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

[imjvdn]

The transport specification defines an MCP session between a client and server; it does not promise one session per chat conversation. That does not explain the Claude Desktop change, but it means the transport session ID alone is a fragile key for your application's run.

A workaround would be to pass an explicit application ID:

• If run_web_automation opens the App view, return its runId in the tool result and have that view call discover_run({ runId }).
• If the iframe must exist before the run starts, generate a stable viewId when opening it. Return that ID in the initial tool result so both the model and view have it, require the start tool to accept it, and store viewId → runId independently of the MCP session. The iframe then polls discover_run({ viewId }).

Scope each lookup to the authenticated owner. Keep the normal session-header handling; the application ID is an additional correlation key.

The SDK documents a similar stable view-ID pattern, including passing the ID back to app-only tools. Applying it to your run mapping is a suggested workaround; I have not reproduced the Claude Desktop regression.