The most common question we got from buyers in Q1 was some variant of: "do you integrate with Zapier?" The honest answer was "not yet, and probably not for a while." That answer raised eyebrows. So here's the longer one.
We took a long look at our customer base and asked: of the agencies and engineering teams running outbound on us, who uses Zapier, and who uses something else?
Out of 312 active sub-workspaces, 41 had a Zapier integration listed somewhere in their stack. Of those, only 9 were using it for anything beyond a one-time data export. The pattern was clear: the agencies we serve have engineers (or at least one technical operator) on staff. They route events through their own infrastructure — n8n, Trigger.dev, in-house API endpoints, sometimes raw cron jobs against the REST API. Zapier was the fallback when nothing else existed.
Meanwhile, 187 of those 312 sub-workspaces had used the public REST API directly within the last 30 days. 73 had used the MCP server. Two of the largest had built their entire reply-triage workflow on top of MCP + Claude Code.
Where Zapier shines, and why we don't fit
Zapier is a brilliant product. It works because three things happen to be true at once: there are millions of buyers who want to wire two SaaS tools together, those buyers are not engineers, and the tools in question have stable, documented webhooks and APIs.
Cold email at the agency tier breaks the first two assumptions. The buyer is technical or has technical staff. The integrations they care about aren't "send to Google Sheets when X" — they're more like "when a reply comes in on this client's campaign, push to that client'sSlack, HubSpot, internal CRM, and analytics warehouse, with the right HMAC signature." That's not a Zapier shape. That's a webhook-per-workspace shape, which we ship natively.
What MCP unlocks that Zapier can't
An MCP server is a JSON-RPC-shaped contract that lets an LLM call a tool by name, with typed arguments, against a remote system. Claude Desktop, Cursor, Zed, and a growing number of agentic IDEs and dev tools all consume it. From the LLM's perspective, MCP tools look exactly like the model's built-in functions.
The unlock is that an agent can decompose a fuzzy request into a sequence of API calls in real time, without anyone writing glue code for the specific request shape. "Pause every campaign in the EU workspace until Tuesday morning"is a one-liner against MCP. Against Zapier, it's a six-step Zap and you've already moved on.
The two most common patterns we see from MCP users in our customer base:
- Morning triage.A user opens Claude on their phone, says "show me the positive replies from the last 24 hours, draft a short response for each, and approve the ones with voice-match above 0.9." That's three MCP calls + an arbitrary natural-language filter the agent applies between calls.
- Programmatic onboarding.A new client signs an MSA. An internal Cursor agent creates a sub-workspace, clones the agency's template campaign, imports the client's CSV, sets up the Stripe Connect subscription, and posts a confirmation in the agency Slack. The whole thing is ten minutes of an agent loop, not a six-week internal sprint.
The technical decisions
A few things we got wrong on the first attempt and then fixed:
Don't let the agent invent IDs. Early MCP versions exposed tools like numail.campaign.pause(campaign_id) with no helper. LLMs would hallucinate campaign IDs that looked plausible. We added numail.campaign.search({ q }) as a separate tool and rewrote the prompt descriptions to nudge the model to always search first. ID hallucination dropped to zero.
Tool descriptions matter as much as tool names.Claude reads the tool description to decide whether to call it. A description of "Pause a campaign" gets called every time someone says "pause" in any context. A description of "Pause a campaign by id, with an optional auto-resume timestamp. Returns the updated campaign state. Idempotent." gets called only when the user means it. Both versions of the tool do the same thing on the server side.
Scope your keys. The MCP server pulls credentials from the user's local environment, but the API key itself is what limits blast radius. We default new keys to read-only and force an explicit scope checkbox for writes. Customers can give their agents a key that can only ever read the unibox and draft a reply, never send. That single piece of UX has avoided several near-misses on customer side already.
Idempotency, always.Every write tool takes an idempotency key. Agents retry. They retry even when they shouldn't. They retry in loops. If your API isn't idempotent under repeated calls with the same key, an MCP integration will eventually create 47 copies of the same campaign. We learned this on our own dogfood week.
What we shipped first, what we deferred
The first @numail/mcp v0.1was 12 tools: list/get for campaigns, leads, mailboxes, and the unibox; pause/resume for campaigns; approve for AI drafts. That covered 80% of the "morning triage" use case. We shipped it three weeks after Claude Desktop's MCP integration went GA.
Today, six months later, we're at 47 tools. Everything in the REST API except a small handful of admin endpoints. The remaining gaps (creating Stripe Connect onboarding links from within an agent loop, for instance) need explicit human consent that's hard to do well from inside a chat agent. Those stay UI-only on purpose.
Meanwhile, Zapier is still on the roadmap. It'll ship — probably in the second half of this year. But it's a v1.1 priority, not a v1 one, because our actual customer was the one who'd ask the agent to do it, not the one who'd set up a Zap.
If you only have time to build one programmatic interface, build the one your most demanding customer is going to use, not the one your widest possible buyer might want.
If you want to try the server yourself, the install is in the MCP page. If you'd rather read the actual MCP tool descriptions, they're served at https://api.numail.ai/v1/mcp/tools as JSON.