What the Mercury MCP server does today
Mercury runs one hosted MCP server, at https://mcp.mercury.com/mcp, and labels it a beta. You add it once and sign in through Mercury's OAuth screen, where you pick the account and the permissions the AI tool gets. Nothing is installed on Mercury's side, because the server supports dynamic client registration: the AI tool registers itself on first connect.
Mercury lists official integrations for ChatGPT, Claude, Cursor, Perplexity, Gemini Enterprise, Grok, Microsoft 365 Copilot, Notion and Replit, and documents manual setup for Claude Code and Codex CLI. In Claude Code it is one line, claude mcp add --transport http -s user mercury https://mcp.mercury.com/mcp, followed by claude mcp login mercury.
Once connected, the tool can read balances, statements, transactions with merchant and card metadata, recipients, cards, users, treasury accounts, invoices, customers, webhooks and even SAFE agreements. Mercury's supported-tools page lists 30 read tools and 5 write tools, last updated 8 October 2026. That breadth is the point of the product: a founder can ask "graph my last six months of software spend" and get an answer from live bank data.
The read side matters for security too. Mercury's own security page warns that read access exposes balances across every account, complete transaction history and recipient routing and account numbers, and that this data could leak if the AI client is compromised or prompt-injected.
How we probed Mercury, with a control for every check
We did not rely on the marketing page. On 15 October 2026 we pulled four public sources and checked each against a control that should have produced the opposite result:
- The MCP host. The server root returned
200 {"status":"ok"}, the MCP endpoint returned401withWWW-Authenticate: Bearer error="invalid_token", and a randomly generated path on the same host returned404. So the host is real and not a catch-all that answers everything. - The OAuth metadata.
/.well-known/oauth-protected-resourcenames the resource "Mercury MCP Server" and publishes exactly seven scopes:read,offline_access,transactions:request,transfers:request,categories:create,categories:editandtransactions:update. The authorization server supports PKCE (S256) and a public registration endpoint. - The API reference.
docs.mercury.com/llms.txtindexes 112 documentation pages. Every API reference page embeds its OpenAPI definition, and we parsed 74 operations from them (one page, Get an attachment, ships malformed JSON and was read by hand). A random reference path returned404. - The limit vocabulary. We searched all 257 input fields on the 31 write operations for amount, limit, budget, spend, max, threshold, approval, merchant, category and interval words. The search fired 18 times, and it fired hard on the card endpoints, which is where Mercury does model limits, so it is not blind.
Mercury MCP cannot send money, and that is a real control
Credit where it is due. Mercury designed the MCP write path more carefully than most payment MCP servers we have probed. The two money tools are requestSendMoney and requestTransferMoney, and both create a request, not a payment. Mercury's documentation says plainly that the AI tool "cannot approve the request or move money on its own," and that if your approval policy would normally let the payment through without review, "the requester must approve it in Mercury." There is no OAuth scope at all for the direct send endpoint, so no MCP connection can reach it.
The other three write tools are different in kind. createCategory, editCategory and updateTransaction apply immediately, with no approval queue. They move no money, but they rewrite how spend is categorized and annotated, which is the data your books and your month-end close are built on. Mercury's security page names this risk directly: a prompt injection could cause "unwanted category or note changes."
The MCP server also does not create recipients, issue or manage cards, or create invoices, and agent card credentials are not available through it. So the honest summary of the MCP route is: strong on money movement, open on metadata, and a human approves every single payment.
The Mercury API direct send skips your approval rules
Most agents that do real work will not stop at MCP. A custom AP agent, a payout job or an internal tool calls the Mercury API directly, and the API has two ways to send money that behave very differently.
POST /account/{accountId}/transactions (createTransaction) submits an ACH, check, domestic wire or real-time payment immediately. Mercury's own Send Money guide says it "does not run your organization's approval rules." Its controls are an IP allowlist on the token, a required idempotency key, and a duplicate guard that rejects the same recipient, account and amount within 24 hours.
POST /account/{accountId}/request-send-money (requestSendMoney) always queues the payment for approval in the dashboard, regardless of policy, and by default the approver is someone other than the token creator. It needs no IP allowlist, because dashboard approval is the control, and it is the only route for international wires.
Two practical consequences for an agent. First, the choice of endpoint is the policy: whoever writes the integration decides whether approvals apply. Second, there is nothing between the two. You get every payment approved by a human, or no approval at all. There is no field for "send automatically under 500 dollars, ask above that," no per-transaction ceiling and no cumulative budget on either endpoint. Approval requests also have no webhook today, so an agent waiting on one has to poll.
Mercury agent cards ringfence the card, not the agent
On 12 August 2026 Mercury launched Mercury Spend with agent cards, a virtual debit or credit card a human creates in the web or mobile app and hands to an AI agent. The agent fetches the full number, expiry and CVC from GET https://vault-api.mercury.com/api/v1/cards/{cardId}/reveal or with mercury cards reveal in the Mercury CLI, then checks out on its own. Reveal works for agent cards only and is not available through MCP.
The guardrails are sensible. Per Mercury's changelog, an API caller cannot create a card with isAgentCard set to true, and cannot change an agent card's spend limit or unfreeze it. The stated goal is to let you give an agent API access "while ringfencing your total exposure to only the agent cards handed over." For a single agent with a single card, that is a good design.
The API schema shows where it stops. A card's limit is one object, spendLimit, with an amountCents and an interval of daily, weekly, monthly or yearly. It is a total per rolling window. There is no per-transaction maximum and no approval step on the card. The card object does return merchantLock, categoryLocks and budgets, but none of them appears in the create or update request, so merchant and category locks can only be set by a person in the app, never by your provisioning code. And the limit belongs to the card, not the agent. An agent that holds two cards, or pays through a Mercury card and an API payment and a Stripe charge, has no single number anywhere that says how much it has spent this month.
Commentary on the launch also pointed out that Mercury's agent card terms leave transactions the customer's responsibility even when an agent acts outside its intended scope. That is normal for a card program, and it is the reason the policy belongs on your side.
Mercury API tokens are well managed, and still all or nothing
Mercury's token hygiene is better than most banks offer. There are three tiers, Read Only, Read and Write, and Custom. Any token with write scopes must be pinned to an IP allowlist. Tokens that carry more permission than they used in a 45-day window are downgraded automatically, unused tokens are deleted after 45 days, and admins get a seven-day email warning before either happens.
What a token cannot express is an amount. Scopes say which endpoints a token may call, never how much it may move, and Custom token scopes cannot be edited after creation. An agent holding a Read and Write token can send any amount the account balance allows, through the endpoint that does not check approval rules, from any allowlisted server. Mercury itself restricts what the payments API may be used for: paying your own invoices and automating your bills are allowed, while building a marketplace, escrow or money transmission service on it is not.
What a finance lead adds before an agent touches Mercury
The controls a controller asks for in the architecture review all sit outside the bank, so the agent cannot rewrite them and they work the same on every rail:
- A per-agent budget, daily and monthly, counted across every card, every API payment and every other provider the agent can pay through.
- An approval threshold instead of all-or-nothing: small payments clear automatically, anything above the line waits for a named approver in Slack or email.
- Counterparty and category rules set in code, so a new agent starts with an allowlist instead of waiting for someone to click merchant locks in an app.
- A per-transaction ceiling, so one bad tool call cannot use the whole month's limit in a single charge.
- An agent identity and audit trail separate from the human whose token or card it borrows, so you can answer "which agent spent this, and who approved it" without guessing.
How AgentsPay works alongside Mercury
Keep Mercury as your bank, your cards and your payment rails. AgentsPay sits in front of the moment money leaves. Each agent gets its own AgentsPay identity with hard per-agent spend limits, an approval threshold that routes larger payments to a human, scoped virtual cards for AI agents when you want a card per task, and an audit trail of every agent payment.
In practice the agent asks AgentsPay before it calls createTransaction, reveals an agent card or pays anywhere else. Under the threshold it proceeds and the payment is logged against its budget. Above it, a person approves once and the agent continues. Mercury's own controls stay on as a second line, which is exactly where they belong.
If your stack also includes BILL for payables, the same pattern applies, and we documented BILL's control surface on the Bill.com MCP server comparison. For the wider set of finance tools that now expose MCP servers, see QuickBooks, NetSuite and Xero MCP servers and Stripe, PayPal and Square MCP servers. Mercury's plan prices and fees are broken down in Mercury pricing plans in 2026.