How do servers make requests to clients?

[kyleconroy]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

I'm working on a Go client / server implementation but running into a big of ambiguity try to implement certain features of the base protocol. This graph seems to indicate that normal operation includes clients making requests to servers, servers responding, and clients possibly sending notifications.

When trying to to implement logging, sampling, etc. the specification mentions the server making requests to the client. How is this process supposed to work? Do servers write requests back to the client? In this case the messages coming in via stdin could also be responses from the client?

[jspahrsummers]

When trying to to implement logging, sampling, etc. the specification mentions the server making requests to the client. How is this process supposed to work? Do servers write requests back to the client? In this case the messages coming in via stdin could also be responses from the client?

Yes, this is correct. Messages arriving on stdin will be JSON-RPC requests, notifications, or responses. The server, in turn, sends its messages to the client over stdout. Since both directions can contain requests and responses, the communication is bidirectional.

[ppipada]

@jspahrsummers @kyleconroy I have the same question but wrt SSE transport. Can you please help?

Basically, how would the req/response data flow look like for client features (e,g sampling).
After the initial negotiation and establishment of sse stream + post endpoint, how would server fetch a response from the client?
I do understand that server would formulate a SSE request and stream it to the client as a SSE message.
Question is how would the server get a response for this request from the client?
As SSE event specifically is unidirectional, is client supposed to send some out of band "notification" or "Request" to the server with the response for this server event?

I could not find a lot of details wrt this in the spec site. If it is present someplace and i have missed, It would be great to get it. I would be happy to look at any docs or code too for this.

[jspahrsummers]

I think this is covered here—did you see the request flow diagram? https://spec.modelcontextprotocol.io/specification/2024-11-05/basic/transports/#http-with-sse

[ppipada]

Thank you for your response. I did see that before. The question still remains though.

Note that I am specifically asking about Client features to be used by server. E.g Sampling.

Going step by step:

• I do understand that whenever server wants to get some response from the client it will send a SSE event as a standard message type.
• This events working for notification type is straightforward as server is not really expecting any response and hence it can send the event and forget about it like any other SSE event.
• Question is if the above step is for a Request that expects a response. E.g Sampling.

In the above diagram it is mentioned that client will send everything to server as a post message and server sends to client sse events.

Now in this particular case, is the server listening to the post message as a response type too ?
I.e other than normal request types that it is serving on the jsonrpc endpoint, is the server also serving some response types and has to build some mechanism to connect SSE request event to the incoming Response post message?

Thanks for your patience and help.
Regards,

[jspahrsummers]

All messages (which include all requests, responses, and notifications) from the server flow over the SSE stream, and all messages from the client arrive as POSTs. JSON-RPC includes a message ID field to link up requests and responses, so even though they are transmitted in different ways, they're connected to each other.

Note that even using the same stream wouldn't be sufficient to link requests and responses if the ID field weren't there, because different requests can be interleaved.

[ppipada]

Thank you for the clarification. This answers my query.

I think the main confusion was from the inherent HTTP protocol assumption related to request response i.e post request sends a response back on same connection and SSE is for async push events (which is a separate connection). I understand now that MCP is looking at HTTP post as forward and SSE as a backward connection and data flow is unidirectional per connection.

Thanks again.