Why MCP Spread

On March 26, 2025, OpenAI shipped support for a standard published by a rival lab.

The standard was the Model Context Protocol, MCP, which Anthropic had released four months earlier as a common way for AI applications to plug into tools and data. OpenAI's agent toolkit supported it the same day Sam Altman announced the decision. Microsoft followed within two months. A little over a year after launch, Anthropic donated the protocol to a new foundation under the Linux Foundation, with Anthropic, OpenAI, Google and Microsoft among its top-tier members.

Rival labs rarely agree on anything that fast. So it's worth understanding why they did here, and what exactly they agreed on, because the answer tells any company adopting MCP which problems it just solved and which ones it still owns.

MCP spread because it turned a multiplication into an addition, moved the connector work to the people who know each system, and made joining cheaper than competing. What it standardizes is how a tool is described and called. It says nothing about what a tool may do or which servers deserve trust, and those questions stay with whoever adopts it.

From twenty connectors to nine

Every AI application that does real work has to reach the systems where the work lives: the ticket queue, the billing database, the code repository. Until late 2024, each application built that reach on its own.

Take a company with four AI applications (a chat assistant, a coding assistant in the editor, a coding agent and an internal workflow agent) that should each reach five systems (CRM, billing, ticketing, a wiki and a database). Without a shared interface, every pair needs its own connector: code that translates the application's way of calling tools into the system's interface, handles the login and formats the results. Four times five is twenty connectors, and each one breaks when either side changes.

With a shared protocol, each application implements the client side once and each system gets one server. Four plus five is nine.

Scroll sideways to see the whole figure

The saving isn't automatic. With two applications and two systems, the grid needs four connectors and the protocol needs four, so nothing is gained. But the gap grows with the size of the grid: at five applications and twenty systems it's 100 against 25. Real portfolios never fill every cell, so those are upper bounds. The direction is what matters.

The count matters less than who does the work. Without a standard, the maker of every AI application has to learn every system's interface and permissions. With one, the owner of each system, who already knows both, builds a server once, and the application maker builds a client once. Work moves to the party with the knowledge. That's what lets a catalog of connectors grow without anyone coordinating it.

Programmers had seen this exact arithmetic before. Until 2016, code-editor features like autocomplete had to be rebuilt for every combination of editor and programming language. Then Microsoft's Visual Studio Code team, with Red Hat and Codenvy, published the Language Server Protocol: one server per language, usable from any editor. MCP's first specification says it took inspiration from it, and the two share the same basic machinery. The pitch was already familiar to the people who had to build it.

What actually travels over the wire

MCP has three roles. The host is the AI application a person uses, and it contains the harness, the ordinary software around the model that decides what the model sees (Same Model, Different Results). A client is a connector the host creates for each server. A server is a program in front of a system that announces what it offers. Servers can run as a local program on your machine or as a web service anywhere.

Scroll sideways to see the whole figure

The most important thing a server offers is tools: functions the model may decide to call. Here is a whole tool definition, roughly as a billing team might publish it so any compatible assistant can answer "which of Acme's invoices are overdue?"

{
  "name": "search_invoices",
  "description": "Find invoices in the billing system. Use when the user asks what a customer owes or has paid. Returns at most `limit` invoices, newest first. Does not change anything.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer": { "type": "string" },
      "status": { "type": "string", "enum": ["open", "overdue", "paid"] },
      "limit": { "type": "integer", "minimum": 1, "maximum": 50 }
    },
    "required": ["customer"]
  },
  "annotations": { "readOnlyHint": true }
}

The host fetches this list from the server and shows it to the model. When the model decides to use the tool, it writes a tool call with arguments, the client forwards it, and the server queries the billing system and returns text the model can read: "2 overdue invoices for ACME-0042..."

Three details in that small block explain most of what follows.

The description is all the model knows. It's a paragraph of text the model reads to decide when to use the tool. If it's vague, the model guesses. Nothing in the standard checks whether it's any good.

The annotations are hints. readOnlyHint says the tool doesn't change anything, and the specification itself says clients should never trust such hints from untrusted servers.

Nothing says whose invoices the caller may see. That decision happens inside the server and the billing system, if it happens anywhere.

MCP standardizes how a tool is described and called. It does not say what the tool may do.

Why rivals said yes

Several things helped MCP's start. Anthropic launched it with working pieces, including support in its own desktop app and ready-made servers for Google Drive, Slack, GitHub and Postgres, so the first clients had something to plug into on day one. Tool-using AI products, coding agents especially, were taking off and needed exactly this. And the design borrowed a template developers already trusted.

None of that explains why a rival joined. The explanation I find most convincing is a cost asymmetry. A lab that builds its own connector format has to recruit every system owner separately, and every competing format splits those owners' effort. A lab that adopts the existing protocol borrows the whole catalog overnight. That OpenAI's toolkit shipped support on the day of the announcement suggests how cheap joining was. This is an argument from incentives; nobody has published the decision memo.

Once OpenAI was in, the rest followed quickly. Microsoft announced support in Windows 54 days later. The decisive step looks like that rival adoption, because it turned MCP from Anthropic's format into the format everyone's users already had servers for. The evidence here is sequence and timing, so it can't fully separate cause from momentum already building.

Then came neutral ground. In December 2025 the protocol moved to the new Agentic AI Foundation, co-founded by Anthropic, Block and OpenAI. Anthropic said the way the project is governed would stay the same, so the move changed the legal home more than the working process. The effect still mattered: a rival can adopt a foundation's standard without adopting a competitor's product.

One more data point suggests where the value sits. The 2026 revision rebuilt the protocol's core: it dropped the opening handshake and the idea of a session entirely, so each request now stands alone. If adopters had been attached to the original design, that would have been a crisis. It wasn't. OpenAI's toolkit simply probes servers the new way and falls back to the old one. The value is in the shared name and the shared catalog, much more than in any particular design decision (What Standards Do to Lock-in). That also means the standard can change under its users, and it has: four backward-incompatible revisions in about 21 months.

A plug, not a policy

MCP is best understood as a plug standard. It guarantees the connector fits the socket. It promises nothing about what comes through. Five things that look like part of the standard aren't.

What a tool may do. The protocol carries a tool's name, arguments and result. It doesn't decide whether this user, in this context, should run it. The specification says a person should be able to deny tool calls and that servers must check access, but those are requirements on implementations, and implementations vary. Authorization itself is optional. When Microsoft announced MCP for Windows, it added its own registry, proxy, consent prompts and signing requirements, which tells you the base protocol wasn't built to carry that load.

Trust in other people's servers. A server controls two things the model reads: the tool descriptions and the results. And models can't reliably tell instructions from data (Giving an Agent Room to Work). In April 2025 security researchers at Invariant Labs showed tool poisoning: instructions hidden in a tool's description, visible to the model but not to the user, told an agent to read the client's MCP configuration file and an SSH key and send them back through an extra parameter. They also described servers that change a description after the user approved it, and one server's description quietly altering how the agent uses another server's tool. OpenAI's own documentation warns that a malicious remote server can extract anything that enters the model's context.

The quality of the descriptions. Fifty vaguely named tools is perfectly valid MCP and a terrible interface, partly because every definition takes up room in the model's context window, the limited text it can consider at once. Two servers that each expose a tool called search collide when a host combines them.

Reliability. Since the 2026 revision, if a connection drops mid-request, the client has to send the request again as a new one, and it can't know whether the first attempt ran. A tool that charges a card or sends an email can run twice unless its author made it safe to repeat (When the Tool Call Fails Halfway).

Money. The specification defines no pricing, metering or payment. A vendor hosting a server decides what it exposes and what it charges, in the contracts that already governed its API.

Is it just a wrapper?

The natural objection says MCP is a thin layer of well-known parts (JSON messages, web requests, standard login, schemas) and that standards like this come and go.

Half of that is right. The technology is ordinary, and the core was redone about twenty months after launch. If the claim is that MCP is clever, it isn't. But standards win through coordination, and novelty rarely decides which one becomes shared. The question is whether MCP became the point everyone converged on, and it clearly did. The closest precedent, the Language Server Protocol, is still maintained roughly ten years later, though its providers were local programs developers chose, while MCP's can be remote and sometimes hostile.

The stronger version of the objection is that models may not need a tool protocol at all. A coding agent with a command line can run any program, and an agent that operates a screen can use software with no machine interface. For local developer tools that's already true. But where a system is remote, requires login, and serves many people with different rights, typed schemas, a standard login flow and a single place to set policy are worth having.

My bet, and it's a hypothesis, is that MCP stays strongest exactly there: in front of companies' systems of record and the software-as-a-service products they rent, and matters less on the developer's laptop.

What to build once, and what to keep owning

For a company, the useful consequence is a division of labor.

Build once a server in front of each system of record that AI applications should reach, so your own agents and your vendors' assistants share one connector instead of each building its own.

Keep owning what the protocol won't:

• Permissions. The server should call the system on behalf of the signed-in person (delegated access), with the narrowest permissions that work, and the check must also hold in the system behind it (Data Access Is the Real Integration Project). Where your clients support it, the Enterprise-Managed Authorization extension lets your identity provider decide which servers employees can reach and revoke them in one place.
• Audit. The log you can trust is the one on your side: who called what, with which arguments, and what came back.
• Effect classes. Sort every tool into read, reversible write or irreversible effect, and set approval and retry rules for each class.
• A test set. Whether a model uses your tools well depends on your descriptions and on the model. A small evaluation set of real tasks catches regressions when either changes.
• A server policy. Treat third-party servers as software dependencies that can talk to your model: name an owner, pin versions, review description changes.

Expect to run two protocol revisions at once for a while, and pin the versions of the libraries you build on.

For software vendors, the lesson runs the other way. Once connectors are cheap, lacking one becomes a gap, and having one stops being an advantage. What differentiates is what your server exposes, which permissions it enforces, and what the data behind it is worth.

The plug is solved. Everything that matters about what flows through it is still yours.

Check yourself

Why did a rival like OpenAI adopt MCP so quickly?

Joining was cheap. Adopting the existing protocol borrowed the whole catalog overnight, while a separate format would have meant recruiting every system owner again.

Why does the wording of a tool description matter?

It is the paragraph the model reads to decide when to use the tool, and nothing in the standard checks whether it is any good. Vague descriptions make the model guess.

Why is MCP not a security policy?

It carries names, arguments and results but does not decide whether this user should run a tool or whether a server can be trusted. Tool poisoning shows why.