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 several AI apps — an editor assistant, a chatbot, a build bot — and several systems you want them to touch — your filesystem, GitHub, a database. To let each app use each system, someone has to write a custom connector for that specific pair. Three apps and three tools means nine connectors, each with its own quirks to maintain. Add a fourth tool and you owe three more; add a fourth app and you owe four 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 chatbot, because it was wired to one app's internals. Everyone reinvents the same bridges, slightly differently, forever.

MCP collapses M × N into M + N by putting a standard interface in the middle. It borrows the well-worn client/server model. The MCP client is the agent's harness — the program running the model. Each MCP server is a small, self-contained program that exposes exactly one capability: a filesystem server, a GitHub server, a database server. The client and server talk to each other in MCP's defined language: the server advertises what tools it offers and what inputs they take, and the client calls them in a uniform way.

Because the contract is standard, the pieces become pluggable. Write a GitHub MCP server once and any MCP-aware client can use it — no per-app rework. Point your agent at a new server and it gains that capability immediately, with no changes to the agent itself. The diagram below shows the shape: one agent acting as an MCP client, connected over the same protocol to several independent MCP servers.

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.