Add statelessMode to streamableHttp.ts

[rinormaloku]

Motivation and Context

Support stateless StreamableHTTP transport. Resolves this issue: #360

Currently, even when configured to return an undefined session ID (sessionIdGenerator: undefined;), Requests still have to be stateful due to the following check:

https://github.com/rinormaloku/typescript-sdk/blob/75078cf549f894b4aaf1d12ce183ab4a31333dea/src/server/streamableHttp.ts#L481-L498

The introduced statelessMode property improves the clarity and removes the "side effect" loaded onto sessionIdGenerator.

How Has This Been Tested?

Updated unit tests as well as manually, as described below:

Start a server and run the following tool call. It fails with the error shown below:

$ curl -X POST http://localhost:3030/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 3,
    "method": "tools/call",
    "params": {
      "name": "hello-world",
      "arguments": {
        "name": "NestJS Developer"
      }
    }
  }'

{"jsonrpc":"2.0","error":{"code":-32000,"message":"Bad Request: Server not initialized"},"id":null}%

With this change, the request will complete successfully.

Note: The initialization check is removed from the unit tests in streamableHttp.test.ts

Breaking Changes

• Users using stateless transport have to set the statelessMode option to true. Alternatively, we can still use the check for sessionIdGenerator being undefined, to set the statelessMode internally (or to simply set initialization to true). However, it would be good to improve this implicit meaning of sessionIdGenerator while it is still not widely used.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[wong2]

Why do we need a new parameter? I think sessionIdGenerator: undefined already indicates that this is a stateless server.

[rinormaloku]

Why do we need a new parameter? I think sessionIdGenerator: undefined already indicates that this is a stateless server.

Because it isn't a good practice to load one property with different meanings, and it's better to fix this sooner rather than later.

[NieXRYu]

Can this mr be approved? I cannot start my stateless server now.

[operation-hp]

For tempoary fix, you can use this code to send an initalisaton message
and manually initialise the stateless instamce. This way you code is more likely be compatible with future changes.
streamableHttp is still a WIP, sadly we are going to see lots of temp fixes.
`'
// Construct and send an initialization request to itself
const initRequest = {
jsonrpc: "2.0",
id: randomUUID(), // Use a proper ID
method: "initialize",
params: {
protocolVersion: "0.1.0",
capabilities: {
logging: {},
tools: { listChanged: true },
resources: { listChanged: true },
prompts: { listChanged: true }
},
clientInfo: {
name: 'share-gc-mcp',
version: '1.0.0',
description: 'AI Pedals API MCP Server (self-initialization)'
}
}
} as JSONRPCMessage;

// Send the initialization request to itself
console.log("Sending self-initialization request");
fetch('http://localhost:' + PORT + '/mcp', {
   method: 'POST',
   headers: {
     'Content-Type': 'application/json',
     'Accept': 'application/json, text/event-stream' // Add required Accept header
   },
   body: JSON.stringify(initRequest)
 }).catch(error => {
   console.error("Error sending self-initialization request:", error);

}); ''

[operation-hp]

this PR close this issue

#377

[rosaboyle]

Thank you for your detailed work on improving the stateless mode implementation in the StreamableHTTP transport. I appreciate the cleaner approach of having an explicit statelessMode option rather than overloading the meaning of sessionIdGenerator: undefined. This aligns better with good API design principles by making intent explicit.

However, I see that PR #377 has already been merged to address the immediate issue by using the existing pattern. While your approach has technical merit, for consistency with the current codebase, we might want to consider postponing this architecture change until a future release with proper deprecation notice.

Would you be interested in updating this PR to build on top of the merged changes in #377, perhaps as a feature enhancement for a future minor release? This would provide a cleaner transition path while maintaining backwards compatibility.