What is MCP?
Model Context Protocol - MCP for short - is an open standard for connecting AI assistants to the systems where work actually lives. Anthropic introduced it in late 2024 and released it under an open-source license so any model, any tool, and any application can speak the same protocol. Within a year it had been picked up by OpenAI, Google DeepMind, Microsoft, and most of the agent framework ecosystem.
The pitch is simple. Modern language models are good reasoners that, by default, know nothing about your files, your codebase, your databases, or your internal tools. MCP is the wire format that lets an AI app discover what those systems can do, ask them to do it, and read what they return - without each app reinventing the integration from scratch.
An open protocol that standardizes how applications provide context to LLMs.- modelcontextprotocol.io
The integration problem
Before MCP, every team building an AI feature had to solve the same plumbing problem twice. On one side, the model needed to call out to tools - a database, a ticket tracker, a file system, a calendar. On the other side, each of those tools needed a bespoke adapter for every model and every app that wanted to use it.
This is the M-by-N problem. With M models and N tools you end up writing M × N integrations, each one slightly different, each one rotting at its own pace. The end result was hand-rolled function-calling code inside every product, with no shared contract, no shared discovery mechanism, and no portability when a team wanted to swap out the underlying model.
MCP collapses that grid. Build one MCP server for a tool and every host that speaks MCP can use it. Build one MCP client into a host and it can reach every server in the ecosystem.
The USB-C model
The shorthand everyone reaches for is USB-C for AI. The analogy is precise enough to be worth keeping. USB-C is a connector and a protocol that decouples the device from the cable from the peripheral - a laptop does not care whether the thing on the other end is a monitor, a hub, or a phone, only that both sides speak the same standard. MCP plays the same role between AI hosts and the world they reach into.
Underneath, MCP is a JSON-RPC 2.0 protocol with a defined handshake, a defined capability negotiation, and a small, well-specified vocabulary of message types. The host advertises what it supports, the server advertises what it offers, and the two sides agree on a feature set before any real work happens.
Hosts, clients, and servers
MCP has three roles, and naming them correctly is half the protocol.
- Host - the AI application the user interacts with. Claude Desktop, an IDE plugin, a custom agent, an internal tool. The host owns the model and decides which servers it is allowed to talk to.
- Client - a connector the host maintains, one per server. The client speaks MCP on the host's behalf and keeps the connection state cleanly isolated from any other server the host is also using.
- Server - a lightweight program that exposes some capability over MCP. A server might wrap a database, a search index, a SaaS API, a local file tree, or a piece of custom business logic. It does not know which model is on the other end.
The separation matters. A host can connect to many servers at once, each one bringing its own narrow slice of context, and a single server can be reused unchanged across hosts written by completely different teams.
The three primitives
Every MCP server exposes some combination of three primitives. The split is deliberate - each one has a different control model and a different lifecycle.
- Tools - model-controlled. Functions the model can choose to call to do something: query a database, send a message, run a build. Each tool has a JSON Schema for its arguments and a description the model reads to decide when to use it.
- Resources - application-controlled. Pieces of context the host can pull in and hand to the model: a file, a database row, a wiki page, a log slice. The app decides what to include; the model just reads it.
- Prompts - user-controlled. Reusable templates a server publishes for the user to invoke - a code review, a release-notes draft, a triage workflow. Hosts typically surface these as slash commands or menu entries.
That three-way split keeps the protocol honest about who is in charge at each moment. The model can reach for tools on its own, but resources and prompts only enter the conversation when the app or the human chooses to pull them in.
Transports
MCP is transport-agnostic in spec and ships with two transports in practice.
- stdio - the host launches the server as a subprocess and they talk over standard input and output. Ideal for local servers running on the user's machine: a filesystem tool, a git wrapper, anything that should not leave the laptop.
- Streamable HTTP - the server runs as a regular web service the host connects to. This is the transport for remote, multi-user, authenticated servers - an internal company API, a hosted SaaS integration, a shared knowledge base.
Authentication for remote servers is layered on top of standard web primitives. The MCP specification defines an OAuth 2.1 flow so a host can ask the user to grant access to a server, get a token, and reuse it on subsequent connections - the same pattern any other modern web integration uses.
The ecosystem
Two things make the ecosystem feel large from day one. The first is the set of reference servers the MCP team maintains - Google Drive, Slack, GitHub, Git, Postgres, Puppeteer, a filesystem server, a fetch server, and a handful of others. They are not toys; they are the canonical examples anyone building a new server is expected to read.
The second is the SDK coverage. Official SDKs exist for TypeScript, Python, C#, Java, Kotlin, Rust, Swift, and Go, all maintained under the modelcontextprotocol GitHub organization. Whatever stack a tool is written in, there is a first-party SDK that handles the protocol details and lets the author focus on what their server actually does.
On the host side, adoption moved quickly. Claude Desktop shipped first. Claude Code, Cursor, Zed, and a long tail of IDE plugins followed. OpenAI added MCP support to the Agents SDK and ChatGPT. Google DeepMind committed to MCP for Gemini. Microsoft built MCP into Copilot Studio and the Agent Framework. By 2026 the question for a new agent-shaped product is no longer do we support MCP but which MCP servers ship in the box.
Where MCP isn't the answer
MCP is a context protocol, not an agent runtime. It does not orchestrate multi-step workflows, it does not own retries or backoff, it does not schedule jobs, and it does not decide how the model reasons about what to do next. Those are the job of the host - the agent framework, the IDE, the product code on top.
It is also not a replacement for retrieval. If your problem is find the right paragraph in a million documents, you still want a vector store, a search index, or a retrieval pipeline behind the scenes. MCP is the doorway the model walks through to ask for that paragraph; it is not the index itself.
And it is not a magic security boundary. An MCP server can do anything the process it runs as can do. Treating server permissions, network access, and user consent as serious surface area is on the host and the operator, not on the protocol.
Why teams adopt it
The honest reason is leverage. Every hour spent writing an MCP server is an hour that pays off across every host that speaks the protocol - and at this point, that is most of the serious ones. The same server that ships inside Claude Desktop also works in Cursor, in a custom internal agent, in ChatGPT, and in whatever the team decides to switch to next year.
For internal platform teams the calculation is sharper still. A single MCP server in front of a company's data warehouse, ticket system, or feature flag service replaces a dozen half-finished integrations scattered across product teams. The team that owns the system also owns the protocol surface that every AI tool inside the company uses to reach it - which is the right place for that decision to live.
MCP did not invent any of the underlying ideas. JSON-RPC has been around for two decades, capability negotiation is older than that, and tool-using assistants existed before MCP shipped. What MCP did was pick a small, opinionated subset, write it down, ship reference servers and SDKs in every major language, and convince the rest of the ecosystem to meet in the middle. That last part is the hardest, and the reason MCP is the protocol the field settled on.