A language model on its own is a brain in a jar. It can reason beautifully about your problem — but it can't see your files, query your database, open a ticket, or check today's calendar unless something connects it to those things. For the last few years, that 'something' was a pile of one-off integrations: every AI app hand-building a custom bridge to every tool it wanted to touch.

MCP — the Model Context Protocol — is the standard that replaces that pile with a single, common port. If you've heard it called 'USB-C for AI,' that's exactly the idea.

The problem it solves

Imagine M AI applications that each want to connect to N tools — your code repo, your docs, your CRM, your database. Without a standard, that's M × N bespoke integrations to build and maintain. Add one new tool and every app has to write a fresh connector; add one new app and it has to re-integrate everything from scratch. It doesn't scale.

A shared protocol collapses that. Each AI app implements MCP once; each tool exposes itself over MCP once; and now anything speaks to anything. It's the same move that the Language Server Protocol made for code editors, or that USB-C made for chargers — turn a mess of private connectors into one public standard.

How it actually works

MCP has two sides:

• The MCP client lives inside the AI application (a chat app, an IDE, an agent). It's the model's side of the conversation.
• An MCP server wraps a specific capability — a filesystem, a GitHub account, a Postgres database, a Slack workspace — and exposes it in a standard shape.

Those servers offer three kinds of thing:

• Tools — actions the model can take (run a query, create an issue, send a message).
• Resources — data the model can read for context (files, records, documents).
• Prompts — reusable templates a server can offer to guide common tasks.

The model, via its client, can discover what a server offers and use it — calling a tool, pulling a resource — all through the same protocol regardless of what's on the other end. Servers can run locally (talking over standard input/output) or remotely (over HTTP), so the same model can reach both a file on your laptop and a service in the cloud.

Why it caught on

Three reasons MCP spread faster than most standards:

• It's open. Introduced by Anthropic but published as an open spec, not a walled garden — so anyone can build a client or a server, and no single vendor owns the ecosystem.
• Connectors are reusable. Write an MCP server for your internal database once, and every MCP-compatible AI tool your team uses can reach it. That write-once-use-everywhere economics is what drove a rapid bloom of community and official servers.
• It matches where AI is going. As models shift from chatbots to agents that take real actions, the bottleneck stops being intelligence and becomes access — safe, structured connection to the systems where work actually happens. MCP is plumbing for exactly that.

The bigger picture

MCP sits alongside other quiet standardisation efforts — like the open Agent Skills format — that are turning a field of incompatible demos into something you can build on. Skills package know-how; MCP packages access. Neither is flashy. Both are the kind of unglamorous interoperability that decides which technologies actually last.

If agents are going to do real work in the real world, they need a standard way to reach it. MCP is the leading answer.

Sources: Model Context Protocol — official site & spec, Anthropic — introducing the Model Context Protocol.

— Relay