The Model Context Protocol

The Model Context Protocol, usually shortened to MCP, is an open standard that lets any AI model reach any external tool or data source through one common interface. Build a data source once as an MCP server, and every AI client that speaks the protocol can use it, without either side knowing anything special about the other.

The problem before there was a standard

Start with what an AI model can do on its own. A model that generates text is, at its core, a system that reads some input and produces likely output. Left alone, it knows only what it was trained on. It cannot look at the file open on your computer right now, it cannot query your company’s database, and it cannot run a command and see the result. To be useful for real work, it has to reach out of its own head and touch the world: read a document, call a service, search a codebase, send a message. Each of those things is a tool the model can be given.

The trouble is in how the tool gets connected. Suppose you are building an AI application and you want it to read from a database, a calendar, and a code repository. Each of those three systems speaks its own language. The database expects queries in one form. The calendar has its own way of listing events. The repository has its own commands. So you write three pieces of connecting code, one for each, and you wire them into your application by hand. That is workable for three. It stops being workable fast.

Now imagine the wider world. There is not one AI application, there are many: one company builds a coding assistant, another builds a research tool, another builds a customer support agent. And there is not one data source, there are thousands: every database, every internal service, every file store, every third party product. If every application has to write custom connecting code for every data source it wants to reach, the amount of work is the number of applications multiplied by the number of data sources. Ten applications and a hundred data sources is a thousand separate integrations, each written, tested, and maintained by hand. Most of them are never built, because nobody has the time.

This shape of problem has a name in engineering. It is often called the N times M problem: N things on one side, M things on the other, and a separate connection needed for every pair. The total work grows as the two numbers multiply. Any field that hits this wall eventually reaches for the same fix.

What a protocol actually is

A protocol is an agreed set of rules for how two parties talk to each other, so that either one can be swapped for a different party that follows the same rules. That is the whole idea, and it is worth being precise about, because the word sounds more technical than the thing it names.

Think about a wall socket. Any lamp with the right plug works in any socket in your country, and the lamp maker and the socket maker never spoke to each other. They did not need to. They both agreed to a standard about the shape of the plug, the spacing of the pins, and the voltage on the wire. The agreement is the protocol. Because it exists, a lamp is built once and works everywhere, and a house is wired once and accepts anything.

The same pattern runs under most of the technology you use. When your browser loads a web page, it speaks a protocol called HTTP to the server, and the two machines have never met. When two mail systems exchange a message, they follow an agreed set of rules so that a message written in one can be read by the other. In every case the protocol does the same job: it turns a private conversation, which only two specific parties can have, into a public one, which any party that learns the rules can join.

The payoff is exactly what breaks the N times M problem. Once there is a shared protocol, a tool builder writes to the protocol, not to any one application. An application builder reads from the protocol, not from any one tool. The multiplication collapses into addition. Each new data source is built once, against the standard, and it immediately works with every client that speaks the standard. Each new client is built once and immediately reaches every data source. The thousand integrations become a hundred servers and ten clients, and none of them had to know about the others in advance.

A protocol turns a private conversation, which only two specific parties can have, into a public one that any party willing to learn the rules can join.

How MCP applies this to AI tools

MCP is that shared standard, aimed specifically at the gap between AI models and everything they might want to reach. It defines a common way for a model’s application to ask, in effect, what can you do, and to then say, please do this one with these inputs, and to get back a result it can read. It does the same for data: a common way to ask what can I read, and to fetch a specific piece. Because the way of asking is fixed, the two sides do not have to be built for each other.

Consider what this means for a single well built data source. Say someone writes an MCP server that exposes a company’s issue tracker: the ability to search issues, read one, and list the comments on it. Before a standard, that connection would have to be rebuilt inside every AI product the company used. With MCP, the server is written once. From that day, a coding assistant can use it, a research assistant can use it, a chat interface can use it, and a tool nobody has invented yet can use it, all without the server’s author lifting a finger again. The server does not know or care which client is calling. It only knows the protocol.

This is why MCP servers have spread across very different clients. Anthropic’s own coding tool, Claude Code, speaks MCP. So does Cursor, an AI code editor built by a different company. So does Codex, and so do a growing number of other clients that were built independently. A server author writes to the protocol, and all of those clients come along for free. That breadth is not a happy accident. It is the direct result of choosing a shared standard over private connections.

The client and server shape

MCP is built on a familiar arrangement called client and server. The two words describe roles, not machines, and the roles are simple. The client is the party that wants something done. The server is the party that offers to do it. The client asks, the server answers. A web browser is a client and a website is a server. In MCP, the AI application is the client and the tool or data source is the server.

So in a concrete session, the coding agent you are talking to is the client. Each capability it has been connected to is a separate server. When the agent decides it needs to search your code, it does not run the search itself. It sends a request, in the shape the protocol defines, to the server that offers search. The server does the work and sends back a result in the shape the protocol defines. The agent reads the result and carries on. The division of labor is clean: the client decides what it wants and when, and the server knows how to do the thing it offers.

One useful consequence of this shape is that a server can live anywhere the client can reach. Some servers run as a small program on the same machine as the client, which matters when the data should never leave that machine. Others run on a remote computer across a network. The protocol is the same either way, so the client does not have to be rebuilt to talk to a local server versus a remote one. Where a server runs is a separate decision from how it is spoken to, and it is the subject of another concept in this hub.

A worked example: giving an agent a code graph

To make this less abstract, take a real kind of server. An AI coding agent is strong at writing and editing code, but on a large project it cannot hold the whole system in view at once, so it often guesses at how the pieces connect. What it lacks is a reliable map of the code: which function calls which, which file imports which, what a change would ripple into. That map is exactly the kind of thing a server can provide.

Koragraph MCP is such a server. It is a local MCP server that gives AI coding agents, including Claude Code, Cursor, Codex, and other MCP clients, a persistent, offline, multi repo code knowledge graph. Because it speaks the protocol, none of those agents had to be modified to use it. The agent stays a plain MCP client. Koragraph stays a plain MCP server. They meet in the middle, at the standard.

From the agent’s side, the interaction is ordinary MCP. It discovers that this server offers a set of tools, such as one to search the code and one to compute what a change would affect. When the agent needs an answer about the structure of the project, it calls the matching tool through the protocol and reads back the result. The agent does not need to understand how Koragraph builds the map, only that it can ask for the answer in the agreed way. That is the entire point of a protocol: the caller and the answerer can be built by different people, at different times, and still fit together.

Where it came from, and why open matters

MCP was introduced by Anthropic in November 2024. That origin is worth stating plainly for a second reason: it did not stay confined to Anthropic’s own tools. It was released as an open standard, meaning the rules are public and anyone may build to them without permission, and adoption has spread well beyond the company that started it. Clients and servers built by many different groups now interoperate because they share the specification.

Openness is what lets a standard actually become one. A protocol that only its author is allowed to use is just that author’s private connection with a fancier name. The value of the wall socket comes entirely from the fact that every lamp maker may use it freely. In the same way, MCP is useful in proportion to how many independent parties adopt it. Every new client that speaks it makes every existing server more valuable, and every new server makes every existing client more capable. That mutual reinforcement is what people mean when they call something an ecosystem, and it is only possible because no single party controls the door.

There is an honest limit to keep in view. A standard is a floor, not a ceiling. It fixes how parties talk, not how well any one of them does its job. A poorly built server that speaks perfect MCP is still a poorly built server. The protocol guarantees that pieces can connect, not that the connection is worth making. What it removes is the tax of custom wiring, so the remaining effort can go into the part that is actually hard: what each tool does and how well it does it.

Where this leads

Once you see MCP as a shared standard that pairs clients with servers, two questions follow naturally. The first is the mechanics of the pairing itself: what it means to be a client versus a server, how one finds the other, and why some servers are best run locally. That is the subject of MCP servers and clients. The second is what a server actually puts on the table once it is connected. A server does not offer one undifferentiated blob of capability; it offers a few distinct kinds of thing, and understanding them is the subject of Tools, resources and prompts. From there, the deeper question of how a model decides which tool to call, and when, is taken up in Tool use and function calling, which is where the protocol stops being plumbing and starts being behavior.