all scenarios

Negotiates a version from the future

version-too-new · Protocol versioning

Endpoint (Streamable HTTP)
https://chaos-mcp.thomascdnns.com/s/version-too-new/mcp
On the wire — recorded from a real request
your clientchaos-mcp01initializePOST /s/version-too-new/mcp200 OK · application/json · 4 ms"jsonrpc""2.0""id"1"result""protocolVersion""2026-06-18""capabilities""tools""serverInfo""name""chaos-mcp/version-too-new""version""1.0.0""instructions""chaos-mcp scenario: version-too-new — Negotiates a version from the future"02tools/listPOST /s/version-too-new/mcp200 OK · application/json · 2 ms"jsonrpc""2.0""id"2"result""tools""name""echo""description""Echo back the provided message.""inputSchema""type""object""properties""message""type""string""description""Text to echo"… 40 more lines

Symptom

what you'll observe

initialize returns a protocolVersion newer than any your client knows (here 2026-06-18). Spec-compliant clients disconnect; lax ones proceed and then mishandle newer message shapes.

Cause

what this reproduces

The server only speaks its own latest revision and ignores the client's requested protocolVersion during negotiation.

Fix

how you'd resolve it

When you don't support the requested version, fall back to a version you share — never force one the client never offered.

Try it with curl
bash
curl -sS -X POST \
  https://chaos-mcp.thomascdnns.com/s/version-too-new/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -d '
"jsonrpc""2.0"
"id"1
"method""initialize"
"params"
"protocolVersion""2024-11-05"
"capabilities"
"clientInfo""name""curl""version""1"

'