What Is the Model Context Protocol (MCP)?

Every integration used to begin with a meeting between two specific parties who had to agree on everything before anything could work. A protocol is what you build so that meeting never has to happen again.

Before any standard existed for connecting language models to the systems they need, the first step of every integration was a calendar invite. Someone on the AI team would sit down with someone who owned the ticketing system, or the data warehouse, or the internal pricing service, and the two of them would negotiate a contract in the oldest sense of the word — what the model would be allowed to call, what shape the arguments would take, what came back, how errors were signalled, who would update the wrapper when the underlying API changed. The work that followed was not conceptually hard, but it was irreducibly bilateral. It could not be done by either party alone, and it could not be reused by anyone who had not been in the room. Multiply that by the number of systems a serious enterprise runs, and the bottleneck on putting models to work was never model capability. It was the sheer number of meetings that had to occur before capability could touch anything real.

The Model Context Protocol is best understood as the removal of that meeting. It is an open protocol that defines a common way for AI applications to connect to external tools and data — a shared vocabulary for how a program that hosts a model discovers what a given system can do, invokes it, and receives the result. Most descriptions stop there, at the level of plumbing, and in doing so they miss the only property that makes a protocol worth having. The interesting thing about MCP is not that it is a tidy way to expose a function to a model. It is that once the way is defined in public, the person exposing the function and the person consuming it no longer need to know each other exists.

A protocol decides who has to be present for a connection to exist

This is the definitional claim, and it is worth stating carefully because it applies to every protocol that has ever mattered. A protocol's real function is not to make a connection elegant; it is to remove parties from the list of people who must be present in order for the connection to happen at all. Before HTTP, publishing something meant reaching an arrangement with whoever would consume it. After HTTP, a person could put a document on a server for readers who did not yet exist, using software written by people they would never correspond with, and it would simply work — not because anyone coordinated, but because the terms of the interaction had been settled in advance, in the open, by neither of them. The agreement was moved out of the relationship and into the specification.

MCP does exactly this for the connection between a reasoning system and everything it needs to reach. When someone builds an MCP server for an internal document store, they are not building an integration with a particular assistant. They are declaring, in a form the specification defines, what the store can do: here are the operations that can be invoked, here is the data that can be read, here are the arguments each one expects. Any client that speaks the protocol can connect, ask what is available, and use it — including clients written after the server was finished, by teams the server's author has never heard of, for purposes nobody anticipated. The server author's obligations end at the boundary of the specification, and that boundary is the whole point. They have described their system to the world rather than negotiated with a counterparty.

The same asymmetry runs the other way, which is what makes the arrangement stable rather than merely convenient. Someone building an AI application implements the client side once and thereby acquires the ability to talk to every server that has ever been written or ever will be, without having to anticipate any of them. Neither side is designing for the other; both are designing for the protocol. That is a structurally different activity from integration work, and the difference shows up immediately in what kinds of things become possible. Under bilateral agreement, a connection exists only where two parties both decided it should. Under a protocol, a connection exists wherever two parties independently decided to conform, which includes the vast majority of pairings no one would ever have thought to arrange.

Why standardisation appears as an ecosystem rather than as a feature

If you evaluate MCP the way you would evaluate a product capability, you will conclude that it does very little. It does not make a model smarter, it does not add functionality that could not have been written by hand, and any single connection it enables could have been built without it, probably in an afternoon. Judged one integration at a time, a protocol always looks like overhead — a layer of ceremony wrapped around something you could have done directly. This is why protocols are consistently underrated at the moment of their introduction and consistently obvious in retrospect: their value is not located in any individual use, which is exactly where product evaluation looks.

What a protocol produces instead is a population. Because a server author can serve consumers they have never heard of, the incentive to write a server no longer depends on knowing who will use it, and the cost of writing one is amortised across every future client rather than charged to a single relationship. That inversion is what turns a specification into an ecosystem. Servers accumulate for systems whose owners had no particular AI project in mind, simply because describing your system in a public format is cheap and the option value is unbounded. Clients proliferate because implementing the protocol grants access to that accumulated population on day one. Neither growth curve requires a central party to broker anything, which is why the arrival of a working standard tends to look less like a feature launch and more like a sudden change in the weather.

The consequence for enterprises is that the shape of the integration problem changes rather than the difficulty of any one instance. The question stops being "which of our systems has someone connected to our AI stack" and becomes "which of our systems has been described in a way that anything can consume." Those sound similar and they are not remotely the same. The first is a project list with a finite, funded scope, and it decays every time a vendor changes or a team reorganises. The second is a property of the estate itself, and it holds regardless of what the organisation later decides to build on top of it — which is precisely the argument that runs through the literature on the autonomous enterprise, where the durable asset turns out to be the accessibility of the systems rather than any particular application built against them.

What this means for how you build

Once you take the definitional claim seriously, a number of practical judgements fall out of it. The value of exposing an internal system over MCP is not measured by the assistant you have in mind today, because the assistant you have in mind today is the least of what will eventually connect to it; the measure is how completely and honestly the system has been described. Design decisions that seem minor become consequential in that light — whether the operations you expose are the ones a reasoning system would actually want, whether the descriptions are legible to a reader with no institutional context, whether errors explain themselves to a caller who cannot ask you what went wrong. You are writing for strangers, which is a harder discipline than writing for a counterparty and a considerably more valuable one.

It also reframes what an AI platform is for. On the StudioX Enterprise AI Platform, MCP support is not a connector feature sitting alongside others; it is the mechanism by which Autonomous AI Workers reach systems that the platform's authors never enumerated, and Instant MCP exists to shorten the distance between an existing system and a description of it that anything can consume. The point of that tooling is not to enlarge a catalogue. It is to lower the cost of the only act that matters under a protocol — publishing a description — so that the number of systems a reasoning core can act against stops being a function of what anyone integrated on purpose.

The mental model worth carrying away is a question you can ask about any piece of infrastructure, not just this one. When you look at a connection between two systems, ask who had to be present for it to exist. If the answer names two specific parties who had to agree, you are looking at an integration, and its reach will always be bounded by the number of agreements anyone has the time to negotiate. If the answer is that both sides conformed to something neither of them owns, you are looking at a protocol, and its reach is bounded by nothing in particular. MCP is the second kind of thing, and every argument about what it enables eventually reduces to that one structural fact.