MCP, explained for people who didn't read the spec

MCP went from a niche RFC to a default in about eighteen months. If you're shipping agents in 2026 and you don't have a position on it, you're already behind. This is the short, opinionated explainer we wish we'd had when we started.

It's also the protocol we used to ship our own Contract Validator MCP server, so we have skin in the game.

What MCP is, in one paragraph

The Model Context Protocol is a way for an AI agent to talk to tools, data, and services without anyone hand-coding the glue. The agent (the client) connects to an MCP server. The server exposes tools, resources, and prompts. The agent calls them. The result goes back into the conversation. That's the whole thing.

Think of it as USB for AI agents. Before USB, every peripheral had its own connector and driver. After USB, you plug in and it works. MCP is doing that for the integration layer between an LLM and the rest of your stack.

Why it won

Anthropic published MCP in late 2024 and open-sourced the spec. By mid-2025, OpenAI had announced support. Google followed with Gemini. Then Mistral. Then JetBrains and VS Code on the IDE side. By April 2026, Gartner was forecasting that 40% of enterprise apps will embed AI agents by year-end, and almost all of them assume MCP at the integration layer.

That kind of uptake doesn't happen because the spec is brilliant. It happens because the alternative was custom function-calling formats per provider, and everyone was tired of writing the same adapter four times.

Three properties made it stick:

• Provider-neutral. A server you write today works for Claude, ChatGPT, Gemini, and whichever model wins next year.
• Local-first. Many MCP servers run as a process on your machine. Your data doesn't have to leave the laptop to be useful to an agent.
• Composable. Agents can connect to multiple servers at once. The filesystem server. The Postgres server. The GitHub server. Your own bespoke server. The agent sees them all as tools.

What it actually looks like

An MCP server, at its simplest, is a process that speaks JSON-RPC. It announces what it offers (tools/list, resources/list, prompts/list), and the agent can then call those tools.

A small Postgres MCP server might expose:

{
  "tools": [
    {
      "name": "query",
      "description": "Run a read-only SQL query.",
      "inputSchema": {
        "type": "object",
        "properties": { "sql": { "type": "string" } },
        "required": ["sql"]
      }
    }
  ],
  "resources": [
    { "uri": "schema://public", "name": "Public schema" }
  ]
}

The agent reads the description, decides "I should query the database", and calls query with a SQL string. The server runs it (read-only, sandboxed), returns rows. The agent reasons about the rows. Done.

The interesting part is that the same agent, in the same conversation, can also call into the filesystem MCP, the Slack MCP, and your custom invoicing MCP. From the model's perspective they all look like tools.

What MCP is not

This is where most introductions stop. We'll keep going, because the false equivalences are where teams burn weeks.

MCP is not an agent framework. It tells you nothing about how to structure your agent's loop, manage state, plan, recover from errors. That's LangGraph, CrewAI, Claude Agent SDK, OpenAI Agents SDK. MCP just gives them tools to call.

MCP is not A2A (agent-to-agent). MCP is about the agent reaching down into tools. A2A is about two agents talking to each other, peer-to-peer. They're complementary. A multi-agent system in 2026 typically uses A2A for coordination and MCP for action.

MCP is not a transport security model. The spec is intentionally thin on auth and trust. If you run a third-party MCP server, you are giving it the same trust you'd give any other process on your machine. We've seen teams plug in random GitHub-published servers without auditing them. Don't.

Treat an MCP server like an npm package, not a web page. You're installing code that can be told to run almost anything by a model that's trying to be helpful.

Where it still doesn't fit

We've shipped real MCP servers, and we've also hit the edges. Three to flag.

Large data flows are awkward. MCP is great for "run this query and give me ten rows back". It's not great for streaming a 4 GB file through an agent. The model would re-read it on every turn. You need to keep big data outside the conversation and pass references.

Latency adds up. Every tool call is a round-trip. An agent that makes ten MCP calls to do one task feels slow. You'll want to design coarse-grained tools ("draft and send invoice") rather than ten fine-grained ones ("look up customer", "look up product", "compute tax", and so on) when the path is predictable.

Auth is your problem. The spec leaves it to the implementer. Production MCP servers should support OAuth, per-user tokens, audit logging, and a kill switch. The reference implementations don't always do this. Read the code before you trust it.

The practical advice

Three things we tell every team starting with MCP in 2026.

One: use existing servers for the boring stuff. Filesystem, Postgres, GitHub, Slack, Notion. Don't write your own when one already exists.

Two: write your own MCP server when your tool is genuinely your tool. Internal API, proprietary database, custom workflow. That's where the leverage is.

Three: keep the agent framework and the tool layer separate. If you stay disciplined about that boundary, swapping model providers later is a config change instead of a rewrite. That's the whole point of standardising on MCP.

The boring protocol always wins. MCP just happens to be that boring protocol for the agent era.