The MCP Stateless Spec Is Final. Here's What It Settles — and What It Doesn't.

On July 28, the MCP 2026-07-28 Release Candidate officially finalized. The headline change is the stateless core: the `Mcp-Session-Id` header and the `initialize` handshake are removed from the specification. Every request to an MCP server now carries what it needs inside the request itself — auth, context, routing — with no prior session required and no session state to maintain between requests.

What the stateless shift actually removes

In a session-based MCP server, the `initialize` handshake established which tenant's data to return and held that context in session state. Stateless architecture eliminates that model. As Microsoft's AppService breakdown describes it, stateless requests can be handled by any server replica with no sticky routing and no session replication. Stacktree's spec analysis frames the transition as moving from 'the server remembers you' to 'the request proves who you are.'

For a multi-tenant SaaS product, the difference is not only scaling — it is correctness. A session-based server that loses its session state on a pod restart or a load-balancer reassignment can silently return wrong-tenant data or drop context. An auth-carried design cannot: the request either carries valid credentials scoped to the right organization, or it is rejected. There is nothing to misplace between requests.

Where OKR Studio already stood before the finalization

OKR Studio's MCP server was already stateless. The `initialize` handshake was never used in our implementation. Tenant scoping has always been carried by the API key on each individual request — the middleware validates the bearer token and scopes every tool call to that key's organization, with nothing held in session state. An internal audit against the RC specification found that the core architecture aligned on five of six areas without changes. The remaining item — caching hints on the tool list response — shipped in a prerelease SDK upgrade this week.

We are not claiming a verified compliance badge until client-side verification completes against the shipped spec. The honest position is this: the stateless finalization presents no breaking changes to how we run today. The architecture was already there.

The spec settles when the floor has already moved

The stateless finalization lands one day after a meaningful commodity signal in the OKR tool category. Earlier this month, OKRs Tool made its MCP server free on every plan, including free tier — repricing what was once a paid integration to a baseline expectation. The combination of free MCP access at competitors plus a finalized stateless spec means that by this week, the category answer to 'does this OKR tool support MCP on a stable spec?' is: yes, everywhere, for free.

That is good for the category. It removes friction and raises the floor. It also means the answer to that question is no longer a purchase signal.

What no spec answers

Two weeks ago we wrote that MCP connection had become table stakes — and that the question worth asking was what the AI does once it is connected. The stateless spec finalizing does not change that framing. It resolves it: connection is now standardized, stateless, and available at the category floor. The analysis question is exactly where it was.

The difference between a basic MCP integration and an analysis-layer one is not the transport. It is what the server exposes through the connection. A server that returns raw key result values gives the AI numbers. A server with a real analysis layer returns cycle-position-aware pacing states, at-risk indicators computed against actual elapsed time, and confidence trends across recent check-ins. The AI can answer 'what is slipping and why' only if the server has already done the work to interpret the data.

The question to carry forward

With connection standardized, the evaluation question for any OKR tool moves cleanly to the analysis tier. Not 'does it support the 2026-07-28 spec?' — that is a baseline expectation by this week. The question is what the AI can answer once it is connected and authenticated.

• Does the server return pacing states or raw progress values? A raw value tells the AI a key result is at 31%. A pacing state tells the AI it is at 31% with 59% of the cycle elapsed — which are opposite situations depending on the baseline and direction of the target.
• Can the AI tell you what is at risk and why, or only what the current numbers are? The former requires cycle context, baseline handling, and direction awareness built into the server. The latter is a database read.
• Does at-risk detection account for where you are in the cycle, or does it fire the same flat threshold on day three and week eleven?

MCP going stateless is the right call for the protocol and for every multi-tenant tool running on it. It closes a real architectural liability and locks in a foundation that scales without session complexity. The fact that OKR Studio already ran this way is not a differentiator worth leading with. The plumbing was never the interesting question. As of July 28 it officially stopped being the open one.

Connect Your AI to Cycle-Aware Analysis

OKR Studio's MCP server exposes pacing states, at-risk indicators, and confidence trends — so any AI tool you connect can answer what's slipping and why, not just what the current value is.