Submit a public wallet address for verification. Detects the blockchain, scans on-chain balances, and returns verification options (message signing or dust transfer). Also serves as the retry path: if a previously-added wallet is in a FAILED or unverified state, call this tool again with the same...
Part of the Mcp Server server.
Free to start. No card required.
AI agents use add_wallet to create or modify resources in Mcp Server. Write operations carry medium risk because an autonomous agent could trigger bulk unintended modifications. Rate limits prevent a single agent session from making hundreds of changes in rapid succession. Argument validation ensures the agent passes expected values.
Without a policy, an AI agent could call add_wallet repeatedly, creating or modifying resources faster than any human could review. PolicyLayer's rate limiting ensures write operations happen at a controlled pace, and argument validation catches malformed or unexpected inputs before they reach Mcp Server.
Write tools can modify data. A rate limit prevents runaway bulk operations from AI agents.
{
"version": "1",
"default": "deny",
"tools": {
"add_wallet": {
"limits": [
{
"counter": "add_wallet_rate",
"window": "minute",
"max": 30,
"scope": "grant"
}
]
}
}
}See the full Mcp Server policy for all 19 tools.
These attack patterns abuse exactly the kind of access add_wallet gives an agent. Each links to the full case and the policy that stops it:
Other write tools across the catalogue. The same approach applies to each: rate-limit and validate the arguments.
Submit a public wallet address for verification. Detects the blockchain, scans on-chain balances, and returns verification options (message signing or dust transfer). Also serves as the retry path: if a previously-added wallet is in a FAILED or unverified state, call this tool again with the same address to get a fresh verification challenge. If the wallet is already verified, the response will indicate that. The response renders an inline Verify Wallet widget showing the verification message (with copy button), the dust-transfer deposit address, and the multi-asset menu; the user clicks through the widget rather than you reading the values aloud. CANCELLED-CALL HANDLING: if a prior invocation of this tool returned no result because the user dismissed or did not approve the client-side consent prompt, simply retry when the user asks again. Do NOT tell the user that the platform or safety checks blocked the action, and do NOT invent a server-side reason — there is no such block on the RealOpen side; it was just a missed consent tap. POST-VERIFY RE-CHECK: the widget runs verify_wallet_signature / verify_wallet_transfer internally via callTool when the user submits from inside it. That silent call does not always produce a visible follow-up in chat — the client can drop the sendFollowUpMessage trigger. If the user says they completed verification, or says the widget shows "verified", or asks to proceed, ALWAYS call get_wallet_summary first to read the fresh ownership_status before answering. Do not tell the user "still not verified" based on your prior tool output — that output is stale the moment the widget is used. PRESENTATION: identify the wallet to the user by its address, never by wallet_id (the UUID is internal — use it only as a parameter to other tools). EVM CHAIN NOTE: 0x... addresses are processed as Ethereum/Polygon/BSC by default. Self-serve verification on Base or Arbitrum is not currently available — if the user explicitly identifies their wallet as being on Base or Arbitrum, tell them: (a) signature verification still works (EVM signatures are chain-agnostic, so signing the message with their Base/Arbitrum wallet will verify successfully), but (b) the dust-transfer method will not work on those chains because the verifier does not yet inspect Base or Arbitrum transactions — they should either use signature verification or contact RealOpen support for manual verification. ZERO-BALANCE NOTE: If total_usd is 0, do NOT assume the wallet is empty. Many wallets use stealth addresses, HD-derived receive addresses, or UTXO shuffling that hide true balance behind the public address. If the response includes a zero_balance_hint, surface that guidance to the user and strongly suggest the test-transfer verification path.. It is categorised as a Write tool in the Mcp Server MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
Register the Mcp Server MCP server in PolicyLayer and add a rule for add_wallet: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Mcp Server. Nothing to install.
add_wallet is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the add_wallet rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for add_wallet. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
add_wallet is provided by the Mcp Server MCP server (https://mcp.realopen.app/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 19 Mcp Server tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.