A shared protocol standardised how models reach tools and data

A protocol for reaching tools and data

On 25 November 2024, Anthropic published the Model Context Protocol (MCP), describing it as a standard for connecting AI assistants to the systems where data lives, including content repositories, business tools and development environments. The release bundled an open specification and software development kits, local server support inside the Claude Desktop app, and a repository of pre-built servers for services including Google Drive, Slack, GitHub, Git, Postgres and Puppeteer. The stated problem was familiar to anyone who has wired a model into an internal system: each connection had been a one-off integration, and a shared protocol lets one server implementation serve many host applications instead of one bespoke pairing per tool. That framing describes an intent, not a measured reduction in effort; adoption in a given workflow is a separate question from the design goal.

Hosts, clients and servers over JSON-RPC

The specification, now developed under Linux Foundation governance, defines three roles connected by JSON-RPC 2.0 messages: a host application that starts a connection, a client connector inside it, and a server that exposes capabilities. It says MCP takes some inspiration from the Language Server Protocol, which standardised how editors add support for programming languages one implementation at a time rather than one per editor. A server can offer a client three kinds of feature: resources, meaning context or data for a person or the model to use; prompts, meaning templated workflows for a person to invoke; and tools, meaning functions the model can execute. That vocabulary is what an implementer builds against. It says nothing about what a particular server's tools actually do once connected, which still has to be read case by case.

What the specification leaves open

MCP standardises message shape, not safety. Its own security section states that the protocol “enables powerful capabilities through arbitrary data access and code execution paths,” and that while implementers should build consent flows and access controls, “MCP itself cannot enforce these security principles at the protocol level.” It also names a specific hazard: a tool's own description of what it does, supplied by the server, should be treated as untrusted unless it comes from a server the host already trusts, since that description can carry instructions aimed at the model rather than the person operating it. The project's repositories show many official SDKs and a community server registry, a measure of ecosystem size, not of how carefully any one server has been reviewed.

Questions to carry into your own evaluation

• Which servers a host connects to have been reviewed by someone other than the server's author?
• Does the host require explicit confirmation before a tool call that writes, deletes or sends data?
• Are a server's own tool descriptions treated as trusted input to the model, or as untrusted text?

MCP settled how a message between an assistant and a tool is shaped. It did not settle who should be allowed to send one, and that is the distinction worth keeping when a product describes itself as MCP-compatible.