MCP Server Review

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:

1. Server code - the repository, folder, or files implementing the MCP server
2. Target revision - the protocol revision the server intends to implement. Defaults to 2026-07-28 if not specified
3. Transport - Streamable HTTP or stdio. Defaults to Streamable HTTP if not specified, since the header rules below apply only to it
4. 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:

1. Revision verdict - one line stating which revision the code appears to implement, and the evidence for that conclusion
2. Blocking findings - table of Finding | Location | Why it breaks | Fix
3. Security findings - the spec's security requirements with their MUST or SHOULD levels, listed separately because they are not stylistic
4. Deprecated but working - features on the twelve month removal clock
5. Not determined - checks that could not be evaluated from the code provided, and what to look at to resolve each
6. 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.

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.

The _meta keys are exact. Check for all three:

io.modelcontextprotocol/protocolVersion
io.modelcontextprotocol/clientInfo
io.modelcontextprotocol/clientCapabilities

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.

1. 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
2. Local binding (SHOULD). When running locally, bind to 127.0.0.1 rather than 0.0.0.0
3. 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
• Do not guess header names, error codes or limits. If you are unsure, check the specification at https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http rather than writing from memory. The single most likely way to produce a wrong review of this revision is to describe the protocol as you remember it

Example

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:

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

References

• Streamable HTTP transport: https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
• What changed in 2026-07-28: https://blog.modelcontextprotocol.io/posts/2026-07-28
• Specification index: https://modelcontextprotocol.io/specification/latest