Model Context Protocol (MCP)

Model Context Protocol standardises how an LLM-based client discovers and invokes external capabilities. Before MCP, every integration between a model and a tool was bespoke. An MCP server exposes a defined set of tools (callable functions) and resources (data) through a common interface; any MCP-compatible client can connect to any MCP server without custom integration code.

The standardisation that makes MCP useful for developers also creates a new, standardised attack surface. Tool descriptors — the name, description, and parameter schema an MCP server publishes for each tool — are read by the LLM to decide when and how to invoke a tool. A descriptor from an untrusted or compromised source is a direct injection vector: the description is treated as authoritative by the model, not merely as metadata.

MCP-specific review areas: authorisation (does each client-tool pair carry a scoped, revocable credential, or a single full-access token?); descriptor sourcing (is each tool descriptor's origin trusted and its integrity verified in transit?); transport security (is the connection encrypted and mutually authenticated?); and logging (can every tool invocation be attributed to a client, a session, and an input?).

MCP security splits into two layers that solve different problems: runtime tools (gateways, traffic-inspection proxies) monitor live MCP traffic and enforce policy as it happens; design-time review assesses the deployment's authorisation model, descriptor sourcing, and transport configuration before it reaches production. A mature MCP security posture needs both — a design-time review catches architectural gaps a runtime tool never sees.

MCP adoption has moved faster than MCP security tooling. A security review of any AI system that connects to an MCP server should treat the MCP boundary as its own attack surface, not fold it into a generic 'third-party API' risk category — the tool-descriptor and authorisation-scoping risks are specific to this protocol.