MCP Server or Zapier Integration: Which Should You Actually Build?

Should you build an MCP server or just use Zapier?

Use Zapier when the job is a known action in an app you already connected, and build a custom MCP server when the agent needs to read and reason over data that no off the shelf action exposes. The deciding factor is whether the work is a fixed action or an open question.

That sounds tidy, and in practice most people get it wrong in the same direction. They build a custom server for something that was always going to be three Zapier actions in a row, because building feels like progress and configuring feels like admitting the problem was small.

I have gone both ways on client work, and the pattern that keeps holding is this: the cost of a custom server is not the build, it is the maintenance. So the question is not which one can do the job. Both usually can. The question is which one you are still willing to own in eight months.

What is an MCP server actually doing?

The Model Context Protocol is an open protocol for connecting LLM applications to external data and tools. The specification describes hosts, which are the LLM applications, clients inside them, and servers that provide context and capabilities, communicating over JSON-RPC 2.0 messages.

On the server side, the specification defines three things a server can offer: prompts, resources, and tools. Tools are the executable actions. Resources are data the model can read. Prompts are reusable instruction templates. Most people building their first server only implement tools, which is a shame, because resources are where MCP stops being a fancy webhook and starts being useful.

The practical difference is that a tool call is a request to do something, while a resource is something the model can look at before deciding what to do. If your agent needs to survey a hundred CMS items and choose the right ten, resources and good querying beat a hundred tool calls every time. That is the case where a custom server earns its keep.

What is Zapier MCP doing differently?

Zapier MCP is a hosted bridge rather than a server you write. Zapier says it connects Claude, ChatGPT, Cursor, and other AI tools to Gmail, Slack, Salesforce, and more than 9,000 apps, and that your existing Zapier app connections are brought in automatically. Zapier lists it as being in beta.

The setup story matters more than it sounds. Zapier's own documentation says each MCP client requires its own MCP server, and that you can run multiple servers, one for Cursor, one for Claude, one for ChatGPT, but only one server per named client. That is a governance decision disguised as a configuration detail. It means the boundary of what each AI tool can touch is drawn per client, which is exactly how you would want to draw it.

Zapier also publishes its own adoption numbers on its MCP page: more than 450,000 MCP servers created and more than 18.5 million tool calls completed. Those are Zapier's figures about Zapier, so read them as evidence that the thing is real and widely used rather than as a quality judgment.

How do the costs actually compare?

Zapier's cost model is published and easy to model. Zapier says MCP runs on your existing plan with no separate billing, that each successful tool call consumes two tasks at a fixed rate, and that failed tool calls do not consume tasks. A custom server has no per call fee and a real ongoing cost in your own time.

The batch behaviour is where people get surprised. Zapier's documentation spells it out plainly: adding five rows to a spreadsheet is five tool calls and ten tasks, and searching and updating ten records is eleven tool calls and twenty two tasks. An agent doing bulk work through Zapier MCP will consume tasks in proportion to the work, and agents are enthusiastic. Zapier also says that when you hit your plan's task limit, MCP tool calls stop working until the allowance resets or you upgrade.

A custom server flips the shape of that cost. There is no per call charge, so bulk work is cheap, but you now own an authentication story, a deployment, error handling, and a thing that breaks when an upstream API changes. I wrote about the token side of this in budgeting for automation costs before they run away, and the same logic applies: the cost you can see is rarely the one that hurts.

Which one should you pick for a repeatable, scheduled job?

Neither, usually. If the job runs on a schedule, has no decisions in it, and produces the same shape of output every time, you want a plain Zap or a Make scenario rather than an agent calling tools. Determinism is a feature, and putting a model in the loop removes it for no gain.

This is the most common mistake I see in 2026. Agentic tooling is genuinely good, so people reach for it on jobs that never needed judgment. A nightly sync of form submissions into a CRM does not need a model to decide anything. It needs a reliable pipe and an alert when the pipe breaks.

Keep agents for the jobs where the next step depends on what the previous step found. Draft this reply based on what the ticket says. Audit these pages and tell me which ones are thin. Find the five CMS items that contradict the new pricing. Those are questions, not actions, and they are where the protocol layer pays off. If you are choosing between the classic automation platforms for the deterministic half, I compared them in Make versus Zapier versus n8n for small businesses.

When is a custom MCP server worth the build?

Three situations. When the data lives somewhere with no good hosted connector. When the agent needs to read a lot before it acts, so per call pricing punishes you. And when you need to enforce rules in code that no amount of prompting will reliably enforce.

That third one is the underrated reason. In a custom server you decide what is even callable. If the agent must never delete a CMS item, you do not write a delete tool. If it must never publish without a draft step, publishing takes a draft identifier that only your create tool returns. Constraints written in code hold under pressure in a way that constraints written in prose do not.

The second reason is quieter but adds up. Webflow's own MCP work at Conf 2026 is a good illustration: Webflow announced that agents can now sort and filter on custom fields, search across reference fields, and page through results, which it frames as fewer requests and less token burn on multi step CMS work. Better querying is worth more than more actions.

What breaks in each approach?

Zapier MCP breaks on scope and budget. The agent finds a tool you forgot was connected and uses it, or a bulk operation quietly burns through the task allowance. Custom servers break on maintenance. Auth expires, an upstream API changes a field name, and nobody notices until an agent silently returns nothing.

The silent failure is the dangerous one in both cases. A tool that errors is fine, because the agent sees the error and usually says so. A tool that returns an empty list because a filter changed meaning is not fine, because the agent reports honestly that it found nothing and everyone believes it.

So whichever side you land on, the monitoring question is the same. What does a successful run look like numerically, and what alerts when today's number is zero? I keep that check outside the automation itself, because a broken system is a bad judge of whether it is broken. If you run one server across several clients, the layout choices I described in running a single MCP server across multiple clients apply here too.

How do you decide without building both?

Write the job down as a sentence and look at the verb. If it is send, create, update, or log, it is an action and Zapier almost certainly wins. If it is find, compare, audit, choose, or decide, it needs reading before acting, and that is where a custom server or a richer platform MCP starts to pay.

Then check the volume. Under a few hundred tool calls a month, the hosted route is cheaper than any hour you would spend building. Above that, run Zapier's arithmetic on your actual expected call count before you commit, because two tasks per successful call compounds faster than people expect once an agent is doing batch work.

Then check who maintains it. If the answer is one person who is already busy, the hosted option is not a compromise, it is the correct engineering decision. Systems nobody has time to maintain do not fail loudly. They drift.

What should you do next?

Pick your single most annoying manual task and classify it honestly against three questions. Is it an action or a question? Is it deterministic or does it need judgment? Is it low volume or high? Three answers, and the choice usually makes itself without building a prototype first.

If it comes out as an action on low volume, connect it through Zapier MCP this week and stop thinking about it. If it comes out as a question over a lot of data, sketch the resources and tools your server would expose before you write any code, because that list is the real design. If you want a second opinion on which side a specific workflow falls, reach out and tell me what the job is. I will tell you straight if it does not need an agent at all.