MCP specification changes, explained

The Model Context Protocol (MCP) is the open standard that lets AI agents use tools and data: a calendar, a CRM, a database, a code repository. An MCP server offers the tools; the agent calls them through an MCP client. The standard is young, and every few months a new version of the specification changes what servers and clients have to do.

This tracker explains each version in plain language: what changed, why it matters, and what to check in your own MCP servers. Technical terms are explained in the glossary at the end. I update it when a new version is published.

As of 27 October 2026: the current version is 2026-07-28, the fourth since MCP got a standard way to sign users in, in March 2025. In short, MCP has moved from "paste an API key into a config file" to the same sign-in and permission model as any other enterprise API.

The short version

March 2025: a standard way to sign in

What changed. Until this version, MCP had no agreed way to authenticate users, and servers handled credentials their own way, often with an API key in a configuration file. Version 2025-03-26 adopted OAuth 2.1, the sign-in standard behind most web APIs, and made PKCE, a protection against stolen login codes, mandatory for every client. It also added tool annotations: labels saying whether a tool only reads data, may delete or overwrite something, can safely be repeated, or talks to the outside world.

Why it matters. Each user signs in as themselves instead of everyone sharing one key, and a client can ask the user before it runs a tool that changes data.

What to check. Remote servers use OAuth sign-in rather than shared keys, and every tool that writes or deletes is labelled as such.

June 2025: tokens locked to one server

What changed. An MCP server is now formally a resource server: it accepts access tokens but does not issue them. A separate identity provider can do that, and the server publishes where to find it. When a client asks for a token, it has to name the exact server the token is for, and the server has to reject tokens meant for anyone else. A server may not forward the user's token to other APIs it calls; it needs its own credentials for those. Tools can also declare the structure of their results, so the client can check them.

Why it matters. A token that leaks from one server cannot be replayed against another, the audit trail shows which system did what, and you can use the identity provider your company already has.

What to check. The server checks that each token was issued for it, and calls to other systems use the server's own credentials, never the user's token.

November 2025: least privilege by default

What changed. A server now tells the client which permissions, called scopes, an operation needs. If a call fails because a permission is missing, the client can ask the user to grant it, a pattern called step-up. Clients can identify themselves with a simple published description at a web address instead of registering automatically with every identity provider, and automatic registration became optional. Clients also have to confirm that the identity provider supports PKCE and use its secure variant.

Why it matters. An agent can start with read access and ask before it gets write access, which is what security teams want to see.

What to check. Scopes are narrow (read and write separate, destructive actions separate), and the server announces the scopes each operation needs.

July 2026: stricter checks and a simpler protocol

What changed. Automatic client registration is now deprecated. Clients must check that a sign-in response really comes from the identity provider they expected, which blocks so-called mix-up attacks, and must keep credentials separately for each identity provider. A server may show each caller only the tools their permissions allow. Tool definitions can use the full JSON Schema standard. And the protocol became stateless: there is no start-up handshake and no session ID, which should make servers simpler to run and scale.

Why it matters. Fewer ways to trick a client that works with several identity providers, and a read-only user never even sees a delete tool.

What to check. Tool lists are filtered by the caller's scopes, and nothing in your server depends on a session ID.

What has not changed

• Sign-in is optional. Servers that run locally on the user's machine still take credentials from the environment; the rules above apply to remote servers that implement sign-in (authorization).
• Tool labels are hints, not guarantees. Clients must treat them as untrusted unless the server is trusted (tools).
• A human can say no. The specification still says there should always be a human in the loop able to stop a tool call.

How to design tools against the current version is in MCP tool design: fewer, safer, testable tools; how to design permissions and delegation is in Delegated access for agents; where MCP fits in an agent's architecture as a whole is in Agentic AI from demo to production.

Glossary

Changelog

• 27 October 2026. First version, covering versions 2025-03-26 to 2026-07-28, with a glossary.

Sources

• Model Context Protocol: Versioning.
• Model Context Protocol changelog, 2025-03-26.
• Model Context Protocol changelog, 2025-06-18.
• Model Context Protocol changelog, 2025-11-25.
• Model Context Protocol changelog, 2026-07-28.
• Model Context Protocol specification, 2026-07-28: Authorization.
• Model Context Protocol specification, 2026-07-28: Tools.
• Model Context Protocol: Security best practices.