Describe the bug
The Server class in the TypeScript SDK processes client-initiated requests (e.g., tools/list) and sends back responses after the server has sent its initialize response but before it has received the client's notifications/initialized notification.

This act of the server sending a response message can be interpreted as contravening the MCP specification guideline (Section 3.1.2: Initialization) which states: "The server SHOULD NOT send requests or notifications to the client before it has received the initialized notification..."

To Reproduce
Steps to reproduce the behavior:
A client sends an initialize request to an SDK-based server.
The server processes the request and sends back the initialize result.
The client then immediately sends another request, for example, tools/list (i.e., before sending the notifications/initialized notification).
Observe that the server processes the tools/list request and sends back the tools/list result to the client.

Expected behavior
Based on a strict interpretation of the "SHOULD NOT send" guideline, the server, upon receiving a client request like tools/list before notifications/initialized, should ideally:

Queue the request until notifications/initialized is received, or
Return a specific error indicating the server is awaiting notifications/initialized, or
At a minimum, refrain from sending the response payload until after notifications/initialized has been processed.

Actual behavior: The SDK's Server class processes the client's request (e.g., tools/list) and sends the corresponding result/response immediately, without waiting for the notifications/initialized notification from the client.

Logs
If applicable, add logs to help explain your problem.

Additional context
ode Reference: The current handling can be seen in the Server class constructor in src/server/index.ts (or packages/server/src/index.ts): Link to the relevant lines in the GitHub repository, e.g., https://github.com/modelcontextprotocol/typescript-sdk/blob/main/src/server/index.ts#L80-L86 The constructor sets up handlers for initialize and notifications/initialized (via oninitialized callback) but does not include logic to gate other incoming requests pending the notifications/initialized signal.

Impact: This behavior could lead to:

Issues if a client implementation is not fully prepared to handle operational responses until after it has sent notifications/initialized and considers the session fully established.
Potential interoperability issues if some clients or servers expect stricter adherence to this phase of the initialization sequence.