Before the Model Context Protocol, every AI application that wanted to touch your systems did it bespoke: one integration for the assistant that reads your database, another for the one that files tickets, each with its own glue code, its own credential handling, its own quirks. Connect *M* AI applications to *N* systems and you are maintaining M×N integrations. MCP — an open protocol introduced by Anthropic and since adopted well beyond it — collapses that grid. A system exposes its capabilities once, through an MCP server; any MCP client (Claude Desktop, Claude Code, Cursor, VS Code, and a growing list of others) can then connect to it. M+N pieces instead of M×N.
How it works
The protocol is a client–server conversation. The client — the AI application — connects to one or more servers and asks what they offer. A server answers with three kinds of things: tools (actions the model may invoke: search these invoices, create this ticket), resources (content the application can read for context), and prompts (reusable templates the server suggests). Each tool carries a name, a description, and a parameter schema — and those descriptions are read by the *model*, not by a developer, which makes them an interface contract with a non-deterministic consumer and the single most underestimated part of building a server.
Two transports cover the deployment spectrum. stdio runs the server as a local child process of the client — the default for personal use, where the server inherits the laptop it runs on. Streamable HTTP makes the server a network service that many agents and people can share — at which point it needs authentication (OAuth in the specification), TLS, and the operational treatment of any other production service. The protocol's job ends at the conversation; everything about *where* the server runs and *what* it is allowed to do remains yours.
The server ecosystem
The protocol's traction is most visible in its long tail of servers: reference implementations for filesystems and databases, vendor-built servers for the major SaaS platforms, and community servers for nearly everything else — version control, project trackers, browsers, design tools, data warehouses. That breadth is the point of the standard, and it carries the standard's hazard: installing an MCP server is running someone's code with the credentials you give it. The ecosystem rewards the same discipline as any package registry — a reviewed allowlist, pinned versions, and the understanding that a server update can change tool descriptions and therefore change how every agent downstream behaves.
What MCP means operationally
It is easy to file MCP under developer convenience, and for a single laptop that is what it is. The operational story starts when agents depend on servers: at that moment each server is infrastructure — a process holding real credentials, standing between agentic systems and your systems of record. That position cuts both ways. The server is the natural enforcement point — the place to scope permissions tool by tool, cap what a call can return, and log every invocation with its caller, which is why it features in both the running and securing halves of this cluster. And the same position makes servers worth attacking: a compromised or merely careless server sits inside the trust boundary of every agent that calls it. The protocol gives you the standard interface; whether that interface is a control plane or a blind spot is decided by how you operate it.
A practical consequence worth planning for: MCP servers accumulate. Teams add them the way they add packages, and within a few quarters "which servers run where, holding which credentials, called by which agents" becomes a question someone urgently needs answered — usually during an incident. The catalogue step in the running guide exists for that day, and an agent inventory that ignores the tool layer is missing half the estate.