Should you require your AI agent to speak MCP?

Not as a buying criterion, yes as an exit criterion. MCP tells you nothing about what an agent is worth; it tells you something about what you will pay the day you replace it.

The distinction is useful because the protocol has become a sales argument. In 2026 MCP is the de facto standard: more than 13,000 servers published on GitHub, Python and TypeScript SDKs totalling over 97 million monthly downloads, adoption by OpenAI, Google DeepMind and Microsoft, and governance moved under the Linux Foundation via the Agentic AI Foundation. Everyone puts it on their product page. Almost nobody explains what it changes.

What MCP actually solves

The Model Context Protocol, created by Anthropic in late 2024, standardises one thing: the grammar by which a model discovers and uses an external tool. How a server declares its functions and data, how a client discovers them, how a model calls them.

Before, every vendor wrote its own connector to every tool. Thirty agents times thirty pieces of software is nine hundred integrations to write and maintain. With a common protocol it is thirty servers and thirty clients.

The gain is real, and it is economic first. It moves integration cost from every pair to every endpoint, which changes the shape of the market: a small vendor can plug into an ecosystem it could never have afforded to build.

And it addresses the right problem. An estimated 85% of enterprise agent errors come from missing context rather than model shortcomings. An agent that cannot see your ATS is not reasoning badly, it is guessing.

The three things it does not solve

The quality of the connection. The protocol describes how to call a function, not whether that function does its job well. An MCP server exposing your ATS might only reach the last ten profiles, ignore custom fields, or return dates in a format nobody checks. It is perfectly compliant and perfectly useless.

Permissions. MCP says how to talk to a tool; it does not say who may do what with it. Many demos skip past this: plugging in an MCP server usually grants the agent the full set of capabilities that server exposes, without anyone deciding, function by function, which ones are needed.

Maintenance. The 13,000 published servers are not maintained as a set. Most are individual projects, and protocol compliance says nothing about what happens the day the exposed tool changes its API, which happens several times a year at any active SaaS vendor. In production, a connector’s availability matters far less than the question of who repairs it.

A connector is a list of permissions

This is the reading that is missing everywhere, and it matters more than the protocol itself.

Every server plugged in is a channel through which external content enters the context of an agent that has permissions. A server that reads your email brings in text written by anyone; a server that browses the web brings in pages nobody reviewed. That is exactly the configuration that makes indirect prompt injection effective: untrusted source on one side, ability to act on the other, same context.

Standardisation mechanically worsens this, because it makes adding a connection trivial. Adding a tool becomes a line of configuration, while the decision it carries, granting a capability, deserves the same attention as opening permissions in any other system.

Hence a simple rule, whatever the protocol: inventory servers the way you inventory access, and for each one ask whether it reads or writes. Looking at an agent’s list of connections through that lens is instructive, and almost nobody does it.

The blind spot: your ATS has no server

The 13,000 published servers give an impression of universal coverage that does not survive the first real case.

Look at what the ecosystem covers: GitHub, Slack, Postgres, Notion, Google Drive, Stripe, the large American SaaS names. Now look at your own stack. A national recruitment ATS, an assignment-management tool built for staffing firms, a billing system chosen eight years ago, a client extranet developed in-house. There is a strong chance none of the four has an MCP server, and that none will for a long time, because the vendor has three hundred customers, not three hundred thousand.

That is the practical limit of the standard, and it is structural: a protocol does not widen a connector’s market, it only lowers its unit cost. Niche tools remain niche tools, protocol or not.

Which moves the question, for a staffing firm, from the protocol to the commitment. Three things are worth asking, and they decide more than compliance does:

How long for a connector to a tool you do not cover? The honest answer is weeks if the tool has a documented API, and “we don’t know” if it does not. Both are acceptable; no answer is not.

Who maintains it afterwards, and on what timescale? A connector written once for one customer and never revisited is a debt that comes back to you.

What happens when there is no API at all? Some tools expose none at all, and never will. A serious vendor will say so plainly rather than promise an integration they will have to improvise.

An agent that perfectly covers fifteen tools you do not use is worth nothing. An agent that covers the four you do is worth everything, protocol or no protocol.

The question that replaces “do you speak MCP”

It fits in one sentence: what happens when the tool on the other side changes?

That is where a vendor who ticked a box separates from one who runs integrations in production. A SaaS provider modifies an API, deprecates a field, changes pagination, tightens a quota. Sooner or later the connector breaks. The real question is how long you go without knowing, and who fixes it.

Three derived questions are enough to tell vendors apart. Who maintains the connector I would be using? You, the community, or the provider itself, and each of those answers carries a different repair time. All three answers are acceptable and none have the same lead times.

How do I know an integration has gone down? An agent that fails silently on one source hands you incomplete results that look like complete ones. That is more dangerous than a visible outage.

What happens on the day I leave? If your connectors are MCP-compliant, you take the integration work with you. Otherwise you pay to build it all over again. That is the one question where the protocol genuinely counts, and it does not arise when you sign: it arises three years later.

What it changes at purchase time

MCP is good news for the buyer, provided you file it in the right row of the scorecard.

It is not a capability criterion. An agent that speaks MCP is not better than one that does not: it is easier to replace. And a vendor with proven proprietary connectors, a documented API and a team that repairs them beats a compliant vendor who has never handled an API breaking.

Nor is it a security criterion, if anything it adds risk, by lowering the cost of adding an untrusted channel.

It is a reversibility criterion, and a good one. File it next to data export and configuration portability, not next to what the agent can do. What it can do is judged differently, notably on the difference between an agent and a workflow, and no protocol gives you that.