What the MCP 2026 Spec RC Changes
The MCP spec RC, scheduled to finalize on 2026-07-28, ships a stateless core, Tasks, MCP Apps, and mandatory iss validation based on RFC 9207. The stateless core decouples session state from the server, simplifying horizontal scaling and failure recovery, while Tasks standardizes the progress and cancellation of long-running work. From an operations standpoint the biggest shift is in the authorization layer: clients are now required to validate the iss (issuer) value in the token response.
Mandatory RFC 9207 iss Validation
RFC 9207 carries an iss parameter in the OAuth authorization response so the client can confirm exactly which authorization server the response came from. It is the safeguard against mix-up attacks that arise when multiple authorization servers are used together. Without iss validation, an attacker can splice a legitimate server's response into a different flow and steal the token. When validation fails, the default branch is to discard the token and abort the flow.
Failure Patterns Seen in the Registry
The official registry listed 3,012 servers as of March, yet only 8.5% actually use OAuth. Most of the rest are exposed with no authentication or depend on static tokens. Over the past year, 7 CVEs were reported, including a CVSS 9.6 remote code execution (RCE), and many traced back to missing input validation and excessive tool permissions.
A Full-Length Guide: From Planning to Operations
In the requirements and planning phase, first freeze the set of tools you will expose and their permission scope, then pin your target metrics as numbers. For example, set the bar at a 100% iss validation pass rate, zero authorization violations, a p95 tool-call latency of 800ms or less, and a 95%-or-higher retry success rate for transient failures. Without these numbers, quality regressions are hard to catch when you add a tool or swap an authorization server.
Define your failure patterns and recovery strategy per branch in advance. An iss mismatch discards the token and aborts immediately; an expired token gets one silent re-issue retry and, on a second failure, escalates to a human check. When a tool response violates its schema, return only a safe truncated version instead of the raw payload and log the original in isolation. Tool calls that demand elevated permissions are blocked from auto-execution and routed through a human approval gate.
Spell out stop conditions as well. When failures hit three in a row, an abnormal payload is detected, or iss validation failures cross a threshold, isolate the session and send an alert. Cap automatic retries at two to keep cost and latency from spiking together.
For the operations checklist and quality control, emit a standard log for every tool call (request id, tool name, argument hash, iss, latency, result code) and mask PII in both logs and responses. Ban static tokens, apply least privilege, and pin registry servers to a fixed version and hash to block supply-chain drift.
Run the continuous improvement loop on a weekly cadence. Review the CVE feed and registry changes, and track the iss validation pass rate, retry success rate, and block count on a dashboard. Add mix-up attack scenarios to your regression tests so the validation logic is hardened before the spec is finalized.
Executive Summary
The core of adopting MCP is setting a 100% iss validation pass rate and zero authorization violations as the bar, and pre-branching every failure into retry, human check, safe truncation, or stop. Strip out static tokens and make standard logging and PII masking the default, and the transition to mandatory RFC 9207 becomes a smooth one.