MCP Standardises the Interface, Not the Trust

The Model Context Protocol has become the default way to connect an agent to tools. That success has spread one misreading with it: that because the connection is standardised, it is also safe. The specification makes no such claim, and says the opposite in plain language.

What MCP is

MCP is an open protocol for connecting language model applications to external tools and data. The specification defines three roles:

• Hosts, the model applications that start connections
• Clients, the connectors inside a host, one per server
• Servers, which expose capabilities to the model

Servers offer three kinds of capability: tools the model can call, resources it can read, and prompts that act as reusable templates. Messages are JSON-RPC 2.0. The design borrows openly from the Language Server Protocol, which solved the same shape of problem for code editors: write the integration once and every compatible client can use it.

That is the value. Without a common protocol, every combination of application and tool needs its own integration. With one, each side implements it once.

What it standardises, and what it does not

Standardised by the protocol	Left to the implementer
Message format and transport	Whether a server is who it claims to be
How tools are listed and described	Whether a tool's description is honest
How tools are called and results returned	What a tool is actually allowed to do
Capability negotiation	Whether the user consented, and to what

Everything in the left column is about how two parties talk. Everything in the right column is about whether either should be trusted. The protocol covers the first and, by design, not the second.

The line the specification draws itself

This is not an outside criticism. The specification's security section says that "MCP itself cannot enforce these security principles at the protocol level" and asks implementers to build consent, authorisation and access control into their applications instead.

It is equally direct about tools. It says tools represent arbitrary code execution, that descriptions of tool behaviour should be treated as untrusted unless they come from a trusted server, and that hosts must get explicit user consent before invoking a tool.

Read together, those lines mean an MCP server is not a component you plug in. It is a party you decide to trust, with your agent's permissions.

Tool descriptions are prompts

The reason this matters is mechanical. To choose a tool, the model has to read its description, so the host places descriptions in the model's context alongside the system prompt and the user's message.

That makes every description a piece of text the model reads with the same weight as your instructions. A malicious server can put instructions in it. Invariant Labs showed this could be used to exfiltrate data and to override instructions tied to other, trusted servers connected to the same agent. OWASP now catalogues it as a named attack.

This is prompt injection that arrives through metadata rather than content, and it inherits the same core problem: the model cannot reliably separate instructions from data in a single text channel. A systematisation of MCP risks describes the result as a boundary between model error and security breach that dissolves once context can trigger actions.

One further detail makes it harder. Descriptions are fetched at runtime, and the protocol lets a server announce that its tool list has changed. A description you reviewed on day one is not guaranteed to be the one the model reads on day thirty.

What actually reduces the risk

The effective measures are the ones that limit what a trusted-by-mistake server can reach, rather than trying to detect a bad description.

Allowlist servers. Connect to servers you have chosen deliberately, and treat adding one as a security decision rather than a configuration change.

Treat descriptions as untrusted input. Review them, and review changes to them. A description that tells the model what to do with other tools is a red flag.

Scope per server. A server that reads calendars should not share credentials with one that sends email. Least privilege at the server boundary contains a poisoned tool to what that server could already touch.

Confirm consequential calls. Sending, writing, paying and deleting are the calls worth a human check, for the same reason checkpoints belong at side effects rather than reasoning steps.

You may not need MCP

If you have one application and a few tools you own, you probably do not need a protocol at all. Calling your tools directly through the model's function-calling interface is simpler, has fewer moving parts, and does not open a path for third-party descriptions into your context.

MCP earns its complexity when many applications share the same tools, or one application needs many tools maintained by different parties. Adopting it for three internal functions adds a surface without the payoff.

What we do not know

We do not know how the provenance problem will be solved at scale. Proposals exist, including cryptographic signing of tool definitions discussed in the security literature, but none is part of the core protocol today, and adoption across the ecosystem is uneven.

We are also reading one revision of a moving specification. Later revisions may add controls that change parts of this picture. The central point is unlikely to move, because it is structural: a protocol can standardise how parties talk, but deciding which parties to trust stays with you. As with compliance frameworks that pass while the gap stays open, conforming to the standard is not the same as being secure.

The figure in this note may be reused with attribution and a link to this page.