Mercury MCP: AI Payment Requests You Approve

Mercury's documentation now lists five write actions for its MCP server. An AI tool such as ChatGPT or Claude can ask Mercury to send a payment or move money between your own Mercury accounts. It cannot finish either one. A person has to approve the request inside Mercury first. Three other write actions, which change expense categories and transaction notes, apply immediately with no approval step.

That split is the whole story, and it decides how you should use the feature. Money movement has a gate. Bookkeeping edits do not.

We read Mercury's supported tools page, connection guide, security best practices, overview and the support article on connecting AI tools on October 16, 2026. Everything about Mercury below comes from those pages. We have not connected a live Mercury account to an agent for this post.

Turn it on if you pay a steady stream of the same vendors, you already live in an AI tool for bookkeeping questions, and one person can spend a minute approving each payment. Leave write access off if you pay a few bills a month, if you need to pay brand new recipients, or if you want payments to happen without anyone looking.

Mercury lists them with the OAuth scope each one needs:

• requestSendMoney (scope transactions:request) creates a payment request to a recipient that already exists in Mercury. Money is not sent until someone approves it in Mercury.
• requestTransferMoney (scope transfers:request) creates a request to move money between your own Mercury accounts. It also waits for approval.
• createCategory (categories:create) creates a custom expense category right away.
• editCategory (categories:edit) updates a custom expense category right away.
• updateTransaction (transactions:update) updates or clears the note or category on an existing transaction right away.

A connection without the matching scope cannot use that tool. Mercury also says existing read-only connections do not gain write access on their own. You have to sign in again and grant the write permissions on Mercury's consent screen.

The flow Mercury describes is short. You ask your AI tool to prepare a payment. The tool creates a request. You open Mercury, find it under Needs approval in Tasks or Payments, check the recipient, amount, payment method and timing, and approve it if you are an eligible approver. Then you check the status.

Mercury is blunt about two points. A confirmation click inside the AI tool is not approval. And "request created" does not mean "payment sent." Mercury's support article adds that approval requests expire after about five minutes, so a slow reply means starting over.

One detail matters for small teams. Mercury says your organization's approval policies still apply, and that if those policies would have allowed the action without approval, the requester still has to approve it in Mercury. In a company where one owner is also the only approver, the AI adds speed to the typing, not a second pair of eyes.

Per the docs, the write tools do not create recipients, delete categories, issue or manage cards, or create invoices. Mercury also notes that its public API can do things the MCP write tools do not expose. And Mercury does not offer a self-hosted MCP at this time, so everything runs through its hosted server with OAuth.

These are workflows we would build around the feature. They are our designs, not customer results.

1. Bills to payment requests. An agent reads vendor invoices from a shared inbox or your accounting tool, matches each to a recipient already in Mercury, and creates a payment request with the invoice number in your own tracking sheet. A person approves in Mercury. If the vendor is not a recipient yet, the agent does not guess. It posts a task for a person to add the recipient first. This is an integration job as much as an AI job, because the value is in the reliable match between invoice and recipient.

2. Weekly categorization with a paper trail. Because category and note changes apply immediately and can overwrite existing values, we would not let an agent roam free. The agent works from a written rules table (vendor name to category), logs the old and new value for every change, and only touches transactions in a date window you set. If a rule does not match, the transaction goes to a review list instead.

3. Planned transfers between your own accounts. Setting money aside for taxes or payroll on a schedule is a good fit for requestTransferMoney, because the destination is your own account and a person still approves.

4. No duplicate requests after a bad connection. Mercury tells you to check for an existing request before creating another one after an uncertain result, using its list tools for send money and transfer requests. Build that check into the workflow. It is the same idea as the dedupe keys in our guide to webhook idempotency for AI agents.

1. 1Start with read access only. Run it for a couple of weeks and see what questions people actually ask.
2. 2When you add write access, grant only the scopes the workflow needs. Mercury itself says to request only the permissions your client needs.
3. 3Decide who approves. If the person who asks the AI is also the approver, treat approval as a deliberate stop, not a click-through. Our post on human approval gates for finance agents covers how to make that stop real.
4. 4Cap what the agent may request. Mercury's approval is the gate, but a limit on amount and recipient list upstream keeps bad requests out of the queue. See action budgets.
5. 5Test with a small amount to a recipient you control before pointing the agent at real vendors.
6. 6Keep a log outside the chat: request, who approved, when, and the invoice it matched.

• Prompt injection. Mercury's own security page warns that a malicious instruction hidden in an untrusted tool, email or document could push an agent to leak transaction data or create unwanted requests. The approval step does not protect against every data leak or immediate edit. Do not let an agent with Mercury access also read untrusted inbound email without a filter.
• Approval fatigue. If an agent creates ten requests a day, people stop reading them. Batch and cap.
• Silent edits. Category and note changes have no queue. A wrong rule can rewrite a month of books before anyone notices. Log before and after.
• Third-party clients. Mercury says to use MCP clients only from trusted sources.
• Expired requests. A five-minute window means the workflow has to cope with a request that timed out.

For retries, read permission retries and approval controls for MCP and the broader permissions and human approval guide.

If you pay five bills a month, clicking through Mercury yourself is faster than setting any of this up. If your vendors change every month, the "recipient must already exist" rule will stall the workflow constantly. If your goal is payments with nobody in the loop, this feature is not that, and Mercury says as much. And if your books are already handled by an accountant on a fixed schedule, immediate category edits from an AI tool may create work for them.

OrchestriAI does not operate Mercury accounts or approve payments for clients. What we build is the plumbing around it. AI agent systems define what an agent may request and what must go to a person. Systems integration connects the invoice source, your accounting tool and the approval log. MCP development covers servers and permission scopes you control. For recurring, rule-bound work that does not need an AI at all, AI workflow automation is usually the cheaper answer. If you are not sure which of your finance tasks are worth automating, start with the free automation audit.

OrchestriAI is an independent implementation provider. Product names are used for identification only. OrchestriAI is not affiliated with, endorsed by, or sponsored by Mercury, OpenAI or Anthropic. This article summarizes Mercury's public documentation as of October 16, 2026. Features, scopes and approval rules can change, so confirm them in Mercury's current docs before granting write access. This is not financial, legal or security advice, and not a compliance conclusion.