MCP-STL-004

Server does not rely on prior requests over the same connection

“Servers MUST NOT rely on prior requests over the same connection to establish context (e.g., capabilities, protocol version, client identity). Every request supplies this metadata in its _meta field.” — spec anchor

How to fix this

Read capabilities, protocol version and client identity from each request's own `_meta`, never from an earlier request on the same connection.

Example: failing and passing

The server refuses a complete, self-describing request because no earlier request on this connection set up its context.

Violates MCP-STL-004 · 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

{"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": "Call server/discover on this connection first"}}

The server answers the request using only the protocol version and capabilities in its own _meta.

Complies with MCP-STL-004 · 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

{"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 P1.2, against a streamable-http server on the modern protocol. What it reports:

pass: A second request carrying its own complete _meta was answered without relying on any earlier exchange

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-008.

Check your own server against MCP-STL-004

Probe P1.2 checks MCP-STL-004 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-002A client-supplied Mcp-Session-Id is ignored, not required
MCP-STL-003A cold modern request succeeds with no prior handshake
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