MCP: what it standardises between AI, data and tools

On 25 November 2024, Anthropic introduced the Model Context Protocol, or MCP, as an open standard for connecting AI applications to systems where data and tools live. The original announcement began with a recognisable problem: every pairing of assistant and external source needed its own connector, which was hard to reuse and maintain.

MCP standardises a conversation between programs. It does not make a model reason better, decide which server deserves trust or grant permissions on its own. The official architecture documentation draws the boundary precisely: the protocol focuses on context exchange and does not dictate how an application uses its language model or manages the context it receives.

The transferable skill is to separate five layers that are often collapsed: connection, advertised capability, authorisation, model decision and real execution. Two systems speaking MCP proves protocol compatibility. Trusting an action still requires knowing who offers the tool, what it can do, which identity executes it and which control the application retains.

Three participants, one connection per server

The architecture distinguishes a host, client and server. The host is the AI application coordinating the experience and its policies. Inside it, an MCP client maintains a dedicated connection to one server. The server is the program exposing context or functions, whether it runs on the same computer or is hosted remotely.

If an editor connects one issue-tracking server and one file server, the host creates a client for each. That separation supports capability negotiation and isolates connections, but it is not an automatic security boundary. The host remains responsible for controlling what enters context, which tools are shown to the model, which actions are allowed and which results reach the user.

The USB-C analogy goes only so far: a common contract avoids designing a different cable for every product pairing. An MCP server, however, can supply text that influences a model or execute a function that changes the world. The provenance of descriptions, content and code therefore matters far more than it does for a physical connector.

Two layers: messages and transport

The data layer uses JSON-RPC 2.0 and defines requests, responses and notifications. It includes connection lifecycle, capability negotiation and shared primitives. The transport layer decides how those messages travel. Current documentation describes stdio for local processes and Streamable HTTP for remote connections, using POST with optional Server-Sent Events for streaming.

At startup, client and server exchange protocol version, implementation identity and capabilities. If they cannot agree on a compatible version, the connection should terminate. A notification then marks initialisation as complete. This sequence prevents a client from blindly invoking features the other side did not declare; it does not establish that a declared function is honest or safe.

Notifications can report, for example, that the tool list changed. The client can request it again and update its registry. That dynamism improves interoperability but requires a policy for capabilities that appear or change during a conversation: refreshing a list should not silently expand permissions.

Tools, resources and prompts are different primitives

A server can expose three central primitives. A resource supplies contextual data such as a file, schema or record. A prompt supplies a reusable template for structuring an interaction. A tool is an executable function: querying an API, writing a file, opening an issue or updating an order.

The client discovers tools with tools/list and can invoke one through tools/call using arguments that should match a schema. The tools specification supports structured and unstructured results. It also warns that behaviour annotations — such as claims that a tool is read-only or idempotent — must be treated as untrusted when they come from untrusted servers.

That warning reveals the correct boundary. The protocol transports a name, description, schema and result; it does not prove that “query” never writes or that “delete draft” can be reversed. A safe client needs its own policy, an allowlist of servers, input and output validation, confirmation for sensitive effects and records that reconstruct what happened.

What the client can offer in return

Direction does not always run from server to host. A client may offer sampling, so a server can request model generation without integrating a particular provider; elicitation, to ask the user for information or confirmation; and logging. These are negotiated capabilities, not rights any server acquires merely by connecting.

The official client concepts guide describes human controls around sampling and elicitation. Users can inspect and modify requests or responses and decline to provide information. Elicitation must not request passwords or API keys. The interface needs to identify which server is asking, why, and how the data will be used.

Roots let a client communicate directories within which a server should operate. The guide states the limit: roots express intended boundaries but do not enforce security restrictions. A local process with broad permissions is not confined because it received a directory list. Isolation must exist in the operating system, container or host policy.

Authorisation is not the same as connection

For remote servers, the MCP authorisation specification builds on OAuth and protected-resource metadata for authorisation-server discovery. Tokens must be intended for the corresponding MCP server. Passing a received token to a downstream API without validation is forbidden because it breaks audience boundaries, damages auditability and can turn the server into an exfiltration route.

Even with OAuth, implementations need least privilege. A token granted file, database and administrative access up front multiplies the harm if stolen. Separate scopes, short-lived tokens, per-client consent, exact redirect validation and credentials kept out of logs reduce the blast radius.

With stdio, a process runs locally and does not use the same remote authorisation flow. That does not make it harmless: it commonly inherits the privileges of the client launching it. Installing a local server means executing software. Its origin should be known, the full command reviewed, file and network access limited, and an isolated environment used where possible.

Risks the standard names but does not remove

The official security best practices describe confused-deputy attacks, token passthrough, session hijacking, requests to internal resources and local-server compromise. A malicious server may steer a client toward internal addresses during OAuth discovery; a local package may hide a damaging startup command; a result may contain instructions aimed at the model.

Mitigations live in the implementation: HTTPS for remote connections, destination and redirect validation, SSRF protection, unpredictable session identifiers, separate identities, sandboxing, visible approval and telemetry. MCP makes it possible to describe a connection consistently. It does not inspect server code, certify its publisher or replace authorisation at the final API.

There is also semantic risk. An authorised calendar server can return false data because of a bug; a model can choose the correct tool with wrong arguments; a tool can faithfully execute an instruction the user did not intend. Authenticity, accuracy, intent and permission are separate questions. An encrypted connection answers only part of them.

How to assess an MCP integration

First inventory participants and boundaries: host, clients, servers, transports and reachable data. Then list primitives and effects: which resources are read, which tools write, which prompts enter context and which client capabilities a server may request. Every sensitive tool needs an identity, scope, validation, confirmation and audit record.

Next test adversarial cases: a misleading description, out-of-schema parameters, a changing tool list, a result containing hostile instructions, a token for the wrong audience, an internal address during discovery and a local process trying to leave its authorised directory. Tests must observe the actual effect rather than trust annotations supplied by the server itself.

In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation. That governance change may help a shared standard, but it does not alter the technical test. MCP reduces bespoke connectors; trust is still constructed at every boundary. The durable question is not “does it use MCP?”, but “which capability is connected, under what authority, and what prevents untrusted input from causing an improper effect?”.