FlyWheel
Choose your agent:
Book a call Get beta access
← All posts

What the 2026 MCP spec changes for marketers

By Ben Bowler

What the 2026 MCP spec changes for marketers

On 28 July 2026, the Model Context Protocol published its first specification revision since November 2025, and it’s the largest one so far. If you connect an agent to your ad accounts, keyword tools or analytics, this is the plumbing underneath that connection.

Nothing you’re running breaks this week. The revision matters to you for three reasons, in this order: MCP now has a written deprecation policy with a twelve-month minimum window, so the connectors you wire up this quarter can’t vanish on you next quarter. Authorization got meaningfully tighter, which is the part that touches the OAuth flow you use to hand over an ad account. And the protocol dropped its stateful session, which is the shape of the “your connector disconnected” problem you’ve hit mid-task. Everything else in the release is work for the people who build servers.

What actually changed on 28 July

The revision turns MCP, the open protocol agents use to reach tools and data, “from a bidirectional stateful protocol into a request/response stateless protocol”. The initialize handshake and the Mcp-Session-Id header are gone, and each request now carries its own protocol version, client identity and capabilities.

The rest, briefly:

  • Multi Round-Trip Requests replace the old pattern where a server held a stream open to ask the user something mid-call. Now the server returns input_required, and the client retries with the answer.
  • Header-based routing. Requests must carry Mcp-Method and Mcp-Name headers so gateways can “route and meter on those headers instead of parsing JSON bodies”.
  • Cacheable lists. Tool, prompt and resource listings now carry ttlMs and cacheScope.
  • An extensions framework. Tasks moved out of the experimental core into an extension, joining MCP Apps and Enterprise Managed Authorization.
  • Deprecations. Roots, Sampling and Logging are deprecated, as is the legacy HTTP+SSE transport, all with at least a year before anything can be removed.

The deprecation policy is the underrated part

MCP now commits to “a formal deprecation policy with a twelve-month minimum window so you can plan upgrades instead of reacting to them”. Every feature gets an Active, Deprecated, Removed lifecycle, with at least twelve months between the middle state and the last one.

If you’ve only ever consumed ad platform APIs through a tool someone else maintains, that sentence reads like housekeeping. It isn’t. Compare it to what you get downstream. Google’s own versioning documentation says that “periodically, older Google Ads API versions will need to sunset” and that Google “will post notices on the developer blog when a version is about to sunset”. That’s a process, not a guarantee. Anyone who lived through the Google Ads v20 to v22 moves in 2025 knows what an unplanned version bump does to a week.

So the interesting position is this: the protocol connecting your agent to your ad stack now offers a stronger stability commitment than several of the ad APIs at the other end of it. The churn risk in an agent-run marketing stack has moved down to the platforms, where it always really lived.

The authorization changes touch your ad accounts

This is the part with the shortest path to your money, because connecting an agent to Google Ads or Meta means completing an OAuth flow and leaving a token behind.

Three changes matter. Authorization servers must now return the iss parameter under RFC 9207 and clients must validate it before redeeming a code, which the release describes as closing “an authorization-server mix-up hole”. Client credentials are now “bound to the issuer that minted them”, with no reuse across authorization servers. And Dynamic Client Registration is formally deprecated in favour of client ID metadata documents, though it keeps working for now.

Translated: it’s now harder for a badly built or actively hostile client to get an authorization code issued by one provider redeemed somewhere it shouldn’t be. If you’re evaluating a tool that wants your ad accounts, “which spec revision does it implement” is a fair question, and it’s newly meaningful.

None of this changes the more basic point, which is that the protocol governs how the connection is made, not what the thing on the other end is allowed to do with it. Scope, spend limits and approval steps are still decisions made by the server you connect to. That distinction is the same one behind Meta’s rules for agent permissions: the platform decides what a token can reach, the connector decides what an agent can do with it, and those are separate questions with separate answers.

What “stateless” fixes that you’ve probably felt

If you’ve had an MCP connector go dead partway through a long job and had to reconnect, you’ve met the session. Under the old design, the client and server established a session and everything hung off it. Anything that interrupted the connection, a gateway timeout, a deploy, a load balancer moving you to a different instance, took the session with it.

Removing it means each request stands on its own. For connector operators that makes deploying and scaling far less delicate, and the practical benefit lands on you as fewer mid-task drops. The trade is real for developers: the release is upfront that “there will be some migration cost, especially for developers that did depend on session identifiers”.

The header routing change points the same direction. Once a gateway can read the tool name off a header instead of parsing the body, per-tool rate limits, routing and metering become ordinary infrastructure rather than custom code. If you want a hard ceiling on how often an agent can call a write tool against a live ad account, that’s the layer that enforces it, which is another way of saying the controls don’t belong in the prompt.

What to actually do about it

Very little, deliberately.

Expect SDK version bumps from the tools you use over the next few months, and expect a couple of them to be bumpy. Don’t chase the revision number. A connector still on the November 2025 revision is not broken and won’t be for at least a year.

Two things are worth doing. When you next connect an ad account to anything, notice whether the consent screen names an authorization server you recognise, because that’s the mix-up the new rules exist to prevent. And if you’re choosing between connectors, treat a documented deprecation policy as a real feature. The spec now has one. The tool you pick should be able to tell you the same about itself.

A protocol revision is only as useful as what the connector on the other end does with it. FlyWheel gives your AI agent one MCP surface across Reddit, Google Ads, Meta, and X, with every tool call logged with args, status, latency and actor, and new campaigns shipped paused by default. Get started with FlyWheel.