MCP specification: a plain-English guide

The MCP specification defines the messages, capabilities, transports and authorization rules of the Model Context Protocol. It is the source for implementation requirements, rather than a guarantee that every product supports every feature. The official current revision checked on October 14, 2026 is 2026-07-28; hosts, SDKs and deployed services can update at different times.

Use this guide to read the standard and identify compatibility questions. It is a plain-English map, not a replacement for normative text or a claim that AIPx implements the latest revision.

Model Context Protocol specification and source of truth

Start with the official specification. Its protocol schema defines message structures, while the surrounding text explains behavior and requirements. The official TypeScript schema is the source of truth for the protocol’s types; SDK convenience APIs are implementation interfaces layered on top.

A tutorial answers “how can I build this example?” A standard answers “what must conforming implementations do?” Both are useful, but they are not interchangeable. A successful sample can use only a tiny part of the protocol and tell you little about authorization, optional capabilities or compatibility paths.

Always retain the revision in your notes. A link to “latest” is convenient for discovery, but it can point to different content after an update. A date-specific reference lets a reviewer understand which behavior your example or integration was designed around.

The server introduction explains the roles before the low-level details. The architecture article shows where message behavior fits into the host’s model loop and the upstream application’s permissions.

MCP specification versions compared

The most useful immediate comparison is between the previous revision and the current one. It exposes why older code examples may look correct while describing a different flow.

Topic	2025-11-25	2026-07-28
Initial exchange	Initialization-based lifecycle	Per-request metadata and discovery
Protocol sessions	Connection/session-oriented behavior	Core protocol made stateless
Server discovery	Capabilities exchanged in older lifecycle	server/discover implemented by servers
Experimental tasks	Experimental core feature	Moved to an official extension
Roots, sampling, logging	Earlier feature mechanisms	Deprecated, with transition guidance
Client registration	Earlier registration mechanisms	Dynamic registration deprecated in favor of metadata documents

These differences follow the official change summary. Deprecated is not the same as removed: a transition window can preserve functionality while steering new implementations toward another approach.

Do not infer adoption from publication. A product may implement the older flow, an SDK may support both and a server may expose only some optional capabilities. A compatibility decision should record the versions and paths you actually tested.

What changed in 2026-07-28

At a high level, requests carry information needed for the protocol interaction instead of relying on the older initialization sequence. Discovery gives clients a way to inspect server support. This changes what a low-level sequence diagram should show, but it does not change the distinction between the host’s decision and the server’s execution.

A stateless core does not mean the application has no state. A long-running business operation can still have an explicit handle, an upstream object can still be mutable and a tool can still store data. The handle needs authorization just like an object identifier: possession of a string is not a sufficient business permission model.

Extensions are another important boundary. Moving experimental tasks out of core means support should be checked as an extension rather than assumed from general compatibility. The same approach applies to optional capabilities: the presence of one feature family does not establish support for another.

Implementation authors should read the complete change summary before migrating. Operators should look for the practical compatibility consequence: which host and server combination still works, what configuration must change and whether the SDK offers a legacy path. A protocol upgrade is not a reason to grant broader upstream scopes.

MCP transports and request metadata

Transport describes how messages move. Local stdio uses process streams; remote Streamable HTTP uses a service endpoint. The same conceptual tool operation can appear in either deployment, but process trust and remote authorization are different responsibilities.

Question	What to record
Which transport is required?	stdio, Streamable HTTP or explicitly legacy behavior
Which revision is implemented?	Date-specific protocol support, not just a marketing label
Which capabilities are needed?	Tools, resources, prompts and required optional features
Who authenticates the request?	Host, gateway, remote server and upstream service boundaries
What happens after a failed write?	Result interpretation and business retry policy

Per-request metadata belongs to protocol behavior, not ordinary tool arguments. Avoid hand-building envelopes by combining fields from tutorials written for different revisions. Use a current SDK and pin it for reproducible examples. The minimal server tutorial separates the SDK interface from the wire details.

Network retries need a business policy even when transport behavior is specified. If an HTTP response is lost after an upstream write, another request can duplicate the action. Check the destination state or use operation-specific idempotency before repeating it. A new request identifier is not automatically an idempotency key for the application’s business object.

MCP authorization and security rules

The standard’s authorization guidance concerns the client-facing protocol boundary. The upstream application’s OAuth grant or API key is another boundary. Validate the intended audience, issuer and account relationship rather than forwarding arbitrary tokens between services.

The official security guidance covers attacks arising from credentials, delegation and endpoint handling. A tool schema does not protect against a confused deputy or an overly broad upstream token. Read MCP OAuth for the protocol-specific authorization route and authentication for the wider agent context.

Untrusted content also remains untrusted after an authenticated read. A document or tool description can influence the model without being an instruction from the user. Review what the executor permits independently of what the model proposes. The security article explains concrete examples.

AIPx’s modes should be interpreted accurately in this context. Allow and Confirm are execution hints, with Confirm review dependent on the client honoring tool metadata. Hide is server-enforced and removes tools from the agent surface. The standard does not turn that product hint into a universal approval gate.

Optional capabilities and extensions

A server can provide tool operations without being a full-featured content or prompt service. A host can support one primitive better than another. The tools, resources and prompts guide describes these differences without assuming identical client UI.

For a required optional feature, ask three questions: does the server implement it, does the client support it and does the host expose behavior you can use? The protocol can permit a feature while a particular application has no usable interface for it.

Extensions add another compatibility dimension. Track the extension identifier and implementation requirements separately from core revision support. Do not describe experimental or specialized features as mandatory simply because they appear in an official documentation navigation menu.

An integration evaluation should therefore end with a small capability matrix. Record the host version, SDK/server version, transport, authorization method and required feature support. Include one representative successful request and a controlled failure. That evidence is more useful than a broad assertion that “MCP works.”

Reading MUST, SHOULD and MAY

Normative requirement words express different obligations. MUST indicates a requirement; SHOULD indicates a recommendation that needs careful reasoning when deviating; MAY indicates permission or an option. Read them in the context of the defined feature and revision rather than lifting one sentence into a general product claim.

For example, a server requirement to implement a discovery method does not imply every client must probe it before every operation. A recommendation about ordering results does not necessarily establish a hard failure condition. The standard’s exact wording matters when deciding conformance.

Keep implementation notes separate from editorial shorthand. An explainer can say “the current core is stateless” while an implementer still needs the precise metadata fields, error types and compatibility rules. Link the relevant revision so a reader can move from the concept to the normative definition.

When reviewing a vendor, ask for evidence of the behavior you require rather than treating specification publication as a vendor release note. For the gateway role itself, see MCP gateway. For remote deployment, see remote servers. The correct reference helps you identify what should happen; testing the chosen path establishes what actually happens in your setup.

Further reading

what is mcp.