createmcps.com

MCP-STL-002

A client-supplied Mcp-Session-Id is ignored, not required

“An Mcp-Session-Id header on a request: ignore it, and do not mint or echo session IDs.” — spec anchor

How to fix this

Ignore an `Mcp-Session-Id` that a client sends. Do not require it and do not reject the request over it — older clients will keep sending it, and refusing them is its own violation.

Example: failing and passing

The server rejects the request because of the client-supplied Mcp-Session-Id instead of ignoring it.
Violates MCP-STL-002 · HTTP
POST /mcp HTTP/1.1
Host: mcp.example.com
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/list
Mcp-Session-Id: 550e8400-e29b-41d4-a716-446655440000

{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {"_meta": {
  "io.modelcontextprotocol/protocolVersion": "2026-07-28",
  "io.modelcontextprotocol/clientCapabilities": {}}}}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"jsonrpc": "2.0", "id": 1, "error": {"code": -32600, "message": "Unknown session"}}
The server ignores the Mcp-Session-Id header and answers the request normally.
Complies with MCP-STL-002 · HTTP
POST /mcp HTTP/1.1
Host: mcp.example.com
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/list
Mcp-Session-Id: 550e8400-e29b-41d4-a716-446655440000

{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {"_meta": {
  "io.modelcontextprotocol/protocolVersion": "2026-07-28",
  "io.modelcontextprotocol/clientCapabilities": {}}}}

HTTP/1.1 200 OK
Content-Type: application/json

{"jsonrpc": "2.0", "id": 1, "result": {"resultType": "complete", "tools": [], "ttlMs": 300000, "cacheScope": "public"}}

How the validator checks this

Probe P5.3, against a streamable-http server on the modern protocol. What it reports:

pass
A client-supplied Mcp-Session-Id was ignored rather than rejected
fail
Rejected a request carrying Mcp-Session-Id (HTTP …). The spec says ignore it — refusing is a different violation, and older clients will keep sending it.

Quoted from the probe that runs this check, so it cannot drift from what the validator actually reports.

This rule is checked deterministically: a fail here is a certain violation, not an inference.

Checked in the same request as MCP-STL-001.

Check your own server against MCP-STL-002

Probe P5.3 checks MCP-STL-002 in the same request as 1 other rule, so one run shows your server's result for this rule next to the rest. Validate a server or read how the validator works.

Background on this topic: statelessness and Mcp-Session-Id explained.

Other Statelessness and session removal rules

  • MCP-STL-001Server never mints or echoes Mcp-Session-Id
  • MCP-STL-003A cold modern request succeeds with no prior handshake
  • MCP-STL-004Server does not rely on prior requests over the same connection
  • MCP-STL-005GET on the MCP endpoint returns 405
  • MCP-STL-006DELETE on the MCP endpoint returns 405
  • MCP-STL-007Last-Event-ID is ignored — streams are not resumable
  • MCP-STL-008tools/list does not vary per connection