MCP, Explained Without the Hype
A standard protocol for connecting AI models to tools and data is quietly reshaping the agent stack.
Reporter · · 3 min read

The Model Context Protocol (MCP) has quietly become one of the most consequential pieces of plumbing in the AI stack. In under a year it went from a single vendor's spec to something that looks a lot like a default — the way models reach out to the tools, files, and data that make them useful.
## What MCP actually is
Strip away the branding and MCP is a small, boring, well-scoped idea: a standard way for an AI application (the *host*) to talk to external capabilities (the *servers*) over a common protocol. A server exposes three kinds of things:
- **Tools** — functions the model can call (query a database, send an email, open a PR).
- **Resources** — read-only context the host can pull in (files, records, documentation).
- **Prompts** — reusable, parameterized templates a server can offer up.
The host speaks to servers over JSON-RPC, either locally over stdio or remotely over HTTP. That's the whole shape of it. The genius isn't the transport — it's the agreement.
## Why a protocol, and why now
Before MCP, every integration was bespoke. If you wanted your assistant to read from Sanity, or open a Figma file, or run a database query, someone wrote a one-off adapter against that app's SDK, wired it into one specific product, and moved on. The next product rebuilt the same bridge from scratch.
MCP collapses that N×M problem into N+M. Write one server for your product, and *every* MCP-compatible host can use it. Adopt the protocol in your host, and you inherit the entire ecosystem of servers other people have already written. That's the same trade that made the Language Server Protocol win for editors a decade ago, and it's why MCP spread the same way — fast, and mostly without anyone deciding to standardize on it.
## The parts that still hurt
MCP is young, and the sharp edges show:
- **Auth is the hard part.** Local stdio servers inherit your shell's trust. Remote servers need real authorization, and the OAuth story is only recently settling. Getting a token, scoping it, and refreshing it across a fleet of servers is where most real deployments spend their time.
- **Tool sprawl is real.** Connect a dozen servers and the model is suddenly staring at a couple hundred tools. Discovery, ranking, and lazy-loading of tool schemas — rather than dumping everything into context — is quickly becoming the difference between an agent that works and one that flails.
- **Trust boundaries are fuzzy.** A resource pulled from an untrusted server can carry an injection payload straight into your model's context. "It's just data" stops being true the moment that data is instructions.
None of these are fatal. They're the normal growing pains of a protocol that got adopted faster than it got hardened.
## Where this goes
The interesting bet is that MCP becomes invisible — the USB-C of agent tooling, the thing nobody thinks about because it just works. Registries of vetted servers, per-tool permissioning, and hosts that intelligently surface only the tools a given task needs are all arriving now. The protocol won't be the story for long. What people build on top of it will be.
We started *The Context Window* to cover exactly that layer: the unglamorous, load-bearing plumbing between models and the world. MCP is where we're beginning because it's where the most is being decided, quietly, right now.
More soon.