What Zapier MCP and Zapier Agents do in 2026
Zapier sells two agent products on top of its integration catalog. Zapier MCP is a remote MCP server. You pick the apps and actions you want to expose, connect each app once, and then any client that speaks MCP over Streamable HTTP can call those actions from a conversation: Claude, ChatGPT, Cursor, Copilot Studio or your own code. Zapier handles OAuth, stored credentials and rate limiting, which is the whole appeal. Zapier Agents is the hosted version, where you write instructions, give the agent the same actions, and let it run on triggers or a schedule without anyone in the chat.
Both products reach the same action library, and that library includes the payment, billing and accounting apps a US finance team runs on. That is the part this page is about. An MCP server is a door from a language model into a system of record. When the system is Stripe, QuickBooks Online or Brex, the door opens onto money, and the useful question for a controller is what stops the agent when the amount is wrong.
We read the Zapier MCP action catalog for nine finance apps
Zapier publishes a page for every app it exposes over MCP at zapier.com/mcp/<app>, and each page carries the full action catalog in its page data: every read, search and write action, its input fields and the help text Zapier shows the user. On 13 October 2026 we pulled twelve finance and commerce app pages plus one nonsense slug as a control. Nine returned a catalog: Stripe, QuickBooks Online, Xero, Shopify, Square, Brex, Chargebee, PayPal and Recurly. Bill.com, Ramp and Wise returned the same 404 page, byte for byte, as our nonsense control, so we left them out rather than guess at their slugs.
Across the nine apps Zapier lists 138 visible write actions, the ones that change state rather than read it. We counted a write as touching money when it creates, sends, voids, refunds, captures or transfers a payment, invoice, bill, card, subscription or order. That leaves 66 money actions, including Create Payment and Confirm Payment on Stripe, Refund Payment on Square, Create Bank Transfer on Xero, Create Transfer and Create Card on Brex, Capture Order and Mark Order as Paid on Shopify, and nineteen bill, payment, deposit and refund actions on QuickBooks Online.
Then we looked for a ceiling. Those 138 write actions carry 1,921 input fields between them, 65 of which are amounts. Zero of the 1,921 is a maximum, a budget or an approval threshold that limits the agent. The amount is simply a field the model fills in.
The only spending limits in the catalog are ones the agent can set
Our limit search did fire, which tells you the test is not blind. Every hit came from one app, Brex, and they are worth reading closely. Brex on Zapier exposes Set User Limit, whose required input is "Monthly Limit (in USD)", and Create a Budget and Update a Budget, which take a Limit Amount and a Limit Type and are marked for Brex Empower customers only.
Those are write actions. If you enable them on an MCP server, the limit is something the model can change, not something that binds it. The same server can also run Create Card and Create Transfer, whose Amount field is required and unbounded. A spend limit that lives inside the tool set the agent controls is the opposite of the control a finance team wants.
The other two hits were on Stripe's Create Payment Link, "Maximum adjustable quantity" and "Maximum number of times the link can be used". Both limit what a customer can do with a link. Neither limits what the agent can create.
Zapier itself warns that these actions charge money
The help text inside the catalog is candid. On Stripe Create Payment Zapier writes: "Be careful when using this Action because it can charge money to the customers in your Stripe account." The Confirm Payment Immediately field adds that it "controls whether this action charges money or not" and defaults to false "as a precaution", then notes that most users will want to set it to true.
Square's Refund Payment is the sharper example. The refund amount is optional, and the help text says that "if left blank, the refund will be issued for the original full payment amount." An agent that omits the field, which models do, refunds the whole sale.
And six of the nine apps, Stripe, QuickBooks Online, Xero, Shopify, Square and Chargebee, list an API Request (Beta) action that "makes a raw HTTP request that includes this integration's authentication". That turns the named actions into a floor rather than a ceiling, because a raw request can reach any endpoint the connected account is allowed to call.
What Zapier MCP does control and how it bills
Zapier gives you three real controls, and they are worth using. First, action selection. A server exposes only the actions you add, so leaving out Create Transfer is the strongest single thing you can do. Second, field pinning. For each required field you choose between letting the agent select a value and setting a specific value that is used every time the action runs, so you can hard-code the source account or a fixed amount. Third, the endpoint is authenticated. We checked mcp.zapier.com/api/mcp/mcp on 13 October and it answered 401 with a Bearer challenge for the realm "Zapier MCP", while a random path on the same host returned 404.
What none of the three does is reason about money across calls. A pinned amount is fixed, not capped, so it cannot express "up to 500 dollars". Nothing adds up what an agent spent today. Zapier's usage page is explicit that "there is no limit on the number of tool calls per session" and that "the only usage limit is the task allowance included with your Zapier plan." Each successful call uses two tasks and failed calls are free. With pay-per-task on, calls keep running past the allowance, billed at 1.25 times the base rate on annual plans and 2.5 times on monthly plans, up to three times the subscription. The task meter limits what Zapier bills you. It does not limit what the agent sends. For the full rate card, see our Zapier MCP pricing breakdown.
Where Human in the Loop fits for Zapier Agents
Zapier does have an approval tool. Human in the Loop is a built-in app with a Request Approval action that pauses a Zap at a step until a reviewer approves or rejects it, notified by email or Slack. For a recurring Zap that pays a vendor, that is a sensible gate.
It is a Zap step, though, and an MCP tool call is not a Zap. When Claude calls Create Payment through Zapier MCP, the action runs directly, and there is no approval step in between unless you build a Zap around it and expose that instead. Zapier Agents add their own bound, a cap of 40 activities per run on paid plans and 10 on the free tier, but an activity is a unit of work, not a dollar amount. The decision about which amounts need a person still has to be written into every workflow by whoever builds it.
What a finance team adds before a Zapier agent can spend
Before an MCP client or a Zapier Agent gets an action that pays, refunds, transfers or issues a card, a controller will ask for controls that sit outside the tool and that the agent cannot rewrite:
- A per-agent budget per day and per month, cumulative across every app and every Zapier server the agent can reach.
- A per-transaction ceiling, so one confused run cannot refund a whole sale or transfer ten times the usual amount.
- One approval threshold that applies the same way to every action, so amounts over a set number always wait for a person.
- Counterparty rules for approved vendors, customers and categories, checked before the call rather than found in reconciliation.
- An audit record tying each payment to the agent, the prompt, the rule applied and the approver.
A line in the agent instructions that says "never refund more than 200 dollars" is advice to a model, and a model can be argued out of advice by a prompt injection hidden in an email or a support ticket. That is why AI agent governance and spend policy are separate layers, and why the policy has to answer before the action runs.
How AgentsPay works alongside Zapier MCP
Keep Zapier as the place your agents reach apps. AgentsPay sits where the money leaves. Each MCP client or Zapier Agent that can spend gets its own AgentsPay identity with a hard per-agent budget and per-transaction cap, vendor and category rules, and approval thresholds that route larger amounts to a person in Slack or by email. Every decision lands in an exportable audit trail.
The wiring is one call. Have the agent, or a Zap step in front of the payment action, ask AgentsPay whether the agent may spend this amount with this counterparty, and continue only on an approval. When the payment is by card, the agent receives a scoped virtual card with the limit built into the card itself, so the limit holds even if the prompt is hijacked. The same policy covers agents outside Zapier, which matters when other teams wire Claude straight into a vendor's own QuickBooks MCP server or a payment MCP server, or build on Workato MCP instead.