architecture

12 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

MCP 2026-07-28 is a stateless protocol

In the MCP specification version 2026-07-28, MCP is defined as a stateless protocol: every request is self-contained and carries its own protocol version and capabilities. MCP follows a client-host-server architecture built on JSON-RPC, where each host can run multiple client instances.

Client-to-server relationship is 1:1

In MCP, the host creates and manages multiple client instances, and each client communicates with exactly one server (a 1:1 client-server relationship). Clients route protocol messages bidirectionally, manage subscriptions and notifications, and maintain security boundaries between servers.

Host responsibilities in MCP

The MCP host process acts as container and coordinator: it creates and manages client instances, controls client connection permissions and lifecycle, enforces security policies and consent requirements, handles user authorization decisions, coordinates AI/LLM integration and sampling, and manages context aggregation across clients.

MCP base protocol components and what MUST be implemented

MCP consists of: Base Protocol (core JSON-RPC message types), Versioning and Compatibility (protocol version negotiation, extension negotiation, interoperability with earlier revisions), Message Patterns (request/response, multi round-trip requests (MRTR), subscribe and notify), Authorization (for HTTP-based transports), Server Features (resources, prompts, tools), Client Features (elicitation, sampling, root directory lists), and Utilities (logging, argument completion). All implementations MUST support the base protocol, versioning, and the message patterns; other components MAY be implemented based on application needs.

Source of truth: TypeScript schema and generated JSON Schema

The full protocol specification is defined as a TypeScript schema at schema/2026-07-28/schema.ts in the modelcontextprotocol/specification repository, which is the source of truth for all protocol messages and structures. A JSON Schema (schema/2026-07-28/schema.json) is automatically generated from the TypeScript source for use with automated tooling.

Feature lifecycle policy: Active, Deprecated, Removed with 12-month window

MCP adopted a specification feature lifecycle and deprecation policy defining the Active, Deprecated, and Removed feature states, a minimum twelve-month deprecation window, and a registry of deprecated features (SEP-2596).

MCP spec version 2026-07-28 authoritative source is schema.ts

The MCP specification dated 2026-07-28 states that it defines the authoritative protocol requirements based on the TypeScript schema in schema/2026-07-28/schema.ts in the modelcontextprotocol/specification GitHub repository. Implementation guides and examples live at modelcontextprotocol.io.

MCP uses JSON-RPC 2.0 between hosts, clients and servers

MCP uses JSON-RPC 2.0 messages to establish communication between three roles: Hosts (LLM applications that initiate connections), Clients (connectors within the host application), and Servers (services that provide context and capabilities).

Specification document structure for 2026-07-28

The MCP 2026-07-28 specification is divided into these sections: Architecture (/specification/2026-07-28/architecture), Base Protocol (/specification/2026-07-28/basic), Server Features (/specification/2026-07-28/server), and Client Features (/specification/2026-07-28/client), plus a Contributing page.

Server spec page layout (2026-07-28 revision)

In the MCP specification revision 2026-07-28, server features are documented under /specification/2026-07-28/server/ with sub-pages: prompts, resources, and tools.

Prompts are user-controlled

Prompts are designed to be user-controlled: they are exposed from servers to clients with the intention that the user explicitly selects them for use. This refers to who decides when the prompt is used, not who authors its content; prompt content is defined by the server. The protocol does not mandate any specific user interaction model (slash commands are one common pattern).

Resources are application-driven

Resources in MCP are application-driven: host applications decide how to incorporate context. Applications may expose resources via UI tree/list pickers, allow searching and filtering, or automatically include context based on heuristics or the model's selection. The protocol does not mandate any specific user interaction model. Each resource is uniquely identified by a URI (RFC 3986).

Give your agent this brain