MCP Protocol Updates: 2025–2026

The Model Context Protocol connects AI applications to tools and data. During this review window, it changed substantially: the November 25, 2025 release expanded workflows; the July 28, 2026 release redesigned the protocol around stateless requests. Both are released specifications, not merely roadmap proposals. (November release, July release)

Reviewed October 5, 2026. Coverage: October 5, 2025–October 5, 2026. This article follows those verified releases and explains their practical consequences. Earlier protocol behavior appears only as migration background; implementation support must be checked separately for each client and SDK.

TL;DR

The version changes above are documented in the July 2026 changelog.

Quick Example

Run this dependency-free Python 3 example to print a complete illustrative request body for the 2026-07-28 protocol. get_build_status is a fictional tool; this prints JSON without contacting a server.

For Streamable HTTP, the transport must additionally send matching MCP-Protocol-Version, Mcp-Method, and Mcp-Name headers, plus the required content negotiation headers. A maintained SDK should handle transport framing and authentication. This body is not a complete HTTP client. (2026 Streamable HTTP specification)

Core Concepts

Protocol versions and package versions differ

A protocol date describes a wire contract. An SDK package version describes a software release. Updating a package does not establish which protocol a particular remote peer supports. Keep a compatibility inventory containing host, client library, server library, supported protocol dates, and required extensions.

Capabilities are explicit

In 2025-11-25, initialization exchanges protocol versions and capabilities. In 2026-07-28, request metadata carries the version and client capabilities. Servers must implement server/discover, which clients may optionally call for server information. Do not send a July version string inside an old initialization flow and assume that creates compatibility. (2025 lifecycle, 2026 versioning)

Application state still needs an owner

The July protocol removes connection-level sessions, but an application can still maintain a shopping basket or browser workspace. Represent such state with explicit tool arguments and authorize access to each object. A visible identifier helps tracing; possession alone should not grant access. (July release explanation)

What November 2025 Added

Tasks for work that outlasts a request

November introduced experimental tasks: a receiver could return a task identifier, expose execution status, and retain a result for later retrieval. Support was negotiated for specific request types. Clients could poll status and retrieve the completed payload through tasks/result. (2025 Tasks specification)

For a report generator, distinguish “accepted” from “finished” in the interface. Record the task identifier with the initiating user and business operation. Decide how expired results, duplicate submissions, and cancellation appear before making the feature available.

URL elicitation and authorization discovery

URL-mode elicitation added an external browser interaction for sensitive steps. Form elicitation must not collect passwords, access tokens, API keys, or payment credentials. Clients must identify the requesting server and obtain consent before opening the destination. (2025 elicitation specification)

The authorization specification also supported HTTPS Client ID Metadata Documents and OpenID Connect discovery. Metadata documents describe a client through a URL; they do not replace user consent or turn a public client identifier into a secret. (2025 authorization specification)

Sampling gained tool support

November added tools and toolChoice to sampling requests, allowing server-directed model work to include tool use through a supporting client. This historical capability needs a migration caveat: Sampling was subsequently deprecated in July 2026. (2025 sampling, 2026 deprecations)

What July 2026 Changed

Requests became self-contained

The new transport contract removes the protocol session and initialization handshake. Request metadata carries the context needed to interpret each message. This makes request routing easier, but does not eliminate application databases, authentication, or background job storage. (2026 transport overview)

User input moved to a retry flow

Multi Round-Trip Requests replace independent server-initiated requests with an interim input_required result. The client gathers the requested input and retries the original operation with inputResponses. (MRTR specification)

For a destructive operation, make the authorization decision and the requested action unambiguous. A confirmation for deleting three named files should not become permission to delete a changed selection after a retry. This is application design advice, not a guarantee supplied by the protocol.

Tasks moved into an extension

July moved Tasks out of the experimental core. Its revised design uses polling through tasks/get, introduces tasks/update, and removes the earlier tasks/list and blocking tasks/result interfaces. A November implementation therefore needs explicit migration work. (2026 Tasks extension)

Best Practices

Migrate one observable workflow first

Start with a read-only operation such as build-status lookup. Capture the selected protocol, operation identifier, duration, and outcome. Compare behavior across the actual hosts your team supports before migrating a tool that changes production data.

Separate transport retries from business retries

Document whether retrying an operation can create another invoice, deployment, or report. Use a server-side operation key where duplicate execution matters. Test interruption after the underlying action succeeds but before the response reaches the client.

Budget for deprecated features

The formal lifecycle policy normally requires at least twelve months between deprecation and removal; active security risks can use an expedited process with a ninety-day minimum. Deprecation creates migration time; it does not promise permanent availability. Track each dependency and its replacement in your integration backlog. (Feature lifecycle policy)

Comparison

These differences summarize the versioned July changelog; they do not establish support in every product.

Common Mistakes

Treating an SDK upgrade as a completed migration

Bad: Change a dependency and exercise one successful tool call.

Correct: Verify both supported protocol paths, authorization, user decline, interrupted responses, and task completion with your deployed clients.

Treating task creation as success

Bad: Tell the user their export is ready when the server returns a task identifier.

Correct: Show pending status and inspect the final result before offering a download. In July's extension, a completed task can still contain a tool result with isError: true. (Task status definitions)

Mixing examples from different revisions

Bad: Combine November initialization code with July task methods.

Correct: Label examples by protocol date and follow one coherent versioned contract.

FAQ

Is the November 2025 specification the newest release covered here?

No. This article also covers the released July 28, 2026 specification. Avoid interpreting older documentation's “latest” label without checking its version. (July release)

Does stateless MCP mean my service cannot store anything?

No. The protocol's request contract and your application's storage are separate concerns. Keep durable state where the application needs it, with explicit ownership and access checks.

Should a new integration depend on Sampling?

The July revision deprecates Sampling and recommends direct model-provider integration for new implementations. Existing integrations should plan migration against the applicable lifecycle policy. (2026 deprecations)

Related Topics

References