What is MCP (Model Context Protocol)?

An AI agent is only as useful as the things it can reach. A model that can read your files, open pull requests, and query your database is in a different league from one that can only chat. But every one of those abilities is an integration — a bridge between the agent and some external system — and for a long time each bridge had to be built by hand.

MCP, the Model Context Protocol, is the standard that ends the hand-building. It is an open specification for how an agent connects to external tools and data sources, so that connecting a new capability becomes a matter of plugging it in rather than writing fresh glue code.

Picture the world before any standard. You have three AI apps — an editor assistant, a chat app, a CI bot — and four systems you want them to touch: your files, GitHub, a database and a ticket tracker. To let each app use each system, someone writes a custom connector for that specific pair. Three apps and four tools means twelve connectors, each with its own quirks to maintain. Add a fifth tool and you owe three more; add a fourth app and you owe five more. This is the M × N problem: the integration work multiplies instead of adding up.

The deeper issue is that none of that work is reusable. The clever GitHub connector you wrote for your editor assistant does nothing for the chat app, because it was wired to one app's internals. And when GitHub changes its API, every app's copy breaks separately, so three teams fix the same thing three times.

Step through the wiring below. Predict how many connectors it takes before you look, then flip to the shared protocol and watch the same two changes — a new tool and a changed API — land again.

MCP collapses M × N into M + N by putting a standard interface in the middle. It borrows the well-worn client/server model. The host is the AI app you run, and inside it an MCP client speaks the protocol. Each MCP server is a small, self-contained program that exposes one capability: a files server, a GitHub server, a database server. Servers can run as a local process on your machine or as a remote service, and the protocol is the same either way.

A server offers a few kinds of things. Tools are actions the model can ask for, like get_issue or read_file; each comes with a name, a plain-language description and a schema for its inputs. Resources are data the host can read into the model's context, like a file or a database schema. (Servers can also offer reusable prompt templates.)

A conversation runs in three moves:

1. Discover. When the host connects, the client asks each server what it offers. The tool names and descriptions go into the model's context, so the model now knows what it could do.
2. Call. When the model decides a tool would help, it doesn't make a network request. It asks for a tool by name, with arguments. The client routes that request to the server that owns the tool, and the server does the real work — calling GitHub's API with its own credentials, say.
3. Return. The server's result flows back through the client into the model's context, and the model carries on.

Because the contract is standard, the pieces become pluggable. Write a GitHub MCP server once and any MCP-aware host can use it, with no per-app rework. Point your agent at a new server and it gains that capability immediately, with no changes to the agent itself.

Step through one conversation below. You'll be asked what happens when a user's question needs a tool. Then a new, unvetted server joins, and you'll see why the last step matters.

Connecting a server is often one line of configuration, which makes it easy to forget what you're agreeing to. A server is code you run: a local server runs on your machine with your permissions, and a remote one acts with whatever credentials you hand it. It is also text your model reads: its tool descriptions and every result it returns land in the model's context, right next to your instructions.

That second point is the subtle one. A model can't reliably tell a result that contains data from a result that contains instructions. If a server — malicious, compromised, or just relaying a web page someone else wrote — returns text that tells the model to read a secrets file and pass it along, nothing in the protocol stops the model from trying. The protection has to come from around the protocol:

• Install servers you trust. Check who publishes a server and what it does, the way you'd vet any dependency.
• Give each server the least access it needs. A read-only token, one folder rather than your whole disk, one repository rather than the organization.
• Require approval for anything with side effects. A host that shows you read_file(.env) before running it turns a silent leak into a question you can say no to.

The word that does the heavy lifting in "Model Context Protocol" is protocol. Like USB for peripherals or HTTP for the web, a shared protocol turns a tangle of private arrangements into an ecosystem. Tool builders can publish one MCP server and reach every compatible client; client builders get instant access to a growing catalog of servers they didn't have to write. The network effect compounds — each new server makes every client more capable, and each new client makes every server more worth building.

It's worth being clear about what MCP isn't, though. It doesn't make the model smarter, and it doesn't decide anything on its own — it's plumbing. The agent still reasons about when to reach for a tool and what to do with the result; MCP just standardizes the pipe between them. That separation is exactly why it's useful: the protocol stays simple and boring, and all the interesting behavior lives in the agent and the servers it can now reach.