Don't create sessions for requests without a sessionId

[mikekistler]

Describe the bug

Currently the C# SDK (http server) allows requests, e.g. tools/call, without a sessionId but creates and returns a sessionId in the response.

The TypeScript, Java, and Go MCP SDKs do not do this.

The Python SDK, while it does return a sessionId, this sesionId is unusable because the server knows that it was not generated by initialize -- requests using this sessionId fail with the server log message:

WARNING  Failed to validate request: Received request before initialization was complete

In addition, I do not think a strict reading of the spec allows creating a new session for any request other than initialize:

A server using the Streamable HTTP transport MAY assign a session ID at initialization time, by including it in an Mcp-Session-Id header on the HTTP response containing the InitializeResult

To Reproduce

Issue a tools/call request to the server without an mcp-session-id header.

POST {{HostAddress}}/
Accept: application/json, text/event-stream
Content-Type: application/json
MCP-Protocol-Version: 2025-06-18

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
        "name": "get_random_number",
        "arguments": {}
    }
}

The request succeeds and returns a newly minted sessionId in the mcp-session-id header of the response.

HTTP/1.1 200 OK
Connection: close
Content-Type: text/event-stream
Date: Thu, 20 Nov 2025 22:00:39 GMT
Server: Kestrel
Cache-Control: no-cache,no-store
Content-Encoding: identity
Transfer-Encoding: chunked
Mcp-Session-Id: B9-naagwnKD6Y3X5SzhXUw

event: message
data: {"result":{"content":[{"type":"text","text":"94"}]},"id":1,"jsonrpc":"2.0"}

Expected behavior

No sessionId should be returned in the response.

Additional context

This repo contains my investigations of the behavior of the other SDKs.

https://github.com/mikekistler/mcp-session-experiments

[halter73]

Expected behavior

No sessionId should be returned in the response.

I think it makes more sense to reject the request unless we're in Stateless mode in which case we never return a session ID anyway.

Some of the other SDKs are a bit lower level and require you to manage sessions manually, so I don't think all the experimental apps are using sessions in the first place. The TypeScript experiment is the moral equivalent of running the C# Stremable HTTP transport in Stateless mode. Written this way, tool call handlers will not be able to take advantage of features like sampling or elicitation even if the client supports it.

To support sessions using the TypeScript SDK, you need to manage the session ID to transport mapping yourself. In the simpleStremableHttp.ts example, it rejects non-initialize messages without a session ID which I think is the more appropriate behavior.

The Go experiment which uses NewStreamableHTTPHandler is more comparable to what we offer with MapMcp(), and it seems to also reject the tool call without a session ID due to that lack of initialization.

H:\> curl -X POST http://localhost:3001 `
>   -H "Content-Type: application/json" `
>   -d '{
>     "jsonrpc": "2.0",
>     "id": 1,
>     "method": "tools/call",
>     "params": {
>       "name": "get_random_number",
>       "arguments": {
>         "min": 1,
>         "max": 10
>       }
>     }
>   }'

event: message
data: {"jsonrpc":"2.0","id":1,"error":{"code":0,"message":"method \"tools/call\" is invalid during session initialization"}}

Depending on how strict we decide to make the default stateful mode, we could make it so ClientCapabiliites and ClientInfo are always initialized by the time user handlers run, but it's not possible to make this guarantee if we don't require a session ID. This isn't a guarantee we make today, but that's partly because we don't reject requests without a session ID. The other part is that we don't require initialization at the start of a session regardless even with the stdio transport.