How to Read the MCP Specification (Without Being a Protocol Engineer)

Status in the 2026-07-28 spec: core (this page is about the specification document itself)

To read the Model Context Protocol (MCP) specification, start at the current version, 2026-07-28, read the overview and architecture pages first, and treat capitalized words like MUST and SHOULD as the actual rules. Everything else is explanation, examples or history.

The spec is long, but it is well organized. Once you know which pages are rules, which are guides and which are historical records, you can answer most questions in a few minutes.

This guide is a map. It is written for technical managers and developers who are new to MCP, and it reflects the spec as of October 2026.

What the MCP specification is

The MCP specification defines "the authoritative protocol requirements" for how AI apps talk to MCP servers. It is published on modelcontextprotocol.io and maintained in the modelcontextprotocol GitHub repository.

The prose pages are not the final word. The overview says the spec is "based on the TypeScript schema in schema.ts," and the base protocol page calls that schema "the source of truth for all protocol messages and structures." A JSON Schema version is generated from it automatically for tooling.

If you want our plain-English overview of the whole protocol first, read how MCP works.

Why it is written the way it is

The spec has to serve many independent builders: AI app makers, server authors, SDK maintainers and gateway vendors. They all need the same precise rules, so the spec uses formal language borrowed from internet standards.

The key words "MUST", "SHOULD", "MAY" and their negatives are "to be interpreted as described in BCP 14," the IETF convention, "when, and only when, they appear in all capitals." In plain English:

A lowercase "should" in a sentence is ordinary English, not a rule.

How the spec is organized

The base protocol overview lists the building blocks. It also says which ones are mandatory: "All implementations MUST support the base protocol, versioning, and the message patterns. Other components MAY be implemented based on the specific needs of the application."

Most pages also show small JSON examples. Here is the kind you will see everywhere in 2026-07-28: a request carrying its own version and capabilities in _meta, adapted from the discovery page.

{
  "jsonrpc": "2.0",
  "id": "discover-1",
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "ExampleClient", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Some examples are labeled "non-normative." Those illustrate a rule; they are not the rule.

A reading order that works

1. Overview and architecture. Learn the three roles and the security principles. See MCP hosts, clients and servers.
2. Base protocol. Learn the message shapes. See JSON-RPC in MCP.
3. Versioning. Learn how a request declares its version. See MCP server discovery.
4. Message patterns. Especially multi round-trip requests.
5. The features you actually use. Usually tools first, then resources and prompts.
6. Transports and authorization, if you run a remote server.
7. Changelog and deprecated registry, before any upgrade.

Versions, drafts and other documents

The site keeps every version online: 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25, 2026-07-28 and a draft. The versioning guide explains the labels. A revision is Draft (in progress), Current (ready for use, may still get backward-compatible fixes) or Final (complete and frozen). As of October 2026, 2026-07-28 is Current.

Version names are dates. The guide says a version identifier marks "the last date backwards incompatible changes were made." Our specification changelog summarizes each one.

Three other document types sit next to the spec:

• Learn and develop docs explain concepts and walk through code. They are helpful, but the spec is binding.
• SEPs (Specification Enhancement Proposals) record why a change was made. The SEP guidelines say Final SEPs "are not updated after finalization" and that "the current specification is authoritative."
• Extensions live in separate pages and repositories. The extensions overview says they are "always disabled by default." See how MCP extensions work.

What changed across versions in how you read it

Before 2026-07-28, you read the spec through the lens of a "lifecycle": an initialize handshake, then a session. The 2025-11-25 lifecycle page said initialization "MUST be the first interaction."

In 2026-07-28 that page is gone. Its replacement is the versioning and compatibility page, which says plainly: "There is no negotiation handshake." If a tutorial starts with initialize, it describes a legacy version.

The 2026-07-28 release also added a deprecated features registry. Check it before you build on any feature.

Common mistakes

• Reading the wrong version. Search engines often land on 2025-06-18 or 2025-11-25 pages. Check the date in the URL.
• Treating a SEP as current rules. SEPs are frozen once Final. One example: SEP-2567 mentions a messages/listen channel, but the shipped spec uses subscriptions/listen.
• Ignoring capitalization. "Should" and "SHOULD" are not the same thing.
• Assuming extensions are core. Tasks, MCP Apps and Skills over MCP are opt-in on both sides.
• Trusting one sentence over the schema. Small leftovers happen. As of 28 October 2026, the 2026-07-28 overview page still says extensions are "negotiated during initialization," while the versioning page and the extensions overview describe per-request negotiation. When pages disagree, check schema.ts and the more specific page.

Next step

Now that you know how the document is laid out, read the first technical layer: JSON-RPC requests, responses and notifications in MCP. You can also browse every topic from the MCP specification hub.

Frequently asked questions