Model Context Protocol (MCP)

MCP standardises the link between a model-driven host and the tools it uses. A host application connects to one or more MCP servers, each of which exposes primitives the model can draw on: tools it can call, resources it can read, and prompts it can reuse. Messages travel over a defined transport (a local process over standard input and output, or a network transport such as streamable HTTP), which lets a single agent talk to many servers through one interface instead of a bespoke integration each time. The design goal is composability: a new capability becomes a new server, and the model discovers and calls it through the same protocol.

The security consequence is that a tool description and a server URL are now instructions the model trusts. Two problems follow. First, tool poisoning: the metadata a server advertises (a tool’s name and description) is read by the model, so a malicious or compromised server can hide instructions there, a form of injection through the tool layer rather than the user prompt. Second, authority: an agent connected to a server that can read files or call an API is only as safe as the permissions behind that server, and a non-human identity with a broad, long-lived token is a common weak point. From the offensive side, a connected agent inherits the blast radius of every server it trusts.

We assess an MCP-connected system as an agent plus its servers: which servers it trusts, what each is permitted to do, how their credentials are scoped and stored, and whether tool metadata can carry instructions the model will follow. Excessive agency (more connected capability than the task needs) is a finding in its own right. Each server is also part of the AI supply chain and is reviewed as such. This is part of how we test an agent and its connected tools.