Wiring MCP Tools for Finance Agents on Claude

Connecting a Claude agent to your banking systems is the moment the stakes get real. Up to here a mistake produces a wrong sentence; once an MCP tool can move money, open accounts, or file a request, a mistake produces a transaction. Wiring tools and MCP servers for financial services is therefore less about plumbing and more about discipline: how you authenticate, how you shape schemas, how you handle the inevitable errors, and how you guarantee that a retried action doesn't execute twice. This post is about getting those four things right.

The Model Context Protocol is an open standard that lets Claude connect to external tools and data through MCP servers, which expose typed operations the model can call during a conversation. MCP makes integration uniform, but uniformity is not safety — a well-formed tool call to a poorly designed server can still cause harm. The four disciplines below are what turn a working integration into a trustworthy one.

Auth: the agent acts for a user, not as itself

The first rule of wiring finance tools is that the agent must act with the permissions of the human it's serving, never with a god-mode service credential. Establish the user's identity at the start of the session and propagate a scoped token to the MCP server on every call. The server enforces entitlements against that token — so even if the model is somehow induced to ask for an account it shouldn't see, the server refuses. Authorization belongs on the server, not in the prompt, because prompts can be manipulated and servers cannot be talked out of a permission check.

Keep credentials out of the model's context entirely. The agent reasons about what to do; the MCP server handles whether it's allowed using tokens the model never sees. This separation also simplifies audit: every privileged call carries the user's identity, so the access log answers "who looked at this account" without ambiguity. Scope tokens tightly and expire them with the session so a leaked token has a short, bounded blast radius.

Schemas: make the dangerous calls hard to get wrong

For read tools, strict schemas mainly aid reliability; for write tools, they are a safety control. A funds-transfer tool should require explicit, typed fields — source account, destination, amount as a precise decimal, currency, and a client-supplied idempotency key — and reject anything underspecified rather than fill in defaults. Never accept a free-text instruction the server has to parse; that turns the server into a second, untested interpreter of intent. The model's job is to populate a precise schema, and the schema's job is to make a malformed or ambiguous action impossible to submit.

Design schemas so the destructive surface is small and explicit. Separate read and write tools cleanly so a query can never accidentally mutate. For high-stakes writes, require a confirmation token that the agent can only obtain after presenting the action to a human, encoding human-in-the-loop directly into the tool contract. A schema that demands confirmation for a transfer is far more robust than a prompt that politely asks the model to confirm first.

flowchart TD
  A["Claude builds tool call"] --> B["MCP server: validate schema"]
  B -->|Invalid| C["Typed error back to Claude"]
  B -->|Valid| D["Check scoped auth token"]
  D -->|Denied| C
  D -->|Allowed| E{"Idempotency key seen before?"}
  E -->|Yes| F["Return prior result, no re-execute"]
  E -->|No| G["Execute + record key + log"]
  G --> H["Structured result to Claude"]

Error handling: typed failures the model can reason about

Agents only recover gracefully from errors they can understand. A finance MCP server should return typed, structured errors — insufficient_funds, account_frozen, validation_error, rate_limited — not a raw stack trace or a vague 500. Given a typed error, Claude can do the right thing: explain an insufficient-funds result to the user, retry a transient rate-limit after a pause, or escalate a frozen-account case to a human. Given an opaque failure, the best it can do is apologize, and the worst is hallucinate a success.

Crucially, distinguish errors that are safe to retry from those that are not. A network timeout on a read is retryable; a timeout on a transfer is dangerous, because the transfer may have succeeded even though you didn't get the response. Mark each error with a retry-safety flag and let the agent's retry logic respect it. This is exactly where idempotency stops being a nicety and becomes the thing that prevents double payments.

Idempotency: the same action, run twice, happens once

Networks fail mid-call and agents retry; without idempotency, a retried transfer is a duplicate transfer. The fix is to require a client-generated idempotency key on every state-changing operation. The agent's tooling generates a unique key per intended action and includes it on the first attempt and every retry. The server records keys it has executed and, on seeing a repeat, returns the original result instead of running the operation again. From the model's perspective a retry is safe; from the ledger's perspective the action happened exactly once.

Generate the key when the intent is formed, not per HTTP attempt, so all retries of the same logical action share it. Store keys server-side long enough to outlive any retry window. Pair idempotency with the typed retry-safety flags from the previous section: the agent retries freely on operations the server guarantees are idempotent, and refuses to blindly retry anything else. Together these two mechanisms are what let an autonomous agent touch real money without you lying awake about duplicate transactions.

Logging every tool call into the evidence trail

Finally, wire each MCP call into the same evidence ledger your reads use. Every write records the inputs, the idempotency key, the user identity, the result, and a timestamp. This gives you a complete, replayable account of every action the agent took — not just what it said, but what it did. When a customer disputes a transaction or an auditor asks why an account changed, the ledger answers precisely, with the model's reasoning trace alongside for context. An agent that can act in the world must be an agent whose actions are fully recorded.

Frequently asked questions

Can I reuse a public MCP server for finance tools?

Treat any third-party MCP server as untrusted until you've reviewed its auth model, schemas, and error semantics — and never hand it a broad service credential. For tools that touch money or customer data, you almost always want servers you own and control, with the scoped-token and idempotency disciplines above built in. The protocol is open; the trust boundary is yours to enforce.

Where should idempotency keys be generated — by Claude or by code?

By your tooling code, not the model. The deterministic wrapper around the tool call generates a unique key when the intended action is formed and reuses it across retries. Letting the model mint keys risks duplicates or collisions; keeping it in code makes the guarantee reliable and testable.

How do I keep the model from being tricked into a forbidden action?

Don't rely on the prompt for that guarantee. Enforce entitlements on the MCP server against the user's scoped token, require confirmation tokens for high-stakes writes, and keep read and write tools separate. Even a perfectly manipulated prompt then runs into a server that simply refuses unauthorized or unconfirmed actions.

From MCP tools to live customer calls

CallSphere wires these same auth, schema, and idempotency safeguards into voice and chat agents that take real actions mid-conversation — safely looking things up and booking work without double-executing. See the safeguards at play at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.