Multi Round-Trip Request (MRTR) Proposal#7
Multi Round-Trip Request (MRTR) Proposal#7markdroth wants to merge 2 commits intomodelcontextprotocol:mainfrom
Conversation
| // Similar to existing JSONRPCResultResponse. | ||
| // Used in cases where the server needs the results of one or more requests | ||
| // of its own before it can complete the client's request. | ||
| export interface JSONRPCIncompleteResultResponse { |
There was a problem hiding this comment.
Agree with the proposal for tool calls,
Would like to discuss the Result Response. In #9 I propose two additional message format options, that extend or reuse existing concepts vs adding a new one.
My preference is Option 2 which extends the existing Tool Result Concept to encapsulate this new response type while being able to leverage existing messaging semantics.
There was a problem hiding this comment.
+1 to extending Tool Results. It's already polymorphic so adding new "request" types would be easier to do while maintaining backward compatibility when writing servers.
| 1. Client sends a CallToolRequest. | ||
| 2. Server sends back a single response (**not** an SSE stream) indicating | ||
| that the request is incomplete and that an elicitation request is required. | ||
| 3. Client sends a new CallToolRequest, completely independent of the |
There was a problem hiding this comment.
Edge case to consider: The server sends multiple requests. The client responds with one. Some options:
- [Preferred] Return a
400. The client is required by protocol to return all responses at the same time. - The client responds with the requests not answered. This seems less ideal as it's possible a client could answer the same server request multiple times.
There was a problem hiding this comment.
The problem is that I don't think the server can tell whether the client responded to all of the requests it was told to, because it doesn't know which server instance told it to send those responses. In upgrade cases, this may be difficult or impossible to tell.
I think it's fine for the server to just respond with whichever dependent requests it doesn't yet have. If the client sees the same request a second time because it didn't answer it the first time, that just means that the client can deal with the result of its own bug. :)
| id: RequestId; | ||
| // Requests issued by the server that must be complete before the | ||
| // client can retry. | ||
| dependent_requests: { [key: string]: ServerRequest }; |
There was a problem hiding this comment.
Proposal rather than a key:
Let's use 1685 for this. The goal of 1685 is to allow the server to pass context to the client that is echo'ed back to the server when the response is submitted in order to help the server process the response. That's effectively what is being done here. If the state is passed to the client, they then CAN use a machine readable key but they don't have to in cases where there is only one request (likely the vast majority), which simplifies clients and reduces complexity and allows us to keep this as a list.
Example: state: "github_login"
Separately, a ServerRequest is a JSON RPC request, so it will seem weird to nest them. For example, should the JSON RPC requirements that an id is supplied in the request and the response should mirror that be respected? Should we add a new type here, that is more clear/useful long term?
There was a problem hiding this comment.
+1 not having a unique ID for the dependent requests will be hard to implement in servers
|
Closing this as a duplicate of #12. |
| 1. Client sends a CallToolRequest. | ||
| 2. Server sends back a single response (**not** an SSE stream) indicating | ||
| that the request is incomplete and that an elicitation request is required. | ||
| 3. Client sends a new CallToolRequest, completely independent of the |
There was a problem hiding this comment.
The problem is that I don't think the server can tell whether the client responded to all of the requests it was told to, because it doesn't know which server instance told it to send those responses. In upgrade cases, this may be difficult or impossible to tell.
I think it's fine for the server to just respond with whichever dependent requests it doesn't yet have. If the client sees the same request a second time because it didn't answer it the first time, that just means that the client can deal with the result of its own bug. :)
4 participants
Initial draft of a proposal for the MRTR problem.
See previous discussion in the original document.