What MCP Actually Is

Every couple of years something shows up wearing the word "standard" and promising to end integration pain forever. Most of them are a vendor's API with a press release stapled to it. So when the Model Context Protocol started getting attention in late 2024, the reasonable reaction was a shrug. A year and a bit on, the shrug looks wrong. MCP is one of the few of these that earned its keep, and it did so by being almost aggressively boring.

Here's the thing it actually solves.

The integration tax

Say you have a few models you care about — Claude, GPT, Gemini — and a pile of systems you want them to touch: your Postgres database, GitHub, a Slack workspace, an internal pricing API. Without a shared convention, each pairing is its own little project. Models times tools. Four models and ten tools is forty integrations, and every one of them rots on its own schedule. Change the pricing API's auth and you go patch it in four places.

This is the M×N problem, and it's the whole reason MCP exists. The pitch is to turn M×N into M+N: write one server that exposes the pricing API the MCP way, and any compliant client can talk to it. Build the client side once per model host, the server side once per system. The analogy people reach for is USB-C — one connector instead of a drawer full of adapters — and for once the analogy isn't doing too much work.

Anthropic published the protocol as an open spec in November 2024. The part that mattered was "open." By early 2025 OpenAI had added MCP support to its Agents SDK and ChatGPT desktop app, Google and Microsoft followed with their own tooling, and in December 2025 the project was donated to the Linux Foundation's Agentic AI Foundation. A protocol owned by one lab is a marketing asset. A protocol nobody owns is infrastructure. That shift is what made building against it a safe bet rather than a gamble on someone else's roadmap.

Three things a server can expose

An MCP server is a process that advertises capabilities. There are three kinds, and the distinction is worth getting right because people conflate them constantly.

Tools are functions the model can call to do something — run a query, open a pull request, send a message. They have side effects, or at least they're allowed to. This is the primitive everyone thinks of first, and it maps cleanly onto the function-calling most people already know.

Resources are data the client can read — a file, a database row, a document, the contents of a URL. The key difference from tools: resources are addressed by URI and meant to be application-controlled context, not model-triggered actions. Reading file:///logs/today.txt shouldn't book a flight.

Prompts are reusable templates the server offers — a pre-built "summarize this incident" or "review this diff" that the user can invoke deliberately. They're the least-used of the three, but they exist so a server can ship opinionated workflows, not just raw capability.

The split is a design stance: actions, data, and templates are different things with different trust profiles, so the protocol keeps them in separate lanes. A lazy server ignores the lanes and dumps everything into tools. That works, and it's also how you end up with a model that deletes a row when it meant to read one.

The wire is just JSON-RPC

Strip the diagrams away and MCP is JSON-RPC 2.0 over a transport. That's it. The client sends a request like {"method": "tools/list", ...}, the server answers with the tools it has; tools/call runs one. There's an opening handshake — initialize — where the two sides exchange protocol versions and declare which capabilities they support, and after that it's request/response with a few server-initiated notifications mixed in.

Because it's plain JSON-RPC, you can read the traffic. You can replay it. You can write a server in any language that can print JSON to stdout. No binary framing, no custom serialization, nothing clever. The protocol revisions are dated strings — 2024-11-05, 2025-03-26, 2025-06-18, and the first-anniversary 2025-11-25 release — and the date marks the last time a backwards-incompatible change landed. Boring on purpose.

Transports: where the bytes go

The same message format runs over two transports that matter.

stdio is for local servers. The client launches the server as a subprocess and talks to it over standard in and standard out. This is how the filesystem server on your laptop works — no network, no ports, the OS process boundary is the only thing between them.

Streamable HTTP is for remote servers, and it became the recommended remote transport in the 2025-03-26 spec, replacing the older HTTP+SSE approach. It's what lets an MCP server live behind a normal web stack — an endpoint, a load balancer, auth — instead of running on every user's machine. When people talked through 2025 about MCP "going remote," this transport is what they meant.

Pick stdio when the capability is genuinely local and per-user. Pick HTTP when one server should serve many clients.

What MCP is not

This is where the hype outruns the spec, so it's worth being blunt.

MCP is not a way to make bad APIs good. The protocol standardizes how a tool is described and called. It says nothing about whether the underlying tool is well-designed. Wrap a confusing 30-parameter endpoint in an MCP tool and you have a confusing 30-parameter MCP tool. The interface design problem doesn't vanish; it relocates.

MCP is not an agent framework. It doesn't plan, it doesn't loop, it doesn't decide anything. It's a connection layer. The model still does the reasoning; MCP just hands it a clean menu.

And MCP is not free of risk. A protocol that lets a model invoke tools on your machine is, by definition, an attack surface — a fact that 2025's run of MCP CVEs made very concrete. That's its own post.

So what is it, actually? A contract. A small, legible, vendor-neutral agreement about how a model asks for context and actions, so the asking only has to be built once. The reason to learn it isn't that it's brilliant. It's that it's good enough, and everyone agreed to it. In integration work, that combination is rarer than brilliance — and worth a great deal more.