The Model Context Protocol, or MCP for short, is the kind of acronym that makes most readers' eyes glaze over before the explanation even begins. That is a shame, because the idea behind it is unusually simple and unusually important.

Here is the one-sentence version. MCP is a shared way for AI models to talk to the other software they need to do real work — your files, your tools, your databases, your calendar — so that any model can talk to any tool without each pair needing a custom integration.

The problem MCP fixes

Before MCP, every model-and-tool combination needed its own bespoke connection. If you wanted your model to read from your project management system, somebody had to write a one-off bridge. If you wanted to switch models, the bridge often had to be rewritten. Multiply this across the dozens of tools any real organisation uses and you have a quiet, expensive mess.

MCP fixes this with the same move that protocols always make. It standardises the conversation. A tool implements MCP once and is then reachable by any model that speaks MCP. A model implements MCP once and can talk to any tool that speaks MCP. The integration matrix collapses into a hub and spoke.

What MCP actually looks like

In practice, MCP is two things. It is a wire protocol — a set of message shapes for "here is a tool you can call," "here is the result," "here is the context I have available" — and it is a set of conventions for how servers expose capabilities and how clients consume them. A simple call might look like this:

// Client requests a tool
{ "method": "tools/call",
  "params": { "name": "search_docs", "arguments": { "q": "MCP" } } }

// Server responds with a structured result
{ "result": { "content": [{ "type": "text", "text": "..." }] } }

That is mostly it. The protocol is intentionally boring. The interesting work happens in the servers people build on top of it — the file system server, the search server, the database server, the design tool server — and in the clients that compose those capabilities together.

Why this matters for builders

Three reasons. The first is leverage. If you are building agentic software, every MCP server you can plug into is a capability you do not have to build yourself. The second is portability. If you write your application against MCP, swapping the underlying model is a configuration change, not a rewrite. The third is composability. The whole ecosystem benefits when a useful new tool gets exposed as an MCP server, because every existing client gains access to it at once.

The integration matrix collapses into a hub and spoke. That is the whole game.

The boring infrastructure thesis

MCP is exactly the kind of thing the studio cares about. It is not a model. It is not a flashy demo. It is a piece of plumbing that, if it works, becomes invisible. The next decade of useful AI software will depend on a hundred pieces of plumbing like this — protocols, registries, adapters, evaluation harnesses, observability layers — doing their jobs quietly while everyone else looks at the model.

Boring is good. Boring stays up at 3 a.m. We are betting on boring.