MCP vs plugins and integrations, and when a protocol beats a point connection

What are you actually choosing between?

Four shapes, and confusing them is why this decision gets argued in the abstract.

A protocol connection is an MCP server: a program that exposes tools, resources and prompts in an agreed format, reachable by any client that speaks the protocol. A native integration is a connector one vendor builds into one AI product, which works there and nowhere else. An automation platform workflow is a Zapier, Make or n8n sequence: a trigger fires, defined steps run, the same way every time. A plugin is a distribution wrapper, which is why it belongs in a different column than the other three.

Anthropic's original announcement framed the problem the protocol was built for: every new data source required its own custom implementation, which made connected systems hard to scale. That is a statement about multiplication, and multiplication is the whole test.

Which shape fits which situation?

	Protocol connection	Native integration	Scripted automation	Plugin
Who builds it	The data owner, once	The AI vendor, per tool	You, per workflow	You, wrapping the rest
Works across AI clients	Yes	No	Not applicable	Within one client
Who decides the next step	The model	The model	Your script	Depends on contents
Fails how	Variably	Variably	The same way every time	As its contents do
Best at	Unscripted questions across tools	Depth inside one product	Recurring known work	Handing a setup to a team

When does a protocol beat a point integration?

When the multiplication is real. Three AI clients and five tools is fifteen integrations under the old model and eight pieces under a protocol: five servers and three clients. Most teams are not at fifteen, which is why the argument often feels theoretical until the second AI client arrives and every integration has to be rebuilt.

When portability matters more than depth. MCP is supported across Claude, ChatGPT, Visual Studio Code, Cursor and others. A team that expects to change assistant within two years is buying optionality, and the cost of that optionality is that a protocol connection is usually shallower than a native one built by the vendor who owns both sides.

And when the question crosses tools. A built-in feature inside your tracker can answer questions about the tracker. Nothing inside it can answer why the tickets in one area spiked the same week a deploy went out, because that answer lives in two systems at once.

When does it not?

When the steps are known in advance. If the job is "every Monday at nine, pull these fields, format them this way, post them there", a scripted workflow is better in every dimension that matters: cheaper, faster, deterministic, and it fails in one place you can go and look at. Putting a model in the middle of a solved problem adds variance and nothing else.

When the tool's own feature already does it. Depth beats portability inside a single product, and a vendor's native AI has context about its own data that no wrapper reproduces.

When the honest scope is one tool and one person. A single connection, used by one product manager, for one weekly question, does not need a protocol argument. It needs to work.

The categories are converging, which reframes the question

Zapier now publishes its own MCP server, connecting AI clients to the apps its platform already reaches, with controls its page describes as choosing which apps and actions the AI can access, including read-only, and logging every action in a history log. So the choice is no longer protocol against automation platform. It is where the decision logic lives and where the audit trail lands.

That is a better question anyway. Scripted steps with a model deciding only the final formatting is a different system from a model choosing which of forty tools to call. Both can be built on MCP. Only one of them needs a review process.

For the platform side of that trade, Zapier against Make for product managers compares the two most common choices, and n8n for product managers covers the self-hosted route.

A plugin is packaging, not a competitor

In Claude Code, a plugin directory can carry skills, agents, hooks and a .mcp.json file holding MCP server configurations, plus a manifest describing the whole thing. Claude Code's own scope precedence for MCP servers lists plugin-provided servers as a level of their own, below local, project and user scope.

Read that structurally. A plugin is how one person's working setup becomes something a team installs in one step, with the server configuration, the prompts that use it well and the hooks that constrain it travelling together. Distributing a bare server URL hands people a capability with none of the judgement around it, which is how nine people end up with nine different versions of the same workflow. Claude Code plugins for product managers covers that packaging decision directly.

What does choosing wrong actually cost?

Picking a scripted workflow when you needed a connection costs you a question you never get to ask. That is invisible, which is why it rarely gets counted, and it is usually the cheaper mistake.

Picking a connection when a script would have done costs more, in two ways people do not price in. Every connected server's tool list enters the model's context before any work starts, so a long list makes answers slower and sometimes worse, not just riskier. And a model-mediated step needs someone checking that the output is still right, every week, forever, because there is no build that stays built. A script you wrote in March is doing the same thing in September. A connection you approved in March may be calling tools whose behaviour changed in June, with nothing announcing it.

The asymmetry has a practical consequence. When the two options look close, the scripted one is the safer default, and you can always add the connection once a question arrives that the script cannot answer. Going the other way, unwinding a connection people have built habits around, is much harder.

The rule worth writing on the wall

If you can write the steps down before the work starts, script them. If the interesting part is deciding which steps to take, connect a server and review what the model chose. If the answer changes depending on who is asking, you have a definitions problem that neither option fixes.

Builders Camp's AI Agents bootcamp sits on the first half of that rule, teaching when a workflow needs an agent at all against when a prompt or a script is the better answer, across 2 weeks with 3 live sessions and 9 microlessons. Automate Workflows with AI sits on the other half, covering workflow mapping and return-on-effort selection, triggers and error handling, and human-in-the-loop approvals, in 1 week with 2 live sessions and 8 microlessons, with Zapier and Make named in its syllabus. Both sit in the AI Agentic Builders Expert Track.

See the AI Agents bootcamp

A test that settles most of these arguments in an afternoon: take the workflow you are debating and write the steps down. If you finish the list, you did not need a model in it. If you get three steps in and write "then decide whether", you found the part a connection is actually for. MCP for product managers covers what that connection is underneath.