Add RFD: Streamable HTTP & WebSocket Transport

[alexhancock]

Adding an RFD for a streamable HTTP and websocket transport

[alexhancock]

cc @jh-block @benbrandt

[alpgul]

A project has already been developed for this feature, and I believe it would be better to keep it as a separate project to avoid increasing code maintenance overhead.

[agentcooper]

From what I understand Acp-Session-Id here is a transport specific ID. It is a confusing name because ACP session ID is expected to be created later on session/new (https://agentclientprotocol.com/protocol/session-setup#session-id).

[alexhancock]

This is a good point, thanks for catching.

Do you think it's sane to drop the transport specific id and have no Acp-Session-Id included in requests unless a session/new has been performed? Also interested in alternative resolutions.

[mikhailshilkov]

unless a session/new has been performed

session/prompt has a session_id parameter in its request, which seems to be a separate session ID (actual session ID, not tranport ID). It has to be different from Acp-Session-Id because the same Acp-Session-Id can call session/new multiple times, if I understand it correctly. I'm not sure how exactly Acp-Session-Id is supposed to be used in the proposal.

[anna239]

Do you think it's sane to drop the transport specific id and have no Acp-Session-Id included in requests

This won't work, as capabilities defined during the initialize phase, so when the client sends their session/new request, the server should know which this Session id. But I agree that the name is confusing here.

[anna239]

@alexhancock do I understand it correctly that you suggest opening multiple SSE (first on initialize request, then on session/new and then on session/prompt)? When are those streams closed and how does the agent decide which stream does some update belong to?

[alexhancock]

@alexhancock do I understand it correctly that you suggest opening multiple SSE (first on initialize request, then on session/new and then on session/prompt)?

Intent is to follow the request patterns of MCP's streamable http transport https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#sending-messages-to-the-server. From that spec:

"Every JSON-RPC message sent from the client MUST be a new HTTP POST request to the MCP endpoint"

When are those streams closed

"After all JSON-RPC responses have been sent, the server SHOULD close the SSE stream."

how does the agent decide which stream does some update belong to?

I don't have a perfect answer to this off the top of my head, but it likely relates to the discussion here about session ids.

Should there perhaps be a session id which only corresponds to the concept of ACP Session ID (nothing transport level) and then a request id to correspond to one client request within a session?

Open to ideas!

[anna239]

@alexhancock

"After all JSON-RPC responses have been sent, the server SHOULD close the SSE stream."

does it mean, that f.i. the first SSE stream that was opened for initialize request will be closed once initialize response is streamed? I think this won't work as the agent can send some data to the client after initialize response but before session/new is called