MCPs as the control plane of cognitive systems

Many practitioners still describe context protocols as an integration detail between tool and model. That reading underestimates the strategic role of MCPs. In serious architecture, the protocol is not just a connector. It defines the control plane through which identity, capability, resource, permission and execution flow are negotiated in an intelligible way. When that plane is absent, each integration creates its own semantics, its own risk surface and its own way of concealing failures. The result is operational fragmentation.

The importance of MCPs becomes clear when a system moves beyond isolated conversation into a mesh of agents, tools, memories and external services. In that environment the main challenge is not generating elegant text. It is coordinating access to distributed capability without losing predictability. An agent needs to know what it can call, under what contract, within what constraints and with what return shape. A well-designed protocol reduces improvisation without killing flexibility. It makes ecosystem expansion cumulative rather than chaotic.

The 2025-11-25 MCP specification defines three main transports. The stdio transport operates over stdin/stdout using JSON-RPC 2.0 with newline delimitation. It is the canonical option for local servers running as subprocesses. The HTTP with SSE transport uses GET for the server-to-client channel and POST for client-to-server, with the session identified by an endpoint URI returned in the initial handshake. Streamable HTTP, introduced in the most recent specification, resolves SSE limitations for long sessions with session resumption and stream upgrade.

MCP architecture is structured in three layers. The Host is the process that contains the LLM and accepts user interactions — Claude Desktop, VS Code with Copilot, or a custom application. The Client is the layer within the Host that initiates MCP connections and maintains one-to-one sessions with each Server. The Server is the process that exposes capabilities via the protocol primitives. This separation guarantees that the Host never accesses tools directly. All access passes through the contract negotiated in the initialization handshake.

Protocol primitives cover four functional domains. Resources expose structured data such as documents, code snippets, database entries or event feeds. Tools define executable actions the LLM can invoke with typed parameters and structured return. Prompts allow servers to offer reusable templates the Host can insert into conversations. Sampling inverts the flow: the Server requests the Host to execute an LLM inference with specific temperature and max_tokens parameters. This fourth primitive is what transforms MCP from an integration protocol into a genuinely agentic protocol.

Security in MCPs is fundamental and frequently neglected. The most critical vector is prompt injection via tool results. A malicious MCP server can return content instructing the LLM to execute unauthorized actions. The specification addresses this through tool annotations: readOnlyHint indicates the tool does not alter external state; destructiveHint signals operations with permanent effect; idempotentHint declares repeated calls produce the same result; openWorldHint indicates the tool accesses data that may contain arbitrary instructions. These annotations allow the Host to apply authorization policies before permitting invocations.

For remote servers, the MCP specification recommends OAuth 2.1 with PKCE. The flow begins with the Client sending an authorization request to the Authorization Server with a code_challenge using SHA-256. The Authorization Server issues a code that the Client exchanges for an access token using the code_verifier. The token is included in all subsequent requests as Bearer. Serious implementations also implement token rotation, where the access token has a short lifetime and is renewed via refresh token, keeping the session alive without constant reauthentication.

Tool schema validation is where the protocol becomes most demanding. Each tool declares its input schema as JSON Schema, ideally with additionalProperties: false to reject unexpected fields. The Host validates LLM arguments against this schema before transmitting the call to the Server. The Server validates again. This double validation creates defensive redundancy protecting against both malformed LLM outputs and malicious schema manipulation. Outputs can also be typed, although the current specification treats outputs as unified text, image or resource.

The Google A2A protocol complements MCP for agent-to-agent coordination. While MCP focuses on communication between a Host and its servers, A2A defines how autonomous agents discover each other, negotiate capabilities and delegate tasks via Agent Cards — JSON documents announcing skills, endpoints and authentication schemas. The eventual convergence of MCP and A2A will create a protocol mesh where MCP servers can also act as A2A agents, and vice versa. Architects who understand both protocols today will have significant advantage when designing multi-agent systems in production.

What distinguishes a well-architected MCP system from an ad-hoc integration is contract discipline. Each tool is an API with explicit guarantees. Each resource has declared scope. Each sampling request has justified parameters. That formality is not bureaucracy. It is what allows a cognitive system to scale beyond what a single human mind can control, while maintaining enough predictability for auditing and correction when errors occur.