The MCP 2026-07-28 revision made removal the headline. Here's how we decided what not to build, and why the reasons matter more than the list.
Update (August 5, 2026): Since this piece was written against mocapi 1.0.0, two of the four omissions below have shipped as opt-in extensions: MCP Apps in 1.1.0, and the Tasks extension in 1.2.0 (extended to run cluster-friendly in 1.3.0). Both arrived as additive point releases, which is the "cheap to reverse" path the reversibility test below predicted. subscriptions/listen, the one omission we called structural, is still out. The 1.0.0 snapshot that follows is left as written.
The 2026-07-28 revision of the Model Context Protocol is the first one whose headline is a deletion. The session layer is gone. The stateful lifecycle that leaned on it is gone. Resumable SSE streams went with it. A spec that spent two years accreting surface area turned around and cut.
That puts a question in front of every maintainer building on the new revision, and most of us are answering it implicitly: what do you not build? When the spec itself is subtracting, "implement everything" stops being a coherent goal. You have to draw a line between what's in and what's out, and defend where you drew it.
We drew ours in an architecture decision record, ADR-0022, and published it. This piece isn't a tour of that document. It's an argument for writing one at all, and a look at what the reasons in ours say about building on this revision. Mocapi 1.0.0 implements 2026-07-28 and nothing else: no dual stack, no legacy paths. Every omission is a decision we actually had to make, which is why the reasons are worth reading.
Roots let a client tell a server its workspace boundaries. Sampling let a server borrow the client's model to generate a completion. Logging was the protocol-level notification stream a server emitted to a client. The 2026-07-28 revision deprecated all three under SEP-2577, and told new implementations not to adopt them.
We built the framework as if it had been designed against 2026-07-28 from the start, so it doesn't carry features the same revision is retiring. We pulled ctx.sample and ctx.log out of the API; the server doesn't read roots and doesn't emit notifications/message. The spec's own migration paths cover the gap cleanly: pass files through tool parameters or resource URIs instead of roots, call an LLM provider directly instead of sampling, and use stderr or OpenTelemetry instead of protocol logging.
Deprecated doesn't mean deleted. The spec keeps these three working for at least twelve months, and capability negotiation doesn't change. So what happens if a client still wants them? Nothing, and that's the design. These are negotiated capabilities. A mocapi server doesn't advertise logging and never asks a client for sampling or roots, so a spec-compliant client checks what's on offer, sees them absent, and never calls them. A client hard-coded to assume they exist was already headed for trouble, and we don't carry that assumption forward. This is the one omission that runs with where the protocol is going, which makes it the cheapest of all to leave out.
This is the new mechanism for a server to push list-change and resource-update notifications to subscribed clients. Mocapi discovers its tools, prompts, and resources statically, once, at application startup. A server with a fixed inventory has no change events to push. Building the subscription machinery, change detection, and subscriber tracking would add real weight to feed a capability our discovery model can't produce.
What reopens it: dynamic registration. The day handlers can appear and disappear at runtime, there's finally something to notify about, and subscriptions/listen is where that decision comes back.
SEP-2663 moved long-running task semantics out of the core protocol into an official, independently versioned extension: tasks/get, tasks/update, tasks/cancel, and server-directed task creation. That's a substantial state machine for long-running work, and mocapi's handler model is synchronous. We haven't needed it yet. That's the honest reason, and we don't dress it up as a principled stand. Extensions are opt-in by design and this one versions on its own schedule, so adopting it later won't require a protocol bump.
What reopens it: a real use case for long-running, resumable operations. The extension is built to be added, and nothing structural is in the way.
SEP-1865 lets a server ship server-rendered HTML UIs displayed in sandboxed iframes on the client. It's a presentation-layer feature, and mocapi's world is tools, prompts, and resources. The core protocol requires nothing of it, and it's optional by design.
We shipped 1.0.0 with an empty extensions map on purpose: a clean core baseline before any extension work. Apps is the first extension we're building on top of that baseline, with Tasks to follow. That "not in 1.0.0, next out the door" sequencing is the whole point of the category, and it's why an omission here reads so differently from a permanent one.
Listing what's in and what's out is the boring half of a document like this. The half worth reading is which omissions are cheap to reverse and which would be structural.
Three of our four are cheap. Tasks and MCP Apps are opt-in extensions that version on their own schedule, so adding either is additive work on top of the core rather than surgery to it. Apps is already in progress, which is that argument made concrete. The deprecated trio is cheaper still to leave out, because reversing it would mean adopting features the spec is walking away from.
subscriptions/listen is the structural one. It's out for an architectural reason: static discovery at startup gives it nothing to feed. You can't bolt real-time change notifications onto a server that has no changes to report. Reopening it means changing how discovery works, and that's a different order of cost from dropping in an extension.
That distinction is the point. "We didn't build X" tells a reader nothing about their risk. "We didn't build X, and adding it is a dependency upgrade" versus "and adding it means reworking discovery" tells them exactly what they'd be signing up for.
And the line has nothing to do with what we're capable of building. We shipped the hard part of the interactive surface: multi-round-trip elicitation, where each round trip travels as a self-contained, AES-GCM-encrypted requestState token backed by a replay ledger, keeping the server stateless across the exchange. We built that and declined URL-mode elicitation in the same pass. These omissions are choices, not ceilings.
An ADR is a governance artifact before it's a technical one. Ours answers the architecture-review question before anyone asks it. When someone evaluating mocapi for a regulated deployment asks whether it supports Tasks, and why not, the answer is a numbered, dated record instead of a maintainer's recollection.
It also keeps us honest at the conformance boundary. Mocapi runs the official MCP conformance suite with a published expected-failures baseline. As of the 2026-07-28 run, 79 checks pass and 13 fail, and all 13 are named, explained entries that trace back to a decision in the ADR. A reviewer can open the failures and confirm that each one is a stance we took on purpose: the sampling and roots probes for features SEP-2577 deprecated, the x-mcp-header check we declined, the raw-schema case our type-driven generation doesn't cover. That reads very differently from a bare green checkmark.
The date carries as much weight as the reasons. An omission recorded against a specific revision on a specific day tells a future reader what we knew at the time. When the constraint changes, and for some of these it already is, the record shows what to revisit and why it was closed.
If you're moving a server to 2026-07-28, you're making these calls whether or not you write them down. The revision deprecated features you may already ship, and it introduced optional surface you have to take or leave. Each is a decision, and the decisions you don't record quietly turn into folklore.
So write the document. For each thing you're not building, capture three lines: what it is, why you skipped it, and what would change your mind. Then sort the list by reversibility, because that's the column a future reviewer, or a future you, will actually care about. The feature list dates fast. The reasons are what stay useful.
Mocapi's version is ADR-0022, and the framework is on GitHub if you want to see how the calls play out in code.
There's a wider point under all of this. The discipline of writing down what you didn't build, and why, is the same discipline that keeps enterprise AI dependable once it's in production. It's how we work: we help teams make these calls deliberately, record them, and revisit them when the constraints change. If that's the kind of enterprise AI engineering your organization is trying to build, or you want a second set of eyes on the decisions your teams are already making, that's the AI consulting work we do.