The 2026 MCP Spec From a Production Ads Server’s Seat

Published August 1, 2026 by Ahmed Ashraf · Founder, PaidSync.ai

The 2026-07-28 MCP specification removes protocol-level sessions, moves Tasks and MCP Apps into a formal extensions framework, tightens OAuth rules, and deprecates Dynamic Client Registration in favor of Client ID Metadata Documents. PaidSync runs a remote MCP server with 430+ ads tools across 13 platforms in production for Claude and ChatGPT clients, and these are working notes on what each change means from that seat. Nothing breaks on day one; deprecated features carry a minimum twelve-month window.

Every protocol claim below comes from the official release post and the 2026-07-28 changelog, both read at write time on August 1, 2026. The opinions are ours. The release post puts scale numbers on why this revision matters: close to half a billion SDK downloads a month across the main SDKs, the TypeScript and Python SDKs each past one billion total downloads, and Honeycomb reporting that nearly 20 percent of its monthly interactive queries now come from agents. The Register’s coverage relays the maintainers calling it the most significant release since remote MCP launched. From where we sit, that is about right, and most of the significance is operational rather than flashy.

What Changed on July 28

The Stateless Core and the Retry Problem

The headline change: the initialize/notifications/initialized handshake is gone, and so is the Mcp-Session-Id header. Every request now carries its protocol version, client capabilities, and client identity in _meta, and a new required server/discover RPC lets clients probe capabilities up front. Server-to-client change notifications consolidate into a single opt-in subscriptions/listen stream. The practical effect the maintainers are after, and The Register underlines, is that any request can hit any server instance behind an ordinary load balancer, on ordinary Kubernetes tooling, with no shared session store.

Here is the honest operator read: the protocol session was never where our hard state lived. For an ads server, the state that matters is OAuth grants, the active ad account selection, spend guardrails, and per-platform rate budgets. That state sits in a database keyed to the authenticated user, because it must survive a dropped connection. What the old handshake added was a second, fragile session that could die independently of the real one, and a deploy or balancer restart would sever protocol sessions while auth sessions were fine. Deleting that layer removes a whole class of confusing failures. The spec’s replacement for legitimate cross-call state is server-minted handles passed as ordinary tool arguments, which is how ads flows read anyway: select an account, get a handle, pass it onward. Sign them and expire them, since any instance can now receive them cold.

The sharp edge is retry semantics

Buried under the stateless story is the change most likely to cause real-money incidents: SSE stream resumability and message redelivery are removed. Under 2026-07-28, a broken response stream loses the in-flight request, and the client must re-issue it as a new request with a new request ID. For get_campaign_performance, a retry costs nothing. For a campaign create or a budget update, a blind retry is how an agent double-spends. If your server mutates money, your tool contracts need idempotency keys and your backend needs dedupe, because the transport no longer promises to redeliver the original result. Our shipped writes are approval-gated with dry_run and confirm_destructive flags, which narrows the blast radius, but a gate is not a dedupe. Treat them as two separate controls and build both.

Tasks Finally Fit How Ads Work

Tasks leaves the experimental core and becomes an official extension, io.modelcontextprotocol/tasks. The redesign replaces the blocking tasks/result call with polling via tasks/get, adds tasks/update for client-to-server input mid-task, and lets servers return task handles unsolicited, without per-request opt-in. The Register’s piece highlights the durability point: tasks are addressed by stable handles, so a client can persist a task ID and resume polling after a crash or restart.

Ads work is long-running by nature. An audit across a 200-campaign MCC. A bulk pause across a season’s worth of ad sets, the kind of work our Meta bulk operations docs exist for. A 90-day cross-platform report pull. Today all of that has to finish inside whatever deadline the proxy in front of your server enforces, and every production deployment has such a proxy. Poll-based tasks match boring HTTP infrastructure: no held stream to babysit, nothing for an edge timeout to sever halfway.

tasks/update is the quietly important part for ads specifically. A task that accepts input mid-flight is a task that can pause before its destructive half and ask. Today an approval gate is two tool calls: a dry run, then an explicit confirm. Under Tasks, the same safety pattern can be one durable operation with a human pause inside it, which is a better shape for agents that plan multi-step work. The caveat is structural: extensions are disabled by default and need explicit opt-in on both sides, so this pays off when Claude and ChatGPT ship client support, not before.

MRTR Replaces Server-Initiated Requests

Server-initiated requests (roots/list, sampling/createMessage, elicitation/create) are replaced by the Multi Round-Trip Requests pattern. A server that needs more information returns a result with resultType: "input_required" carrying its questions; the client retries the original request with the answers attached in inputResponses. Every result now carries a required resultType, and results from earlier-protocol servers that omit it must be treated as complete, which keeps mixed-version fleets sane.

Elicitation was how a server asked "which of your 14 ad accounts did you mean?" in the middle of a call. MRTR keeps the question and inverts the mechanics. The server can no longer park a pending question in process memory, because the retry may land on a different instance; whatever context the question needs goes into requestState. That is annoying to retrofit and correct by design. It also formalizes a lesson every remote ads server learns early: chat clients vanish mid-conversation constantly, so any mid-operation question that is not resumable is a question that will strand an operation. We have watched enough half-finished flows to consider this the spec catching up to reality.

Authorization Gets Harder to Get Wrong

Three tightenings, all sourced to the changelog. Authorization servers should include the iss parameter in authorization responses per RFC 9207, and clients must validate it against the recorded issuer before redeeming a code. Client credentials are now explicitly bound to the authorization server that issued them: keyed by issuer, never reused across issuers, re-registered when the issuer changes. And clients must declare an application_type during registration, which fixes a long-standing class of localhost redirect rejections for CLI and desktop agents. Enterprise-Managed Authorization also lands as a formal extension, giving organizations centralized control over which MCP servers their agents may use.

Why this matters more for ads servers than for most: one bearer token to a remote ads MCP server fronts real ad accounts on Google, Meta, and LinkedIn, with real budgets behind them. That is exactly the kind of target OAuth mix-up attacks were invented for, and iss validation is the standard countermeasure. Most of the new obligations land in client code, but they only work if servers publish accurate authorization metadata to validate against. For the record, the PaidSync baseline shipped today is RFC 8414 authorization server metadata and RFC 9728 protected resource metadata at the well-known paths, a published security.txt, an MCP server card and agent-auth manifest, and session revocation so a user can cut off a connected client at any time. That is the current stable revision done carefully, not an implementation of 2026-07-28; we say so plainly because reading a spec is not shipping it.

DCR Is Out, CIMD Is In

Dynamic Client Registration (RFC 7591) is formally deprecated as MCP’s client registration mechanism in favor of Client ID Metadata Documents. It stays available for backward compatibility with authorization servers that have not moved yet. Under CIMD, the client_id is an HTTPS URL the client operator controls, and the authorization server fetches the client’s metadata from that URL.

This one we would have voted for twice. DCR meant every unknown agent self-registered into your authorization server: anonymous rows, self-asserted names, zero reputation, and a periodic cleanup job for registrations nobody ever used. CIMD changes the question at the gate from "did this thing register?" to "who owns this domain?" For a server fronting ad spend, that difference is policy-grade. It makes allowlists of known agent platforms possible, and it makes the consent screen honest: the client name a user approves is backed by a domain, not typed in by the client itself. The migration advice writes itself: keep DCR working through the deprecation window, prefer CIMD for every client that presents one, and start drafting the trust policy now, because the policy is the hard part, not the parsing.

MCP Apps and the Plumbing Changes

MCP Apps

MCP Apps arrives as an official extension in the new extensions framework. The extensions documentation describes it as letting servers display interactive UI elements, charts, forms, video players, inline in conversations. For ads work the candidates are obvious: a spend trend as an actual chart instead of an ASCII table, a campaign preview before launch, an approval form for a bulk change with a checkbox per campaign. A rendered approval form is a materially better safety surface than free-text "yes, confirm". Same caveat as Tasks: opt-in on both sides, so client adoption sets the clock.

Headers and caching

Streamable HTTP POSTs must now carry Mcp-Method and Mcp-Name headers, so gateways can route and rate-limit without parsing JSON bodies. With 438 live tools on our server, per-tool policy at the edge, stricter limits on mutation tools, WAF rules that never touch a body, is cheap capability we will take. List results (tools/list and friends) must now carry ttlMs and cacheScope, which means clients can finally stop re-pulling a large tool catalog every turn. The spec also nudges servers to return tools in deterministic order to improve LLM prompt cache hits; for catalogs our size, that is a direct token-cost lever. We wrote about the catalog-size tradeoff in why the tool count is a feature.

Deprecations with a real clock

Roots, Sampling, and Logging are deprecated, along with the legacy HTTP+SSE transport, under a new feature lifecycle that guarantees a minimum twelve-month transition window. None of it stings here. Server-side sampling was always the wrong shape at a billing boundary, since it means a tool server spending someone else’s model tokens; logging moves to stderr or OpenTelemetry, which production servers do anyway. The lifecycle policy itself is the win: retirements now come with a schedule you can plan against instead of a surprise.

What This Does Not Change

A First-Week Checklist for Agent Builders

If you run or are building a remote MCP server, this is the order we would work in, based on running one in production.

Frequently Asked Questions

Related Reading