Multiple initialize calls per conversation breaks Mcp-Session-Id linking

[hwennnn]

Summary

initialize is being called multiple times within a single conversation, resulting in multiple Mcp-Session-Id values. My server relies on Mcp-Session-Id to link requests together (per the spec), and this was working ~3 days ago — but something changed and now it's broken.

What I'm seeing

sequenceDiagram
    participant Host as Host (Claude Desktop)
    participant Server as MCP Server

    Note over Host,Server: Before conversation starts
    Host->>Server: POST initialize
    Server-->>Host: Mcp-Session-Id: aaa-111

    Host->>Server: POST resources/read<br/>Mcp-Session-Id: aaa-111
    Server-->>Host: HTML (app UI)

    Host->>Server: POST tools/call (discover_run)<br/>Mcp-Session-Id: aaa-111
    Server-->>Host: { runId: null } (no run yet, expected)

    Note over Host,Server: User types prompt...
    Note over Host,Server: Second initialize — unexpected!
    Host->>Server: POST initialize
    Server-->>Host: Mcp-Session-Id: bbb-222

    Host->>Server: POST tools/call (run_web_automation)<br/>Mcp-Session-Id: bbb-222
    Note over Server: Stores run under bbb-222 ✅

    Host->>Server: POST tools/call (discover_run)<br/>Mcp-Session-Id: aaa-111
    Note over Server: Looks up aaa-111 → null ❌<br/>(run is under bbb-222)

Loading

My server stores a session→run mapping on run_web_automation, then the MCP App iframe calls discover_run to find that run. Because discover_run still uses the first session (aaa-111) but the run was stored under the second session (bbb-222), the lookup fails and the app can't show live status/screenshots.

What I'd expect

One initialize per conversation → one Mcp-Session-Id shared across model and app tool calls.

Happy to share server logs and more details if helpful.

Environment

• Host: Claude Desktop (latest)
• MCP Protocol Version: 2025-11-25
• Server: Custom Next.js MCP server (Streamable HTTP)
• MCP Apps SDK: @modelcontextprotocol/ext-apps

[Michael-WhiteCapData]

Mcp-Session-Id identifies one MCP transport session, not a Claude conversation or an application workflow. The host can create separate MCP clients/transports for the model and the App iframe, so one visible conversation does not imply one transport session.

Use an explicit application-level handle instead:

1. run_web_automation creates a cryptographically random runId.
2. It stores the run under the authenticated user plus that runId.
3. It returns runId in structuredContent (or result _meta if the value must be UI-only).
4. The App receives it in ontoolresult and passes it explicitly to discover_run, status, etc.
5. The server validates ownership and expiry on every lookup.

That design survives reconnects, multiple iframes, multiple MCP transports, horizontal scaling, and resumed UI state. It also avoids treating a transport identifier as an authorization capability.

This is now the protocol's explicit direction: the 2026-07-28 revision removes Mcp-Session-Id and says cross-call state should use server-minted handles passed as ordinary tool arguments: MCP draft changelog. For clients on 2025-11-25, the same application design still works and fixes the split-session behavior you observed.