Model Context Protocol (MCP)

What MCP is for

Before a shared protocol, every pairing of an assistant with a tool was its own integration, written twice and maintained forever: five assistants and twenty tools meant a hundred bespoke connections. MCP turns that into addition instead of multiplication. A tool author writes one server, an application author writes one client, and anything on either side can talk to anything on the other. Anthropic published it as an open standard in late 2024 and it has been adopted well beyond that since. It is closer in spirit to a device-driver interface than to a product API: the value is not what it can do, it is that everyone agreed on the shape.

The arrangement is client-server. The application holding the model is the client; each capability you want to expose runs as a server that describes what it offers in a machine-readable way, so the model can see the options and choose. It is transport-agnostic — a server can be a local process on the same machine or something reached over HTTP — which is why the same integration works in a desktop assistant, an AI agent running on a server, and a coding tool without being rewritten for each.

What a server exposes

A server offers three kinds of thing, and the distinction matters when you build one:

• Tools — actions the model can invoke: send a message, query a table, create a record. These are the ones with consequences, and the ones worth being careful about.
• Resources — data the client can pull into context: a file, a document, a row, the contents of a page. Read-only material the model is given rather than something it does.
• Prompts — reusable, parameterized instructions a person selects deliberately, rather than something the model reaches for on its own.

What the protocol does not solve

A connection standard removes the plumbing and leaves everything hard. The first thing you meet in practice is that tools are not free to have. Every capability a model can call must be described to it, and those descriptions occupy the same limited context as the work itself, so a large catalogue quietly competes with the task. We hit exactly this building agents for customers at AgentCeres — the AI Growth Officer at agentceres.com: past a certain number of available capabilities the catalogue has to be summarized to fit at all, which means each additional integration costs something even when nobody uses it. The engineering discipline turns out to be deciding what an agent should *not* be able to reach.

The second gap is authority. The protocol describes how to call a tool; it says nothing about whether this agent, acting for this customer, right now, should be allowed to. A tool that reads a spreadsheet and a tool that publishes to a company's social account are identical to the protocol and completely different to the business. That boundary belongs in your own product, which is why anything with a public consequence on our side waits behind an approval gate with a person on it, no matter how the capability was connected.