Skip to content

Proposal: explicitize the optionality of listening to server notiications on client over streamable http. #2003

@ivanbelenky

Description

@ivanbelenky

Context

The current specification (2025-11-25) states that:

### Listening for Messages from the Server
1. The client **MAY** issue an HTTP GET to the MCP endpoint. This can be used to open an
SSE stream, allowing the server to communicate to the client, without the client first
sending data via HTTP POST.

The server MAY respond 405 if the method is not allowed as it states here

3. The server **MUST** either return `Content-Type: text/event-stream` in response to
this HTTP GET, or else return HTTP 405 Method Not Allowed, indicating that the server
does not offer an SSE stream at this endpoint.

The problem

The implemented SDKs give no option to disable the trigger of the GET stream request for listening messages from the server. This appears contrary to the use of MAY in the above cited specification, i.e. "clients MAY issue this GET request".

Describe the solution you'd like

The requirements for a solution can be described by the following:

  • the Client SHOULD be the owner of the decision for listening to server updates when using streamable-http transport.
  • all sdks MUST implement a configuration listen_to_server_notification on client's streamable-http transport construction.
  • listen_to_server_notification MUST have type bool
  • listen_to_server_notification MUST default to TRUE

Alternatives

If the above is undesired it must be clarified in the specification that the client MUST attempt to start listening to messages from the Server.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions