Your MCP integration is live, your tools are responding, and your AI agent pipeline feels solid. Then the MCP 2026-07-28 specification formally deprecates four features your implementation almost certainly uses: Roots, Sampling, Logging, and the legacy HTTP+SSE transport. The MCP spec deprecated features list just got long enough to create real migration work, and the countdown has already started.
This is not a theoretical risk. Tier 1 MCP SDKs across TypeScript and Python have each crossed 1 billion total downloads, with close to half a billion downloads a month across all Tier 1 SDKs. That's a massive installed base, and a significant fraction of it is running code that now carries a formal expiration date.
Here's what the spec actually says, what you need to migrate, and how to prioritize your work before SDKs start removing support.
What did the July 28 spec actually change?
The 2026-07-28 release formalizes two parallel changes. First, SEP-2577 deprecates Roots, Sampling, and Logging. Second, SEP-2596 introduces a formal feature lifecycle policy with Active, Deprecated, and Removed states, and retroactively reclassifies the legacy HTTP+SSE transport under that policy. Before July 28, deprecations were informal notes buried in changelogs. Now they carry a binding minimum twelve-month window between deprecation and earliest removal.
The release candidate was locked on May 21, 2026, by lead maintainers David Soria Parra and Den Delimarsky, with a ten-week validation window for Tier 1 SDK maintainers running to July 28. That process gave the ecosystem time to ship migration-ready SDKs before the spec dropped, which means the tooling is ready. The question is whether your integration is.
What does "deprecated" actually mean for running code?
Nothing breaks today. Per SEP-2577, deprecated features will remain fully functional in all specification versions released within one year of the 2026-07-28 version's release date. During that window, wire-level behavior is unchanged: no types are removed, no capability negotiation changes, and no existing implementations break.
What does change is the social contract. SDK maintainers are now free to mark deprecated APIs as [Obsolete], suppress them from documentation, and eventually remove them in the first major version released after July 28, 2027. If your codebase depends on any of the four deprecated features and you haven't migrated by then, you'll be pinned to an old SDK version while the ecosystem moves on around you.
Why did Roots, Sampling, and Logging get cut?
Each feature was deprecated for a distinct reason, and understanding the reasoning tells you how urgently you need to act.
Roots: useful in theory, niche in practice
Roots allowed clients to tell servers which file system locations were relevant to a session. According to lead maintainer David Soria Parra, it was "a very niche thing." Most real-world MCP servers never needed to know about client file system context because they either scoped their own data or received relevant paths as tool parameters. If your server uses Roots, the migration is straightforward: pass file paths or resource URIs as explicit tool parameters instead.
Sampling: conceptually clever, operationally painful
Sampling was the feature that let an MCP server ask the client's model to generate a completion mid-session. David Soria Parra described it as something that "seemed useful at the time but turned out to be used rarely," adding that "the semantics were confusing and hard to implement." Its replacement is Multi Round-Trip Requests (SEP-2322): a server returns an InputRequiredResult carrying inputRequests plus an opaque requestState; the client gathers answers and re-issues the original call with inputResponses, keeping all state in the payload rather than a held connection. This is a meaningful architectural change if you depend on Sampling heavily.
Logging: noisy and redundant
Logging was deprecated for being excessively chatty; it piped server-side log messages through the MCP protocol channel itself, which added overhead and made structured observability harder. The recommended replacements are stderr for stdio transports and OpenTelemetry for anything requiring structured, queryable logs.
Not sure which MCP-adjacent capabilities your site already exposes to AI agents? Faro's AI Readiness Scan checks your configuration across 38 signal categories, including transport and API discoverability, and gives you a prioritized fix list in minutes.
What is replacing each deprecated feature?
The table below maps each deprecated feature to its recommended replacement and flags the migration complexity for a typical B2B SaaS integration.
| Deprecated Feature | Why Deprecated | Recommended Replacement | Migration Complexity |
|---|---|---|---|
| Roots | Niche use case; rarely needed by real servers | Tool parameters, resource URIs, or server config | Low — pass paths explicitly |
| Sampling | Confusing semantics, rare adoption | Direct LLM provider API calls; Multi Round-Trip Requests (SEP-2322) | High — architectural rethink required |
| Logging | Excessive noise on the protocol channel | stderr (stdio transports) or OpenTelemetry | Low — swap logging sink |
| HTTP+SSE transport | Stateful connection model limits scalability | Streamable HTTP transport | Medium — transport layer swap |
Sources: Digital Applied MCP Dev Summit Readout; Stacktree MCP 2026 Spec Changes.
How are the Tier 1 SDKs handling this right now?
All four Tier 1 SDKs, TypeScript, Python, Go, and C#, ship support for the 2026-07-28 specification as of publication day, with migration notes for the breaking changes. None of them have removed the deprecated APIs yet, but they've signaled their intentions clearly.
The C# SDK is the clearest illustration of what the migration path looks like in practice. In C# SDK v2.0, the breaking changes are confined to the deprecated capabilities: Roots, Sampling, and Logging are marked [Obsolete] with pointers to their replacements, while stable v1.x APIs keep working in v2. That's the pattern you should expect to see replicated across the other SDKs over the next few release cycles.
If you're running TypeScript or Python MCP servers, open your dependency file now and check which SDK version you're pinned to. Then check whether your code calls roots, sampling, or logging capability methods. If it does, you have migration work to schedule.
Why does any of this matter for marketers and growth teams?
MCP is the protocol that lets AI agents call your product's tools and read your product's data. If your integration breaks or degrades after SDK removal, AI agents stop being able to interact with your product correctly. That's a direct commercial risk.
Consider the stakes: brands recommended first by AI are 389% more likely to be Googled. If your MCP integration is broken or partially functional because you missed a deprecation deadline, AI agents will either fail silently or fall back to a competitor whose integration works. The protocol gap becomes a market share gap.
There's also the broader shift in how traffic reaches your product to consider. AI traffic grew roughly 10x in the past 12 months, and AI Overviews reduce organic CTR by 58% on average. AI agents aren't a future distribution channel. They're a present one, and MCP is the interface layer your product exposes to them. Keeping that layer current isn't an engineering chore, it's a growth priority.
Your llms.txt file is the other side of this equation. A well-structured llms.txt file signals to AI agents which of your tools and endpoints are authoritative, making it easier for agents to discover and use your MCP integration correctly. If your MCP transport is migrated but your llms.txt still references deprecated capability endpoints, agents may still route around you.
Schema markup compounds the problem further. If your MCP server exposes structured product or pricing data, use Faro's AI Schema Creator to ensure that data is formatted in a way AI agents can actually parse, not just search engines.
What is your 12-month migration checklist?
The deprecation window closes on or around July 28, 2027. Here's the order of operations that minimizes risk.
Month 1-2: Audit every MCP server your team owns or maintains. Search the codebase for references to roots, sampling, logging capability negotiation, and any HTTP+SSE transport configuration. Log the findings in a single tracking document.
Month 3-4: Prioritize Sampling migrations first because they require the most architectural thought. Map every place your server currently calls back to the client model and design the Multi Round-Trip Request replacement flow for each.
Month 5-6: Replace Logging with stderr or OpenTelemetry. This is the lowest-complexity migration but the one most likely to get deprioritized because "nothing is broken yet." Do it early so it isn't a distraction during the harder Sampling work.
Month 7-8: Migrate Roots usages to explicit tool parameters or resource URIs. Update your server configuration documentation to reflect the new parameter contracts.
Month 9-10: Migrate from HTTP+SSE transport to Streamable HTTP. Test against the latest Tier 1 SDK versions to confirm compatibility.
Month 11-12: Freeze the deprecated APIs in your internal code review checklists. Run a final audit against the then-current SDK versions to confirm nothing slipped through.
In short
The MCP 2026-07-28 specification deprecates four features: Roots, Sampling, Logging, and the legacy HTTP+SSE transport. A new formal lifecycle policy mandates a minimum twelve-month window before removal. Nothing breaks today, but Tier 1 SDKs are already marking these APIs as obsolete and migration guides are live. Sampling is the hardest migration because it requires adopting the new Multi Round-Trip Requests pattern; Logging and Roots are straightforward swaps. For marketers and growth teams, a broken MCP integration isn't a technical inconvenience: it's a direct hit to AI agent discoverability at a moment when AI traffic is growing faster than any other channel.
Run Faro's free AI Readiness Scan to check whether your site's API and agent-facing configuration is current, or use the OKF Generator to build a structured capability file that surfaces your MCP tools to AI agents correctly. Both take under two minutes.
Frequently Asked Questions
Will my MCP integration break immediately after July 28, 2026?
No. Per SEP-2577, deprecated features remain fully functional in all specification versions released within one year of the 2026-07-28 release date. Wire-level behavior is unchanged: no types are removed and no capability negotiation changes during the deprecation window. You have until approximately July 28, 2027, before SDKs may begin removing support.
Which of the four deprecated features requires the most migration work?
Sampling is the most complex because it requires adopting the Multi Round-Trip Requests pattern from SEP-2322, which is an architectural change rather than a configuration swap. Roots and Logging are comparatively simple: pass file paths as tool parameters and redirect log output to stderr or OpenTelemetry.
What is replacing the legacy HTTP+SSE transport?
The Streamable HTTP transport replaces HTTP+SSE. The legacy transport was reclassified as formally deprecated under SEP-2596, which also introduced the new feature lifecycle policy covering Active, Deprecated, and Removed states. All four Tier 1 SDKs ship Streamable HTTP support as of the July 28 release.
Do I need to update my llms.txt or schema markup as part of this migration?
Yes, ideally. If your llms.txt or structured schema references deprecated capability endpoints or transport URLs, AI agents may resolve to the wrong interface. Updating those files after your MCP transport migration ensures the agent-facing discovery layer matches the live integration. Faro's llms.txt Generator and AI Schema Creator can help you keep both current.
How do I know if my current SDK version is affected?
All four Tier 1 SDKs, TypeScript, Python, Go, and C#, already ship support for the 2026-07-28 spec with deprecated APIs marked as obsolete. Check your dependency file for the SDK version you're pinned to, then search your codebase for calls to roots, sampling, and logging capability methods. The C# SDK v2.0 is the clearest reference: deprecated capabilities are marked [Obsolete] with explicit pointers to their replacements.