You can connect Zapier to Claude using the Model Context Protocol (MCP), and once it’s connected, Claude can trigger the Zaps you’ve already built — which means it can reach into whatever those Zaps touch, not just Zapier itself. That’s the thing that makes Zapier different from every other server in this series: it isn’t one app, it’s a door to thousands of them. This guide covers what the Zapier MCP server actually does, both ways to connect it — directly or through a gateway — and why the scope question matters more here than usual.
What the Zapier MCP server actually does
Zapier publishes a remote MCP server at mcp.zapier.com. Instead of exposing one product’s data the way Notion or Linear’s servers do, it exposes the automations — Zaps — you’ve already set up in your Zapier account, plus the ability to trigger them. In practice that means prompts like:
- “Run the ‘New lead to CRM’ Zap for this contact.”
- “Kick off the invoice-reminder Zap for these three customers.”
- “What Zaps do I have connected to my calendar?”
- “Trigger the Slack-to-Airtable sync now instead of waiting for the next run.”
Whatever a Zap is authorized to do — write a row, send a message, create an invoice, update a record in some other app entirely — Claude can now set that in motion with a prompt. The Zapier MCP server isn’t the thing acting on your data directly; it’s a dispatcher that hands the job to whichever app the Zap was already wired to.
Option 1: Connect Zapier to Claude directly
Zapier’s OAuth registers new clients without an allow-list wait, so the setup is:
- Open Claude’s connector or MCP settings.
- Add a remote server pointing at Zapier’s MCP endpoint.
- Sign in with your Zapier account when prompted — standard OAuth, so Claude never sees your Zapier password, and you can revoke access from Zapier’s own account settings at any time.
That’s enough for one person using Claude with their own Zapier account. The tradeoff shows up once you add a second AI client: each one goes through its own OAuth grant against the same wide door, with no shared record of which client can trigger which Zap.
Option 2: Connect it once, through a gateway
If you’re already juggling more than one MCP server or more than one AI client, wiring each pair directly gets old fast — that’s the connection sprawl covered in what an MCP gateway is. The idea is to connect Zapier (and everything else) to one gateway URL, then point every AI client at that single URL instead of reconfiguring each one.
With gate specifically, connecting Zapier looks like this: add gate’s gateway URL to Claude once, then pick Zapier from the Zapier server page in the directory and sign in with OAuth the same way you would directly. From then on, triggering a Zap is available in every client connected to your gate URL, and every call — which Zap, from which client, at what time — lands in one log instead of scattered across each client’s own history. See the full list of servers on the MCP servers page.
What to check before you connect it
A single Zapier connection can quietly cover more ground than a single-app server ever does, because it inherits the reach of every Zap you’ve built. A few things worth checking before or right after you connect:
- Which Zaps are actually reachable? If a Zap writes to a production database, sends a customer-facing email, or moves money, it’s now one prompt away from firing — not just a scheduled trigger you set up once and forgot about.
- Read Zaps and write Zaps aren’t the same risk. A Zap that posts a Slack summary is a very different exposure than one that creates a Stripe charge or deletes a record. Know which kind you’re handing to an AI client before you approve a broad prompt like “run whatever’s due.”
- The blast radius is the union of every connected app. Zapier itself doesn’t hold your CRM data or your email account — but a Zap that touches both means an instruction routed through Zapier’s MCP server can still reach either one. This is the same shape of problem covered in the confused deputy problem: an agent using access it was already granted, just because something told it to.
- Who else on the team connects it? If more than one teammate wires up Zapier to their own client, each one can trigger every Zap the underlying account can reach — the same access-control question covered in MCP access control for teams.
You can run a quick, no-signup check on any server’s tool list with gate’s free MCP security scanner, which looks for prompt injection and hidden instructions in tool descriptions before you rely on a server day to day.
Troubleshooting the connection
- OAuth loop or sign-in fails. Make sure you’re signed into the right Zapier account in your browser before authorizing — a mismatched account is the most common cause.
- Claude can’t find a Zap you know exists. The MCP server only surfaces Zaps your Zapier account can already see and trigger; a Zap owned by a teammate on a separate account won’t show up.
- A Zap runs but nothing changes downstream. The MCP server hands off the trigger; if the Zap itself is misconfigured, paused, or its own app connection has expired, that’s a Zapier-side problem to check in Zapier’s own dashboard, not the MCP connection.
The bottom line
Connecting Zapier to Claude with MCP is a normal OAuth flow either way: direct if it’s your only client, or once through a gateway if you want the same set of Zaps available everywhere with one log of what fired and when. What’s worth an extra minute is the scope — a Zapier connection isn’t bounded by one app’s permissions, it’s bounded by everything your Zaps already touch. Know what that list includes before you hand an AI client the ability to run any of it on a prompt.