No session/conversation identifier sent to MCP servers — cannot distinguish concurrent sessions

Description

When Claude Code, Claude Desktop, or claude.ai connects to an HTTP MCP server, there is no way for the server to identify which conversation or session a request belongs to. This makes it impossible to maintain per-conversation state on the server side.

The Problem

1. Mcp-Session-Id not sent back: The server returns mcp-session-id in the initialize response header (per MCP spec), but Claude does not echo it back on subsequent requests. Server logs show session_id_from_header=None on all post-init requests.

1. No conversation/instance identifier: Request headers contain only standard HTTP headers (accept, content-type, mcp-protocol-version, user-agent: Claude-User) plus tracing headers (traceparent, baggage). No conversation ID, instance ID, or session reference.

1. clientInfo is generic: The initialize request's clientInfo is always {"name": "claude-ai", "version": "0.1.0"} with no per-instance differentiation. The MCP Implementation schema doesn't include session/instance fields.

Impact

• Multiple concurrent users/conversations: With multiple Claude instances hitting the same MCP server (common in team settings), the server cannot distinguish requests from different conversations
• Per-conversation state: Cannot track what context has been delivered to which conversation (e.g., instructions, onboarding flows)
• Session management: The MCP spec defines Mcp-Session-Id for this purpose, but it doesn't work because the client doesn't send it back
• Fargate/Lambda deployments: Without session affinity, requests from the same conversation may hit different server instances, making in-memory state useless

Expected Behavior

At minimum, Claude should echo back the Mcp-Session-Id header that the server assigns during initialize, as required by the MCP Streamable HTTP transport specification:

"If the server responds with a Mcp-Session-Id header, the client MUST include it on all subsequent requests."

Ideally, Claude would also include a conversation/instance identifier (e.g., X-Claude-Conversation-Id or a field in clientInfo) so servers can distinguish concurrent sessions even across server restarts.

Environment

• Claude Code v2.1.87
• Claude Desktop (claude.ai)
• MCP Protocol Version: 2025-11-25
• Confirmed by inspecting all request headers server-side

Related Issues

• modelcontextprotocol/modelcontextprotocol#231 (API/Client-defined session IDs)
• anthropics/claude-code#25642 (Expose $CLAUDE_SESSION_ID)
• anthropics/claude-code#27142 (Stale Mcp-Session-Id bug)

🤖 Generated with Claude Code