René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Duplicate `initialize` with changed parameters can overwrite `ServerSession.client_params`","articleBody":"### Initial Checks\n\n- [x] I confirm that I'm using the latest version of MCP Python SDK\n- [x] I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue\n\n### Description\n\nAfter a normal MCP initialization flow, a Python SDK server accepts another `initialize` request on the same live connection/session and returns a normal `initialize` result.\n\nI agree that the spec does not explicitly say every repeated `initialize` must be rejected. My concern is narrower: after the session has already moved into normal operation, a later same-session `initialize` with different parameters can update the server's stored client initialization parameters.\n\nThe MCP lifecycle documentation describes initialization as the first client/server interaction and says the operation phase uses the negotiated protocol version and capabilities. In that model, silently changing the stored client identity/capabilities/protocol version after operation has begun seems surprising unless the SDK intentionally supports same-session renegotiation.\n\n- `src/mcp/server/session.py` stores the client initialization request in `ServerSession._client_params`.\n- `ServerSession.client_params` exposes that value.\n- In both the stable release and the `main` snapshot I tested, the `InitializeRequest` handler assigns `self._client_params = params`.\n- `ServerSession.check_client_capability()` later reads `self._client_params.capabilities`, so a duplicate `initialize` with different `capabilities` can affect capability-gated server logic.\n\n### What I observed\n\nReproduced on stable `v1.27.1` (`77431ebe7dda9ed0c61451b22d3e7f8d981bc092`):\n\n- `stdio`: a second `initialize` was accepted after `notifications/initialized`; a later `ping` still succeeded.\n- stateful Streamable HTTP: a second `initialize` was accepted after `notifications/initialized`; a later `ping` still succeeded.\n- stateless Streamable HTTP: a second `initialize` was accepted after `notifications/initialized`; a later `ping` still succeeded.\n\nFor stateful Streamable HTTP on `v1.27.1`, I added a local diagnostic tool that reads `ctx.session.client_params` before and after the duplicate `initialize` on the same session:\n\n| Duplicate `initialize` parameters | Observed result |\n|---|---|\n| Same parameters | No state change |\n| Changed `clientInfo` and `capabilities` | `client_params.clientInfo` and `client_params.capabilities` changed |\n| Older `protocolVersion` (`2024-11-05`) | `client_params.protocolVersion` and `client_params.clientInfo` changed |\n\nOn the frozen `main` snapshot (`161834d4aee2633c42d3976c8f8751b6c4d947d5`), the same duplicate-initialize acceptance still reproduced. My diagnostic snapshot directly observed `client_params.capabilities` changing after a duplicate `initialize` with changed capabilities on both `stdio` and stateful Streamable HTTP.\n\n### Expected behavior\n\nIf same-session duplicate initialization is not intended, I would expect the server to reject the later `initialize` after normal operation has begun, for example with a JSON-RPC `-32600 Invalid Request` error.\n\nIf this tolerant behavior is intentional, I think it should be either:\n\n- a no-op once the session has already initialized, especially for changed parameters, or\n- documented as same-session renegotiation, including whether `ServerSession.client_params`, client capabilities, client identity, and protocol version are allowed to change.\n\n### Example Code\n\n```Python\nimport json\n\ntry:\n    # Current main branch naming.\n    from mcp.server.mcpserver import Context, MCPServer\nexcept ImportError:\n    # Latest stable release naming.\n    from mcp.server.fastmcp import Context, FastMCP as MCPServer\n\n\nmcp = MCPServer(\"dup-init-repro\")\n\n\ndef field(obj, *names):\n    if obj is None:\n        return None\n    for name in names:\n        if hasattr(obj, name):\n            return getattr(obj, name)\n    return None\n\n\ndef dump(value):\n    if value is None:\n        return None\n    if hasattr(value, \"model_dump\"):\n        return value.model_dump(mode=\"json\", by_alias=True)\n    return value\n\n\n@mcp.tool()\nasync def session_snapshot(ctx: Context) -\u003e str:\n    params = ctx.session.client_params\n    return json.dumps(\n        {\n            \"protocolVersion\": field(params, \"protocolVersion\", \"protocol_version\"),\n            \"clientInfo\": dump(field(params, \"clientInfo\", \"client_info\")),\n            \"clientCapabilities\": dump(field(params, \"capabilities\")),\n        },\n        separators=(\",\", \":\"),\n        default=str,\n    )\n\n\nif __name__ == \"__main__\":\n    mcp.run(transport=\"streamable-http\")\n\n'''\nRequest sequence:\n\n1. Start the server.\n2. Send a normal `initialize`.\n3. Send `notifications/initialized`.\n4. Call the `session_snapshot` tool and record the returned JSON.\n5. Send another `initialize` on the same live session, but change `clientInfo` and/or `capabilities`.\n6. Call `session_snapshot` again on the same session.\n\nOn `v1.27.1`, the second snapshot reflects the changed `clientInfo` / `capabilities`. On the `main` snapshot I tested, the second snapshot still reflects changed `capabilities`.\n'''\n```\n\n### Python \u0026 MCP Python SDK\n\n```Text\n- Python: `3.12.3`\n- MCP Python SDK: `mcp==1.27.1` (`v1.27.1`, `77431ebe7dda9ed0c61451b22d3e7f8d981bc092`)\n- Also reproduced on `main` snapshot `161834d4aee2633c42d3976c8f8751b6c4d947d5` (`v1.25.0-159-g161834d4`, pinned 2026-05-11)\n```","author":{"url":"https://github.com/cclabadmin","@type":"Person","name":"cclabadmin"},"datePublished":"2026-05-15T13:34:52.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/2605/python-sdk/issues/2605"}