How MCP and AI agent wallets work together

MCP can help an AI agent discover and invoke payment-related tools, but it does not move money itself. In an MCP agent wallet architecture, MCP standardizes tool discovery and execution between host, client, and server, while the wallet and payment stack handle custody, authorization, policy checks, and settlement on real rails.

That separation matters for accuracy and security. MCP defines tools, resources, prompts, and JSON-RPC flows for connecting AI applications to external systems, while payment standards make clear that payment UX and authorization are separate flows. In practice, MCP lets an agent ask for a payment action, and the wallet decides whether it can proceed.

What MCP does in a payment stack

The MCP specification uses a host, client, and server model over JSON-RPC. Servers expose tools, clients discover them with `tools/list`, and agents invoke them with `tools/call` using structured arguments. That makes MCP useful as a control plane for actions like `create_quote`, `prepare_payment`, `submit_payment_for_approval`, or `get_payment_status`.

Those tools are still interfaces to downstream systems. If a tool connects to a wallet service or processor, the financial action happens there under that system’s credentials, rules, and ledgering. The tools draft also warns that tool descriptions and annotations should be treated as untrusted unless they come from a trusted server, so discovery is not authorization.

Why the wallet is a separate trust boundary

An AI agent wallet lives on a different trust boundary from MCP. The wallet layer is where funds, payment instruments, balances, merchant restrictions, velocity limits, and approval policies live. Tilde Pay’s public materials describe funded wallet or account context, autonomous payments via MCP or API, spend limits, merchant restrictions, and approvals outside configured limits.

That is the right architectural pattern. MCP should let an agent express intent to pay, while the wallet service decides whether the request is valid under policy and whether it can execute on a real rail such as bank transfer, card, stablecoin, or another supported method. In practice, MCP payment tools should usually call a wallet orchestration service before any processor or bank integration.

Tool execution is not payment authorization

A useful model is to split payment initiation into tool execution and payment authorization. Tool execution is the agent requesting an operation such as preparing a payment, fetching a quote, or submitting a proposed transaction. Payment authorization is the separate decision to use real credentials and move funds.

Payment standards show the same separation elsewhere. The W3C Payment Request API coordinates how payment options are presented and how a `PaymentResponse` is gathered, but it is not a new way to pay. Likewise, MCP coordinates access to payment tools, while the wallet or payment backend authorizes and executes against the actual rail.

Keep credentials out of model context

Credential handling is where unsafe MCP designs often fail. The MCP tools draft warns against exposing sensitive parameters such as passwords, API keys, tokens, or PII in ways visible to intermediaries, and the security guidance warns against token passthrough. MCP servers must not accept tokens not explicitly issued for that MCP server and simply forward them downstream.

For agent wallet systems, the model should not hold raw processor secrets, bank credentials, or long-lived signing authority in prompt context. Credentials should remain server-side inside the wallet or payment service. MCP tool calls should carry business inputs such as merchant, amount, currency, invoice reference, and policy context, while the wallet service attaches credentials under controlled conditions.

Approvals and human-in-the-loop controls

MCP can support approval steps, but approval logic belongs to the application or wallet policy layer. The tools specification allows a server to respond with `input_required` when more information or user interaction is needed. That fits payment flows that require confirmation, added metadata, or explicit human approval before funds can move.

The MCP specification and tools documentation also emphasize explicit user consent before invoking sensitive tools. For payment-capable tools, that should be applied conservatively. Low-risk recurring actions may auto-approve within narrow limits, while high-value or out-of-policy requests should require a human approver before the wallet executes them.

Auditability and system-of-record design

Auditability is another reason to keep MCP and wallet responsibilities separate. MCP clients should log tool usage, but a financial control stack also needs durable payment records showing who requested the action, which policy allowed or blocked it, whether a human approved it, which account or credentials were used, and what the downstream processor or rail returned.

A correlation chain across layers is essential. Each MCP tool call should have its own request ID, and the wallet should issue a separate payment intent or transaction ID that persists through quote, approval, execution, retry, and settlement. MCP logs show what the agent asked for, wallet logs show policy and authorization outcomes, and rail logs show execution results.

Reference architecture and common mistakes

A practical design usually follows six steps: a user or application gives the agent a goal; the MCP client discovers trusted wallet tools with `tools/list`; the agent calls a preparation tool such as `prepare_payment`; the wallet evaluates policy, balances, limits, allowlists, approvals, and environment restrictions; the wallet executes on a real rail with protected credentials if authorized; and results return as a