Duplicate `initialize` with changed parameters can overwrite `ServerSession.client_params`

[cclabadmin]

Initial Checks

• I confirm that I'm using the latest version of MCP Python SDK
• I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue

Description

After 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.

I 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.

The 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.

• src/mcp/server/session.py stores the client initialization request in ServerSession._client_params.
• ServerSession.client_params exposes that value.
• In both the stable release and the main snapshot I tested, the InitializeRequest handler assigns self._client_params = params.
• ServerSession.check_client_capability() later reads self._client_params.capabilities, so a duplicate initialize with different capabilities can affect capability-gated server logic.

What I observed

Reproduced on stable v1.27.1 (77431ebe7dda9ed0c61451b22d3e7f8d981bc092):

• stdio: a second initialize was accepted after notifications/initialized; a later ping still succeeded.
• stateful Streamable HTTP: a second initialize was accepted after notifications/initialized; a later ping still succeeded.
• stateless Streamable HTTP: a second initialize was accepted after notifications/initialized; a later ping still succeeded.

For 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:

Duplicate initialize parameters	Observed result
Same parameters	No state change
Changed clientInfo and capabilities	client_params.clientInfo and client_params.capabilities changed
Older protocolVersion (2024-11-05)	client_params.protocolVersion and client_params.clientInfo changed

On 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.

Expected behavior

If 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.

If this tolerant behavior is intentional, I think it should be either:

• a no-op once the session has already initialized, especially for changed parameters, or
• documented as same-session renegotiation, including whether ServerSession.client_params, client capabilities, client identity, and protocol version are allowed to change.

Example Code

import json

try:
    # Current main branch naming.
    from mcp.server.mcpserver import Context, MCPServer
except ImportError:
    # Latest stable release naming.
    from mcp.server.fastmcp import Context, FastMCP as MCPServer


mcp = MCPServer("dup-init-repro")


def field(obj, *names):
    if obj is None:
        return None
    for name in names:
        if hasattr(obj, name):
            return getattr(obj, name)
    return None


def dump(value):
    if value is None:
        return None
    if hasattr(value, "model_dump"):
        return value.model_dump(mode="json", by_alias=True)
    return value


@mcp.tool()
async def session_snapshot(ctx: Context) -> str:
    params = ctx.session.client_params
    return json.dumps(
        {
            "protocolVersion": field(params, "protocolVersion", "protocol_version"),
            "clientInfo": dump(field(params, "clientInfo", "client_info")),
            "clientCapabilities": dump(field(params, "capabilities")),
        },
        separators=(",", ":"),
        default=str,
    )


if __name__ == "__main__":
    mcp.run(transport="streamable-http")

'''
Request sequence:

1. Start the server.
2. Send a normal `initialize`.
3. Send `notifications/initialized`.
4. Call the `session_snapshot` tool and record the returned JSON.
5. Send another `initialize` on the same live session, but change `clientInfo` and/or `capabilities`.
6. Call `session_snapshot` again on the same session.

On `v1.27.1`, the second snapshot reflects the changed `clientInfo` / `capabilities`. On the `main` snapshot I tested, the second snapshot still reflects changed `capabilities`.
'''

Python & MCP Python SDK

- Python: `3.12.3`
- MCP Python SDK: `mcp==1.27.1` (`v1.27.1`, `77431ebe7dda9ed0c61451b22d3e7f8d981bc092`)
- Also reproduced on `main` snapshot `161834d4aee2633c42d3976c8f8751b6c4d947d5` (`v1.25.0-159-g161834d4`, pinned 2026-05-11)

[jshaofa-ui]

Root Cause Analysis & Fix

The Bug

In src/mcp/server/session.py, the _received_request() method (line 165) handles InitializeRequest at line 167-188. The handler unconditionally assigns self._client_params = params (line 170) with no guard to check if initialization has already completed.

After notifications/initialized is received (line 202 sets _initialization_state = Initialized), a second initialize request still matches the first case branch and overwrites _client_params, changing client capabilities and protocol version mid-session.

The Fix

Add a guard at the start of the InitializeRequest handler to reject duplicate initialize requests:

# In src/mcp/server/session.py, inside _received_request():
case types.InitializeRequest(params=params):
    # Reject duplicate initialize after initialization is complete
    if self._initialization_state == InitializationState.Initialized:
        with responder:
            await responder.respond(
                types.ErrorData(
                    code=types.INVALID_REQUEST,  # -32600
                    message="Initialize already completed. Duplicate initialize requests are not allowed.",
                )
            )
        return
    # ... rest of handler unchanged

Why This Works

• Uses existing _initialization_state enum (already tracks NotInitialized -> Initializing -> Initialized)
• Returns proper JSON-RPC error -32600 via responder.respond(ErrorData(...)) (established pattern in codebase)
• Stateless mode: _initialization_state starts as Initialized, so all initialize requests are rejected (correct)
• No new imports needed

Edge Cases

• Stateless mode: All initialize rejected (correct)
• Stdio/Streamable-HTTP: First init accepted, duplicates rejected
• Reconnection: New session = fresh state, no impact

This is a ~9-line fix for a protocol-level bug where client params can be silently changed mid-session.