MCP: The USB-C of AI, Explained Properly

Your AI model cannot read a file, check an inbox, or look at a database. Everything it does beyond writing text is a connection somebody had to build by hand, and until recently every one of those connections was built differently.

There is a drawer in most homes that tells the whole story.

Open it and you find a micro USB cable, a Lightning cable, a mini USB from a camera nobody owns anymore, two chargers with barrels that fit nothing, and a laptop brick from a dead machine. Every one of those cables does the same job. Every one of them moves power from a wall into a device. And not one of them works with the device sitting next to it.

That drawer is not a story about cables. It is a story about what happens when a hundred companies solve an identical problem separately.

The AI industry spent 2023 and 2024 building exactly that drawer. This piece is about how it happened, why it got so expensive so quickly, and what the fix actually is. I will put the conclusion up front, because the conclusion is the interesting part: the hard problem in connecting AI to the real world was never the connecting. It was that nobody agreed on how.

The thing language models cannot do

Start with a limitation that gets glossed over constantly.

A large language model generates text. That is the whole of it. Give it a sequence of words and it produces the next likely sequence. It can write, summarize, translate, argue, and explain, and it can do all of that impressively well. What it cannot do is anything else.

It cannot open your email. It cannot query your database. It cannot list the files on your laptop or check whether an order shipped. It has no eyes and no hands. It has a very large memory of text it read during training, and that memory stops on a fixed date. Ask it what happened yesterday and it will either say it does not know or, worse, invent something plausible.

This matters more than it sounds. A model that cannot see the world is not a colleague, it is a very good writer with no access to the office. It can draft the email. It cannot check whether the thing the email is about is true.

So the industry did the obvious thing. If the model cannot reach the world, hand it a phone.

Tool calling: teaching a text generator to point

The fix is a trick, and once you see it, it stops feeling like magic.

Before you send the user's question to the model, you also send a menu. The menu is written in plain text and it describes functions the model is allowed to request. Something like: there is a function called search_orders that takes a customer ID and returns their recent orders. There is one called send_email that takes a recipient, a subject, and a body.

Now the model has two ways to respond. It can write an answer, as always. Or it can write a small structured message that says, in effect, "I want search_orders with customer ID 4417."

That message is still just text. The model has not done anything. It has pointed.

Your application reads the pointing, actually runs the function, gets back real data, and hands that data to the model as more context. Then the model writes the answer using facts it did not have thirty seconds earlier.

This is called tool calling, and it is the single change that turned language models into something you can build a product on. The model stays a text generator. The application does the doing. The model's only new skill is knowing which tool to point at and what to put in it.

Everything since then, every agent, every AI assistant that can actually accomplish a task, is this loop running over and over.

Where it went wrong

Here is the part nobody puts in the demo.

The menu has to be written in some format. The pointing message has to come back in some format. Your code has to parse that message, dispatch to the right function, and package the result in yet another format the model can read.

None of that was standardized. There was no committee, no RFC, no shared spec. There was a good idea and a land rush.

OpenAI defined a format for their models. LangChain, a widely used framework, defined its own. Other frameworks defined theirs. And every company building something serious in-house defined a private one, because in 2023 that was faster than waiting for a standard that did not exist.

So the same tool, wrapped for four different systems, became four different pieces of code doing the same work in four incompatible shapes.

Now multiply.

The multiplication problem

This is the center of the whole story, and it is worth doing the arithmetic slowly.

Say your company has five AI applications. A customer support assistant, an internal knowledge bot, a coding helper, a sales research tool, a reporting agent.

And say you have five systems you want them to reach. Your database, GitHub, Slack, Gmail, and your file storage.

How many integrations do you build?

Not five. Not ten. Twenty-five. Each application needs its own connector to each system, because each application speaks a different tool-calling dialect. The support assistant's Gmail connector cannot be reused by the sales tool. Same API on one end, same inbox, but a different shape expected on the other end.

Engineers call this the N times M problem. N applications, M tools, N times M integrations.

Five and five is twenty-five, which sounds survivable. Now use a real number. A mid-sized company has something closer to fifty systems worth connecting: Jira, Salesforce, Confluence, Stripe, an internal CRM, three databases, a data warehouse, a dozen internal services, a ticketing system, a CI pipeline. Fifty tools and ten AI applications is five hundred integrations.

Five hundred pieces of custom code. Each one written by someone, reviewed by someone, tested by someone. Each one able to break.

And the cost is not the writing. The writing is the cheap part.

The second bill, which is bigger

The integration you build today is not a purchase. It is a subscription, and you pay it in maintenance.

Follow the chain.

Gmail changes something in its API. A field gets renamed, an auth flow tightens, a response shape shifts. That is a normal Tuesday for any large service.

Every connector anyone built against the old shape now breaks. Not just yours. Thousands of teams, all over the world, each maintaining a private Gmail connector, all break in the same way on the same day.

Then thousands of engineers independently open the same error, read the same changelog, and write the same fix. Same bug, same patch, discovered and repaired thousands of times in parallel by people who will never know about each other.

That is the actual cost of no standard. Not the five hundred integrations. The five hundred integrations multiplied by every upstream change, forever.

And it gets worse with success. The more useful AI becomes inside a company, the more tools people want connected, and the faster this pile grows. The reward for adoption was a larger maintenance burden. Teams were being punished for the thing working.

What a protocol actually is

The fix is smaller than people expect, and understanding why requires being precise about a word.

A protocol is not software. You do not install it. It is not a library, a service, or a product. A protocol is an agreement about the shape of a conversation.

HTTP is a protocol. There is no HTTP program running anywhere. There is a written agreement that a request starts with a method and a path, that headers come as name and value pairs, that a response leads with a status code. Every browser and every web server on earth implements that agreement separately, and they interoperate because they all read the same document.

That is the entire mechanism. Agree on the shape, and independent implementations connect without ever having been introduced.

The Model Context Protocol is that, applied to AI and tools.

Break the name into its three pieces and it explains itself. Model, the AI. Context, everything the model needs around it: the tools, the data, the instructions. Protocol, the agreed shape of the conversation between them.

MCP is a document that says: if you are an AI application asking for tools, here is exactly how you ask. If you are a system offering tools, here is exactly how you describe yourself and exactly how you reply.

Nothing more. That turns out to be enough.

Twenty-five becomes ten

Now redo the arithmetic with an agreement in place.

Each AI application implements MCP once. Not once per tool. Once, total.

Each system exposes itself over MCP once. Not once per application. Once, total.

Five applications plus five tools is ten pieces of work, and every application can reach every tool. The multiplication became addition.

Scale it and the gap becomes absurd. Ten applications and fifty tools: five hundred integrations before, sixty after. And the sixty are not merely fewer, they are differently shaped. Before, every integration was a private thing owned by whoever wrote it. After, the Gmail side is written once, by the people who actually know Gmail, and everyone uses that.

Which fixes the maintenance bill too. When Gmail changes, the Gmail MCP server gets updated by the Gmail team, and every application connected to it is fixed without anyone else touching anything. The repair happens once, at the source, by the people best positioned to make it.

Responsibility moved to where the knowledge already was.

This is why people call MCP the USB-C of AI. It is a good analogy for exactly one reason: USB-C did not make any device better. It made every device connectable, and the drawer of dead cables stopped growing.

The shape of the thing

The diagram everyone draws looks like a wheel. The AI application sits in the middle. Around it: a database, GitHub, Gmail, Slack, the local filesystem, web APIs. Every spoke is labeled MCP, because every spoke is the same connection.

That sameness is the whole point. The application does not know it is talking to Gmail. It knows it is talking to an MCP server that has announced some tools. Swap Gmail for Outlook and the application does not change, because the shape of the conversation did not change.

Underneath, the design has three roles.

A host is the application the person actually uses. A chat interface, a code editor, an agent runtime.

A client lives inside the host and holds one connection to one server. If the host connects to six servers, it runs six clients. Each connection is isolated from the others, which is a security decision as much as an architectural one: a server you connected for GitHub access has no visibility into the session your Gmail server is having.

A server is the thing that exposes capability. It might be a small program on your laptop reading local files, or a service running inside a company's network in front of its databases.

The conversation between client and server uses JSON-RPC 2.0, an old, boring, well understood way of saying "call this, with these arguments, here is the result." Choosing something boring here was correct. The interesting part of MCP is not the wire format, and a protocol that invented a novel one would have added risk for nothing.

What a server is allowed to offer

A server does not just expose functions. The spec defines three distinct things it can offer, and the distinction is more useful than it first appears.

Tools are actions the model can choose to invoke. Send the message, create the issue, run the query. These are model-controlled: the model decides when to use one, which means tools are where the consequences live.

Resources are data the server makes available for context. A file, a record, a document. These are meant to be application-controlled, selected and handed to the model rather than reached for by it.

Prompts are prepared instruction templates a server can offer, typically surfaced to the user as an explicit choice, like a slash command.

The split matters because it separates what the model may do from what the model may read from what the user deliberately invokes. Three different levels of risk deserve three different mechanisms.

There is also traffic in the other direction, which is the piece most explanations skip. A server can ask things of the client. Sampling lets a server request a model completion, so a server can use AI without shipping its own model or API key. Roots let a client tell a server which parts of the filesystem it is allowed to look at. Elicitation lets a server ask the user for information mid-task, instead of failing because a value was missing.

That last one quietly changes what a server can be. A tool that can pause and ask a question is not a function call anymore. It is a participant.

Two ways to connect, and why they exist

Transport is where the protocol touches physical reality, and MCP defines two.

stdio is the local one, and it is charmingly primitive. The client launches the server as a subprocess and they talk over standard input and standard output, the same pipes command line programs have used for fifty years. No ports, no network, no authentication layer, because there is no network to attack. If the server is a program on your own machine reading your own files, this is exactly right.

Streamable HTTP is the remote one, for servers that live somewhere else. It runs over normal HTTP with the option to stream responses back as they are produced, which matters because a tool call can take a while and silence is a bad user experience.

An earlier design used HTTP with a separate always-open event stream. It worked, but it required servers to hold long-lived connections, which is a poor fit for the serverless and load-balanced infrastructure most services actually run on. It was replaced. The protocol has gone through five dated revisions since it appeared, from that first 2024-11-05 release through to 2026-06-30, which is worth reading as a health signal rather than instability. The failure mode for a young standard is not changing. It is being frozen wrong.

Who made it, and why open mattered

MCP came out of Anthropic, designed by David Soria Parra and Justin Spahr-Summers, and was released publicly in late 2024. The first specification revision is dated November 5, 2024.

The important decision was not technical. It was that they gave it away.

MCP is an open standard. The specification is public, the schema is public, the reference implementations are open source. Nobody needs permission to build a server or a client, and nothing about it is tied to any one company's model.

That decision is the reason it worked, and it is worth being clear about why. A standard owned by one vendor is not a standard, it is a dependency with better marketing. Everyone else is being asked to build on ground the owner can move. The rational response is to wait, or to build your own, which is precisely the situation that created the problem in the first place.

By making MCP something anyone could adopt without asking, Anthropic made it safe for competitors to adopt.

They did, and quickly. Microsoft shipped MCP support in Copilot Studio on 19 March 2025. A week later Sam Altman announced OpenAI was adopting it, with their Agents SDK shipping support the same day. On 9 April, Demis Hassabis committed Google's Gemini models and SDK to it. By late May, Microsoft, GitHub, and OpenAI had all joined the protocol's steering committee.

Note the order. Microsoft adopted it before OpenAI did, and both adopted a protocol written by a company they compete with directly. That only happens when joining costs nothing and refusing costs something.

That is the only way addition ever beats multiplication. The agreement has to be one that everybody can join, including the people you are competing with.

Then Anthropic did the thing that actually settles the question. On 9 December 2025 they donated MCP to the Agentic AI Foundation, a fund established under the Linux Foundation, co-founded with Block and OpenAI. The protocol now sits in a neutral legal home. Anthropic cannot unilaterally change its licence, its trademark, or its governance, and the founding platinum members include AWS, Bloomberg, Cloudflare, Google, Microsoft and OpenAI alongside Anthropic itself.

That is what giving something away looks like when it is real rather than rhetorical. A company built a thing, watched it become infrastructure, and then gave up the right to control it, because a standard nobody can seize is worth more to everyone, including its author, than a standard one company owns.

What is actually different now

Step back from the mechanism and look at what changed.

Before, connecting AI to a system was a project. Someone scoped it, someone built it, someone owned it forever. The cost scaled with the product of your applications and your tools, and it compounded every time anything upstream moved.

After, connecting AI to a system is a configuration step. The server exists or it does not. If it does, you point at it.

That difference shows up as capability, not just savings. When integration is a project, you only connect the tools worth a project, which means the important five and nothing else. When integration is configuration, connecting the fortieth tool costs about what the fourth did. The long tail becomes reachable, and the long tail is where most of the actual work in a company lives.

It also changes who builds connectors. Before, the connector was built by whoever wanted it, usually someone who had to reverse engineer a service they did not work on. Now the best-positioned party writes it once, correctly, and maintains it as part of their product. The people who know the system are the ones describing it.

Where this goes

Two things follow from all of this, and neither is comfortable.

The first is that the bottleneck moves. When connecting things was hard, the hard question was "can we connect it." When connecting is easy, the hard question becomes "should this be connected, and what is it allowed to do." A model that can reach forty systems is a model that can make forty kinds of mistake at machine speed.

The specification takes this seriously enough to carry a dedicated security document, and reading its table of contents is instructive. It catalogs the confused deputy problem, token passthrough, server-side request forgery, session hijacking, compromise of a local server, OAuth redirect validation, and scope minimization. These are not exotic. They are the ordinary hazards of any system where one component acts on another's behalf with borrowed credentials, which is exactly what an AI agent is.

The protocol standardizes the plumbing. It does not decide what should flow through it. That judgment is still yours, and it is now the expensive part.

The second is more optimistic. Standards are boring and boring is the point. Nobody is excited about HTTP. Nobody thinks about USB-C. That is what success looks like for a protocol: it disappears, and the thing built on top of it is what gets attention.

The drawer of dead cables did not get organized. It got obsolete. One connector arrived, everything else stopped mattering, and within a few years the drawer was a curiosity.

That is the trajectory MCP is on. In a few years the interesting question will not be how AI connects to your systems. It will be assumed, the way a web page reaching a server is assumed. The interesting question will be what you were careful enough to let it touch.