Integration
Zapier MCP integration
Zapier's MCP server exposes its catalog of 9,000+ app integrations to MCP clients (Claude, Cursor, and others) as invocable verbs. Every app integration Zapier already manages becomes callable through the standardized MCP Tools primitive, without each SaaS vendor needing to ship its own MCP server.
How the integration works
Zapier hosts the MCP endpoint. The client connects over the documented transport and
the two sides run capability negotiation during the initialize handshake. Tool
definitions surface via tools/list at session init; each tool maps to a
Zapier-managed action against an underlying app (Gmail send, Slack post, Notion page
create, and so on across the catalog). When the agent invokes tools/call,
Zapier executes against the target app's API and returns the structured result up the
JSON-RPC 2.0 wire.
The auth model
Authentication is OAuth-mediated. The user grants Zapier access to the apps they want exposed; Zapier issues a scoped token that the MCP client stores in its config (the same place Claude Desktop, Cursor, or Windsurf keep any other remote-server credentials). The token's blast radius equals the set of Zapier app authorizations attached to it. Same risk model as any OAuth-mediated MCP server. If the client config leaks, the token leaks.
Trust considerations
The data path crosses two trust boundaries. Your MCP client sends the tool call to Zapier; Zapier then calls the third-party app (Gmail, Slack, Notion). Both hops are candidate audit points. The relevant inputs for the trust score: which apps the token is authorized against, what Zapier logs about each invocation, and whether the client surfaces the destination app to the user before the call fires. Postmark-mcp (September 2025) is the worked example of why the destination of an agent-initiated SaaS action deserves explicit user-visible confirmation beyond just a tool name.