Review a Model Context Protocol (MCP) server implementation against the 2026-07-28 protocol revision, which removed the initialize handshake and Mcp-Session-Id and made the protocol stateless. Use when the user asks to review, audit, upgrade or migrate an MCP server, asks whether their MCP server is spec compliant, asks which protocol revision their server implements, or reports that an MCP client cannot connect to their server.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Review a Model Context Protocol (MCP) server implementation against the 2026-07-28 protocol revision, which removed the initialize handshake and Mcp-Session-Id and made the protocol stateless. Use when the user asks to review, audit, upgrade or migrate an MCP server, asks whether their MCP server is spec compliant, asks which protocol revision their server implements, or reports that an MCP client cannot connect to their server.
Review an MCP Server Against the 2026-07-28 Revision
Protocol revision 2026-07-28 is the largest change to the Model Context Protocol since it launched. Server code written before it still compiles, still passes its own tests, and still looks correct in review. It simply speaks a shape that modern clients no longer send.
This skill finds that gap. It reviews an MCP server implementation against the current revision, reports what is obsolete, what is missing, and what is a security requirement rather than a nicety, and it distinguishes between a genuine finding and something it could not determine from the code available.
Before Starting
Critical: Always ask the user for the following information before proceeding:
Server code - the repository, folder, or files implementing the MCP server
Target revision - the protocol revision the server intends to implement. Defaults to 2026-07-28 if not specified
Transport - Streamable HTTP or stdio. Defaults to Streamable HTTP if not specified, since the header rules below apply only to it
Backward compatibility requirement - whether the server must still serve clients on 2025-03-26 through 2025-11-25. Defaults to no
If the user doesn't provide all details upfront, ask for the missing ones before proceeding.
Do not infer the revision from an SDK version number. SDK majors and protocol revisions move independently. Read what the code actually sends and accepts.
Output Structure
Produce a review report with these sections:
Revision verdict - one line stating which revision the code appears to implement, and the evidence for that conclusion
Blocking findings - table of Finding | Location | Why it breaks | Fix
Security findings - the spec's security requirements with their MUST or SHOULD levels, listed separately because they are not stylistic
Deprecated but working - features on the twelve month removal clock
Not determined - checks that could not be evaluated from the code provided, and what to look at to resolve each
Nothing to change - the checks that passed
The Not determined section is required and must never be silently folded into "passed". A reviewer reading a clean report has to be able to tell the difference between "this is correct" and "this was not visible".
Every finding must cite the specific rule it comes from. Do not invent limits or headers. If a rule cannot be tied to the specification, leave it out and say so.
Step 1: Establish which revision the server implements
Look for the strongest available evidence, in this order:
An explicit protocol version constant or string, for example 2026-07-28, 2025-11-25, 2025-06-18, 2025-03-26, 2024-11-05
The presence or absence of an initialize request handler
The presence or absence of Mcp-Session-Id handling
Whether request handlers read params._meta for the protocol version
State the verdict plainly. "This server implements a pre-2026-07-28 revision" is a useful finding on its own, and it is usually the root cause when a client cannot connect.
Step 2: Find removed features still present
These were removed in 2026-07-28. Each is a blocking finding for a server that claims to implement it.
Removed
What to search for
Replacement
initialize / initialized handshake (SEP-2575)
A handler for method initialize, or notifications/initialized
Nothing. Every request is self contained
Mcp-Session-Id (SEP-2567)
The header name, session stores, sticky routing, DELETE to terminate a session
Nothing. Any request may land on any instance
GET stream endpoint
A GET route on the MCP endpoint that opens SSE
subscriptions/listen, whose response is itself the stream
Resumable streams
Last-Event-ID handling
Not supported. Streams are not resumable
Server-initiated JSON-RPC requests on SSE
The server sending a request (not a notification) on a response stream
Multi Round-Trip Requests: return an InputRequiredResult containing inputRequests
A server that only supports this revision and receives legacy traffic should answer GET or DELETE on the MCP endpoint with 405 Method Not Allowed, ignore any Mcp-Session-Id it receives without minting or echoing one, and ignore Last-Event-ID.
Step 3: Check the request metadata contract
Under Streamable HTTP the client mirrors body fields into headers so intermediaries can route without parsing the body. The server has obligations on the receiving side.
Required headers on every JSON-RPC request POST:
MCP-Protocol-Version - must equal the io.modelcontextprotocol/protocolVersion value inside params._meta
Mcp-Method - must equal the body's method
Mcp-Name - required for tools/call, resources/read and prompts/get; sourced from params.name or params.uri
The server MUST reject disagreement. If a header and its body value differ, or a required header is missing or malformed, respond 400 Bad Request with JSON-RPC error code -32020 (HeaderMismatch). Verify this is actually implemented, not merely documented. A server that trusts headers without validating them against the body is the exact vulnerability this rule exists to prevent, because a load balancer may route on the header while the server executes on the body.
Version negotiation: an unsupported version must return 400 with an UnsupportedProtocolVersionError listing the versions the server does support. An unimplemented method must return 404 with JSON-RPC -32601. The JSON-RPC error body is what distinguishes a modern server's 404 from a legacy server that simply does not host the endpoint.
Step 4: Check response handling
The endpoint must accept POST. A request body is a single JSON-RPC request or notification, never a response
For a request, the server returns either Content-Type: application/json with one JSON object, or Content-Type: text/event-stream with a stream. Either is valid; the client must support both
For a notification, the server returns 202 Accepted with no body when it accepts it
On an SSE stream, the server may send notifications related to that request before the final response, and the final response should terminate the stream
Closing the response stream must be treated as cancellation of that request. The server should stop work as soon as practical and must not send further messages for it
When opening an SSE stream, the server should send X-Accel-Buffering: no so reverse proxies do not buffer events
For long-lived subscriptions/listen streams, the server is encouraged to emit periodic SSE comment lines (:) as keep-alives
Step 5: Check the security requirements
Report the specification's security requirements separately from style findings, preserving their MUST or SHOULD requirement levels.
Origin validation (MUST). The server must validate the Origin header on all incoming connections to prevent DNS rebinding attacks, and respond 403 Forbidden when it is present and invalid. This is the most commonly missing check in server code
Local binding (SHOULD). When running locally, bind to 127.0.0.1 rather than 0.0.0.0
Authentication (SHOULD). The server should implement proper authentication for all connections
Without the first two, a remote web page can reach a local MCP server through the user's browser.
Step 6: Check x-mcp-header tool annotations
If the server annotates tool parameters for header mirroring, the annotations must be valid or conforming clients will exclude the whole tool from tools/list.
An x-mcp-header value must:
Be non-empty and match HTTP field-name token syntax
Contain no control characters, including CR or LF
Be case-insensitively unique across the inputSchema
Sit only on primitive properties: string, boolean, integer. number is not permitted
Be statically reachable from the schema root through a chain consisting solely of properties keys. The chain must not pass through items, oneOf, anyOf, allOf, not, if/then/else, or $ref
Also confirm the server decodes the Base64 sentinel form before comparing a header to its body value. Values that are not header-safe travel as =?base64?<base64>?=, and a plain value that merely looks like the sentinel is also encoded. A server that compares the raw header against the body will reject valid requests from conforming clients.
Step 7: Flag deprecated features
Deprecated in this revision, with a twelve month minimum window before removal. These are not blocking, but a server still relying on them needs a migration plan.
Roots
Sampling
Logging
Dynamic Client Registration, in favour of Client ID Metadata Documents
The legacy HTTP+SSE transport from 2024-11-05
Step 8: Check what the revision added
Not implementing these is not a defect, but they are the reason to move:
Stateless operation. No session store, no sticky routing. Confirm nothing in the server assumes affinity between requests
server/discover. An optional RPC letting a client learn capabilities without a handshake
Cacheable list results.tools/list, prompts/list, resources/list and resources/read may return ttlMs and cacheScope
Multi Round-Trip Requests. Server-to-client interaction is returned inside a result rather than sent as a separate request
Step 9: Write the report
Follow the Output Structure above.
Rules
Cite the rule behind every finding. A finding a reader cannot verify is not actionable
Separate MUST from SHOULD. The specification distinguishes them and so should the report
Put anything unverifiable in "Not determined", never in "passed". If the auth path is in a separate service you cannot see, say that
Input: Review a Streamable HTTP server that handles initialize, mints Mcp-Session-Id, binds locally to 0.0.0.0, and has authentication implemented by an API gateway whose configuration is not included.
Output excerpt:
Section
Finding
Revision verdict
The server implements a pre-2026-07-28 revision, evidenced by its initialize handler and session header handling
Blocking findings
Remove the initialize handler and stop minting or requiring Mcp-Session-Id
Security findings
Local binding to 0.0.0.0 does not meet the specification's SHOULD-level localhost-binding guidance
Not determined
Authentication cannot be evaluated without the API gateway configuration
Validation Checklist
Before returning the report, verify:
The revision verdict cites evidence from the reviewed code
Every finding cites a specification rule and preserves its MUST or SHOULD level
Removed features, security findings, and deprecated features are reported separately
Unverifiable checks appear under Not determined, not Nothing to change
Header names, error codes, and protocol behavior were checked against the target revision
The report follows every section in the Output Structure
