MCP Sampling Deprecation Migration Plan

MCP sampling deprecation changes who owns the model call in a server-side agent loop. Maintainers need to move from client reverse requests to direct provider integration without dropping consent, tool limits, trace continuity, or rollback.

This July 2026 update turns the specification change into a narrow migration adapter and test plan. It distinguishes documented protocol timing from local deadlines so teams can move quickly without inventing certainty.

Read MCP sampling deprecation as a boundary change

MCP sampling deprecation moves model invocation out of a server-to-client reverse request and into a server-owned provider boundary. Maintainers need a migration that preserves user control, tool authorization, and trace meaning while changing transport. This update maps the July 2026 transition into the smallest adapter, compatibility window, and rollback plan that can be tested without rewriting the entire agent loop.

Direct model integration moves credentials and provider retries behind the server boundary, while MCP reverse requests remain only in the measured compatibility cohort. Those phrases describe two execution shapes, not two names for the same transport.

The first migration inventory records every sampling request shape, model hint, tool boundary, consent prompt, and trace field used in production. That prevents a provider adapter from quietly dropping the human-control behavior that previously lived in the client. I also mark calls that never needed server-initiated sampling, because deleting an unnecessary loop is safer than preserving it behind a new abstraction.

Build the July 2026 compatibility timeline

The 2026-07-28 MCP release announces the specification change, and the release-candidate notes provide transition context. The earlier sampling contract remains useful for inventorying what existing clients do. Product deadlines must cite those texts instead of turning an internal target into a protocol guarantee.

The July 2026 release notes are the authority for timing, while the previous sampling contract remains the authority for the behavior being retired. I do not infer a guaranteed removal date where the release does not state one. Compatibility dates, client support, and rollout decisions stay distinct in the ledger so a planning assumption cannot masquerade as protocol text.

Runnable artifact: The provider-neutral fixture normalizes legacy and direct results while retaining consent and tool scope.

Save this proof as mcp-sampling-adapter.test.mjs and run node mcp-sampling-adapter.test.mjs. Expected final line: PASS: sampling migration equivalent.

import assert from "node:assert/strict";
	const normalize=x=>{assert.equal(x.consent,"approved","consent missing");return {purpose:x.purpose,consent:x.consent,tools:[...x.tools].sort(),text:x.text.trim()}};
const legacy=()=>normalize({purpose:"summarize",consent:"approved",tools:["read"],text:"ready"}); const direct=provider=>normalize(provider({purpose:"summarize",consent:"approved",tools:["read"]}));
assert.deepEqual(direct(x=>({...x,text:"ready"})),legacy()); assert.throws(()=>direct(x=>({...x,consent:"missing",text:"ready"})),/consent|missing/); console.log("PASS: sampling migration equivalent");

Replace reverse requests with a provider adapter

The adapter normalizes messages, approved tools, model class, consent outcome, and trace context before calling a direct provider. Credentials enter only inside the server-owned implementation. The surrounding MCP 2026 specification surface still handles tools and client communication, while the model loop becomes an ordinary dependency whose retries and timeouts the server can observe directly.

A direct-provider adapter accepts a narrow internal request containing messages, declared model class, approved tools, and trace context. The server-owned provider implementation adds credentials outside that object, streams normalized events back, and never exposes raw keys to the MCP client. Consent remains an explicit hook before consequential calls, even though the reverse-request transport has disappeared.

Preserve consent and trace equivalence

A migration is not equivalent if it produces similar prose while bypassing an approval or broadening tools. The fixture compares purpose, allowed actions, decision, normalized result, and terminal outcome across legacy and direct routes. The consent pattern from MCP elicitation UX remains relevant because transport simplification does not remove the human boundary around consequential model work.

Trace equivalence is semantic rather than byte-for-byte because providers frame tokens differently. The fixture compares request purpose, approved tool set, human decision, terminal outcome, and a normalized content transcript; latency and token accounting remain separate observations. A mismatch pauses the cohort instead of being hidden by a permissive normalizer.

Roll cohorts forward without split execution

Capability discovery selects legacy or direct integration once per task and stores that route in its trace. A task never switches midway after a transient error. Maintainers can follow MCP tasks for long-running tools for durable identity and MCP OAuth audience validation for exact resource binding while the sampling migration changes underneath.

Rollback keeps the legacy path behind a time-bounded flag only for clients still inside the documented compatibility window. New sessions select one route at startup and retain it for the task, which avoids crossing providers midway through an agent loop. The flag has an owner, removal date, traffic counter, and alarm if any unlisted consumer still depends on it.

Retire the compatibility flag with evidence

The final dashboard counts remaining legacy consumers, trace divergences, consent mismatches, provider errors, and rollback uses. A dated owner removes the flag only after all named clients have receipts. Future agent tool schema evolution should treat this adapter contract as versioned input, preventing the next protocol change from reopening an unstructured migration.

The migration receipt contains old request ID, new trace ID, consent outcome, provider route, normalized result hash, and any divergence classification. It deliberately excludes message bodies and credentials by default. That compact record is enough to compare behavior without turning observability into a second sensitive transcript store.

Normalize direct-provider failures

The adapter maps provider errors into stable application categories while retaining original codes for diagnosis. Retries reuse the same purpose, tool set, and consent receipt; they never broaden authority. Timeouts remain ambiguous until the provider trace is reconciled.

Provider failures are normalized into retryable, terminal, consent-required, and configuration categories without erasing the original code. A retry never expands tools or changes the approved purpose, and a provider timeout does not automatically fall back to the legacy client route. Keeping failure policy stable is part of proving the new loop behaves like the reviewed old one.

Close the sampling migration deliberately

MCP sampling deprecation is complete when legacy traffic reaches zero, rollback is rehearsed, trace parity passes, and maintainers have a dated support note. The old route is then removed. Keeping both loops indefinitely would preserve the operational ambiguity the migration was meant to eliminate.

The retirement review checks zero unapproved legacy traffic for the declared window, successful rollback rehearsal, trace parity for every named fixture, and a support note for downstream maintainers. Once the gate passes, the reverse-request branch is removed rather than left as a permanent dormant path. The migration ends with less protocol surface, not two agent loops forever.

MCP sampling deprecation should leave maintainers with one smaller, observable model boundary and no loss of consent. Complete MCP sampling deprecation by proving parity, rehearsing rollback, and deleting the legacy reverse-request branch on schedule.