[HTTP+SSE] Throw the Initialization Exception Immediately for Invalid SSE Endpoint Instead of After Timeout

Problem
Currently, when the SSE Endpoint is misconfigured, the client waits until the initialization timeout (e.g., 60s) before throwing an generic initialization exception. This causes unnecessary delays and makes debugging difficult.

Examples settings:

• If MCP Server SSE Endpoint is: http://localhost:8080/sse
• When MCP Client is configured:
  • SSE Endpoint: http://localhost:8080/incorrect-sse
  • Request timeout: 60s
  • Initialization timeout: 60s

Behavior:

• Calling Client.initialize() waits 60s before throwing an exception. The test code and exception are shown in the figure below:
  

• Same issue occurs when:

  • The base URL points to a non-existent server. The test code and exception are shown in the figure below:
    

  • Access Token is misconfigured and the server requires authorization.

Expected Behavior

• Initialization exception should be thrown immediately when the server responds with an error (e.g., 404, 401, access denied), instead of waiting for the timeout.
• Exception should include status code and/or response body from the SSE endpoint to help diagnose configuration errors.

Technical Details

I checked the code, and the timeout issue occurs in the HttpClientSseClientTransport class when assigning the messageEndpointSink member variable. The initialization POST request keeps waiting for messageEndpointSink to be assigned. However, when the SSE Endpoint is incorrectly specified, the GET request never successfully returns the message endpoint, causing the initialization POST request to hang until the timeout occurs.

Affected Versions

• SDK 0.11.2
• SDK 0.12.1
• ...

Start in HttpClientSseClientTransport and trace how the initialization POST request waits for messageEndpointSink and how the SSE GET request handles invalid endpoints. Reproduce the incorrect endpoint, nonexistent server, and authorization-error cases, then verify that initialization reports the server error promptly with its status code or response body instead of waiting for the initialization timeout.