Real-Time Deposit Alerts in Claude: MCP Tools for Incoming Transaction Monitoring
Real-Time Deposit Alerts in Claude: MCP Tools for Incoming Transaction Monitoring
Incoming transaction monitoring is one of those features that sounds simple until your AI agent misses a deposit and acts on stale balance data. If you're building with Claude's Model Context Protocol and need your agent to know when funds arrive onchain — in real time — WAIaaS gives you that out of the box, with one entry in your claude_desktop_config.json.
Why Your Agent Needs to Know About Deposits
Think about what an autonomous trading agent actually needs to do its job. It checks balances, executes swaps, manages positions. But all of that logic falls apart if the agent doesn't know when new funds have arrived. A deposit monitoring gap means your agent might refuse a trade because it thinks the wallet is underfunded, or worse, queue up a transaction before the incoming SOL or ETH has settled.
The stakes get higher when you're running multiple wallets across chains, or when an agent is acting on behalf of a user who just topped up their wallet and expects something to happen next. Real-time deposit awareness isn't a nice-to-have — it's the connective tissue between the outside world and your agent's decision loop.
WAIaaS as an MCP Server
WAIaaS is a self-hosted Wallet-as-a-Service daemon that exposes 45 MCP tools covering wallet operations, transactions, DeFi actions, NFTs, and — critically for this post — incoming transaction monitoring. You run it locally or on a server, then point Claude Desktop at it. Your Claude agent gets a fully functional wallet layer without you writing any blockchain infrastructure code.
The full list of 45 tools includes get-incoming-summary, list-incoming-transactions, get-balance, get-assets, and 41 others. Deposit monitoring is a first-class citizen in that toolset, not an afterthought.
Here's all the Claude Desktop config you need:
{
"mcpServers": {
"waiaas": {
"command": "npx",
"args": ["-y", "@waiaas/mcp"],
"env": {
"WAIAAS_BASE_URL": "http://127.0.0.1:3100",
"WAIAAS_SESSION_TOKEN": "wai_sess_<your-token>",
"WAIAAS_DATA_DIR": "~/.waiaas"
}
}
}
}
That's the one line (well, one block) that gives Claude a wallet with deposit monitoring. Once the daemon is running and this config is in place, you can ask Claude things like "summarize incoming transactions from the last 24 hours" and it will call get-incoming-summary against your actual wallet.
The Two Monitoring Tools You'll Use Most
get-incoming-summary
This tool gives Claude a high-level overview of recent deposits — aggregated amounts, token types, and timing. It's what you want when you're asking Claude to make a decision based on recent inflows. For example:
User: "Has anything come in since yesterday? Should I rebalance?"
→ Claude calls get-incoming-summary → sees 2.5 SOL deposited 3 hours ago
→ Claude factors that into its rebalance recommendation
The summary view is fast and low-noise. It's the right tool for agents that need situational awareness without drowning in transaction-level detail.
list-incoming-transactions
This tool returns the full list of individual incoming transactions — each deposit as a discrete record with address, amount, token, timestamp, and status. It's what you reach for when you need to audit, filter, or act on specific deposits.
User: "Show me all USDC deposits this week"
→ Claude calls list-incoming-transactions → filters by token and date range
→ Returns itemized list with amounts and confirmation status
Together, these two tools let Claude answer both "what's the big picture?" and "what exactly came in and when?" — without you writing a single line of blockchain indexing code.
How Incoming Monitoring Connects to the Rest of the Toolset
This is where WAIaaS as an MCP server really earns its place. The 45 tools aren't isolated — they compose. An agent that can monitor incoming transactions can also:
- Call
get-balanceto confirm the deposit has settled before acting - Call
execute_actionwith a Jupiter swap if a SOL deposit triggers a rebalance rule - Call
get-defi-positionsto check whether the new funds change an LTV ratio - Call
simulate-transactionto dry-run the next move before committing
The flow from "deposit detected" to "action taken" is entirely within Claude's tool context. You don't need a separate webhook infrastructure or a custom event system. The agent can poll, reason, and act using the same MCP session.
Here's what that might look like in a real conversation with Claude:
User: "Monitor my wallet and tell me when a deposit arrives.
If it's more than 1 SOL, swap half to USDC."
→ Claude calls get-incoming-summary (initial check)
→ [Later] Claude calls get-incoming-summary again (polling)
→ Detects 2 SOL deposit
→ Calls simulate-transaction with dryRun: true to verify the swap
→ Calls execute_action with jupiter-swap for 1 SOL → USDC
→ Reports back to user
Setting Up WAIaaS: The Minimal Path
If you don't have WAIaaS running yet, here's the fastest route from zero to deposit monitoring in Claude.
Step 1: Start the daemon
npm install -g @waiaas/cli
waiaas init --auto-provision
waiaas start
--auto-provision generates a master password automatically and writes it to a recovery file. You don't need to set anything manually to get started.
Step 2: Create a wallet and session
waiaas quickset --mode mainnet
quickset creates wallets and MCP sessions in one command. It prints the MCP config JSON you need to paste into Claude Desktop.
Step 3: Add to Claude Desktop config
Paste the output from quickset into ~/Library/Application Support/Claude/claude_desktop_config.json. Or let the CLI do it:
waiaas mcp setup --all
Step 4: Verify the connection
Open Claude Desktop, start a new conversation, and ask:
"What's my wallet balance?"
Claude calls get-balance via MCP. If you see a real balance (even zero), the connection is working. Then try:
"Show me any recent incoming transactions."
Claude calls get-incoming-summary. You're live.
Step 5: Configure notifications (optional but recommended)
WAIaaS includes incoming transaction monitoring with real-time notifications for deposits. If you want push alerts when something arrives — not just on-demand queries — you can configure the notification channel:
waiaas notification setup
This wires up the daemon's deposit monitoring to your preferred notification method, so you (and your agent) don't have to poll manually.
Multi-Wallet Setup: One Agent Per Wallet
If you're running separate wallets for different purposes — a trading wallet, a payments wallet, a Solana wallet — you can run multiple MCP server instances, each scoped to one wallet:
{
"mcpServers": {
"waiaas-trading": {
"command": "npx",
"args": ["-y", "@waiaas/mcp"],
"env": {
"WAIAAS_BASE_URL": "http://127.0.0.1:3100",
"WAIAAS_AGENT_ID": "019c47d6-51ef-7f43-a76b-d50e875d95f4",
"WAIAAS_AGENT_NAME": "trading-agent",
"WAIAAS_DATA_DIR": "~/.waiaas"
}
},
"waiaas-solana": {
"command": "npx",
"args": ["-y", "@waiaas/mcp"],
"env": {
"WAIAAS_BASE_URL": "http://127.0.0.1:3100",
"WAIAAS_AGENT_ID": "019c4cd2-86e8-758f-a61e-9c560307c788",
"WAIAAS_AGENT_NAME": "solana-wallet",
"WAIAAS_DATA_DIR": "~/.waiaas"
}
}
}
}
Each MCP server instance has its own session and wallet scope. Claude sees them as separate tools namespaced by agent name. You can ask "check incoming transactions on my Solana wallet" and Claude routes to the right session.
What About Security?
Deposit monitoring is read-only, but it runs in the same session as transaction execution. That means the session token you configure has access to both. WAIaaS uses a policy engine with 21 policy types and 4 security tiers (INSTANT, NOTIFY, DELAY, APPROVAL) to control what the agent can actually do with funds it detects.
For a monitoring-focused setup, you might configure the spending policy conservatively:
curl -X POST http://127.0.0.1:3100/v1/policies \
-H "Content-Type: application/json" \
-H "X-Master-Password: my-secret-password" \
-d '{
"walletId": "<wallet-uuid>",
"type": "SPENDING_LIMIT",
"rules": {
"instant_max_usd": 10,
"notify_max_usd": 100,
"delay_max_usd": 500,
"delay_seconds": 300,
"daily_limit_usd": 1000
}
}'
With this policy in place, Claude can monitor and report freely, but any spend over $10 triggers a notification, anything over $100 gets delayed, and anything over $500 requires your explicit approval via WalletConnect or Telegram. The agent sees everything coming in; you stay in control of what goes out.
The policy engine uses default-deny for token transfers: transactions are blocked unless explicitly allowed. So even if Claude decides to act on a deposit, it can only send tokens you've whitelisted via ALLOWED_TOKENS policy. That's a meaningful safety layer for any agent running autonomously.
The 45-Tool Picture
Deposit monitoring is two tools out of 45. The others span:
- Wallet:
get-address,get-balance,get-assets,get-wallet-info,get-nonce - Transactions:
send-token,send-batch,sign-transaction,simulate-transaction,list-transactions,get-transaction - DeFi:
action-provider,get-defi-positions,get-health-factor,hyperliquid,polymarket - NFT:
list-nfts,get-nft-metadata,transfer-nft - x402:
x402-fetch— automatic HTTP payment handling - ERC-4337:
build-userop,sign-userop— account abstraction and gasless transactions - ERC-8004:
erc8004-get-reputation,erc8004-get-agent-info— onchain agent reputation - WalletConnect:
wc-connect,wc-disconnect,wc-status
The incoming transaction tools (get-incoming-summary, list-incoming-transactions) slot into a broader agentic loop where Claude can observe, reason, and act — all through the same MCP session.
What's Next
The fastest next step is to get the daemon running and ask Claude "show me incoming transactions" — the whole setup takes about five minutes with waiaas init and quickset. From there, the natural progression is adding spending policies to control what Claude can do when it detects a deposit, then exploring the DeFi action tools to build actual automated strategies.
Dig into the full codebase and documentation at github.com/minhoyoo-iotrust/WAIaaS, or check out the official site at waiaas.ai for deployment guides and the full API reference at /reference once your daemon is running.