Letting an Agent Submit Onchain Transactions Through MCP

What an onchain MCP server is

An MCP server exposes tools to a model through the Model Context Protocol. An onchain MCP server exposes tools that read chain state and, more importantly, produce transactions: transfers, swaps, contract calls, payments. The model decides which tool to call with which arguments. Something then signs and broadcasts.

That last sentence hides every design decision that matters. Which tools exist, how narrow they are, where the key lives, what gets checked before signing, and who can say no.

The ecosystem has already been through one iteration. Base's original base-mcp server, built on Coinbase AgentKit, was configured with a wallet seed phrase and Coinbase Developer Platform credentials, so the server process held key material and signed directly. Its repository was archived on May 13, 2026, and Base's docs now point to Coinbase's Wallet MCP. Coinbase's Wallet MCP documentation says write tools return an approval URL and request ID, and that nothing executes until the user approves in Coinbase Wallet, so the signing key stays on the approving side rather than in the server process. Separately, Coinbase launched Payments MCP on October 23, 2025, with agent wallets that have funding limits, approval thresholds and session caps.

The direction is clear: keys out of the server process, approvals and limits outside the model.

Tool design

Separate reads from writes. Balance, history and quote tools can be called freely. Anything that changes state should be a distinct tool with its own policy, so a client can allow one set and gate the other. Wallet MCP's own split, read tools versus write tools that require approval, is the pattern.

Prefer intent tools to raw calldata. A pay_invoice(payee_id, amount) tool can be validated against a payee list and an amount band. A send_calls(to, data, value) tool can do anything the key can do, and the model composes the calldata. Expose raw calls only when you also decode and check them before signing.

Typed, bounded arguments. Amount as an integer in base units with a maximum, asset from an enum of contract addresses, recipient from an allowlist where possible. Every free text argument is one more place a prompt injection can land.

Idempotency keys. Every write tool takes a caller-supplied key and refuses a second execution with the same key. Models retry. Networks time out. Without this, a retry is a second payment.

Return what happened, not just a hash. Status, amount, recipient and block, so the model's next decision is based on the outcome rather than an assumption.

Where signing happens

There are three realistic places, in rough order of exposure.

In the MCP server process, with a key in its environment. Simplest, and the weakest. Anything that can read the process environment or trick the server can sign anything the key can authorise. Acceptable only on testnet.

In an external wallet, with user approval. The server builds the transaction and hands it to a wallet for a human to approve. Strong for occasional high-value actions, and it removes autonomy by design.

With a scoped session key whose limits are enforced onchain. The key lives in protected storage such as the OS keychain, and is registered to a smart account with a spending cap, allowed assets, allowed targets and an expiry. The server can sign without a person, and the account contract rejects anything outside scope. This is the model that permits autonomy without making the server the boundary.

Whichever you choose, the key should never pass through the model's context, and never through a tool argument.

Simulation, limits and approvals

Simulate before signing. Run the transaction against current state with a call that does not broadcast, and check the result: expected token balance changes, no unexpected approvals, no revert. For contract calls, decode the calldata and compare the decoded function and arguments to what the tool was asked to do. A simulation result that differs from the intent is a stop, not a warning.

Enforce limits in two places. A policy layer in the server checks per-transaction and per-period amounts, targets and assets before signing. The session key's onchain scope enforces the same bounds at execution. The first catches mistakes cheaply; the second holds if the first is bypassed.

Use MCP elicitation for confirmations, not secrets. Elicitation arrived in the 2025-06-18 revision, letting a server ask the user for structured input through the client with accept, decline and cancel responses, and it is a reasonable channel for confirming an action above a threshold. Check the revision you are building against: the current one is 2026-07-28, which keeps the rule that form mode must not request sensitive information and routes anything sensitive through the URL mode added in 2025-11-25, delivering requests inside an InputRequiredResult. Under either revision, elicitation is not a way to collect a key or seed phrase.

Treat tool output as untrusted. Token names, contract metadata, API responses and web pages fetched by other tools all enter the model's context. None of it should be able to change the recipient or amount of a transaction the policy layer will sign.