Conversation
markdroth
left a comment
markdroth
left a comment
There was a problem hiding this comment.
This looks really good! Comments are mostly minor.
| } | ||
| ``` | ||
|
|
||
| After sending `tasks/input_response`, the requestor **SHOULD** then resume polling via `tasks/get`. |
There was a problem hiding this comment.
I think we need to say something here about the atomicity issue: when the client first polls tasks/get after calling tasks/input_response, it may still see the task in state input_required with the same input requests that the client has just finished replying to. The client is expected to ignore any input requests whose keys it has already responded to.
| @@ -0,0 +1,292 @@ | |||
| --- | |||
There was a problem hiding this comment.
Note: I'm seeing a bunch of typos/grammatical issues. Suggest just getting LLM to find/fix those. I won't point them out and instead focus more on the content.
There was a problem hiding this comment.
yup planning on doing a full polish pass once we get content into a reasonable state.
| <Note> | ||
| Multi Round-Trip Requests (MRTR) was introduced in 2026-06-30 of the MCP specification. | ||
| This replaces the previous approach of sending server-initiated rquests. | ||
| Servers **MUST** send server-to-client requests (such as | ||
| `roots/list`, `sampling/createMessage`, or `elicitation/create`) using the MRTR pattern. | ||
| The previous pattern of server-initiated requests is no longer supported. This is a breaking change. | ||
| </Note> |
There was a problem hiding this comment.
we should probably mention briefly what the previous approach was so that this statement stands on its own
| provides a standardized way to handle these server-requests without requiring a shared storage layer across | ||
| server instances or requiring stateful load balancing. | ||
|
|
||
| ### Core Types |
There was a problem hiding this comment.
I'd suggest starting with a high-level overview of how it works (with mermaid diagram) rather than jumping straight into types (which are hard to understand without any context).
| This response **MAY** be sent either as a standalone response or as the final message on an SSE stream. | ||
| If using an SSE stream, servers **MUST NOT** send any message on the stream after the `IncompleteResult`. | ||
| 1. The `IncompleteResult` **MAY** include an `inputRequests` field. | ||
| 1. The `IncompleteResult` **MAY** include a `requestState` field. If specified, this field is an opaque string meaningful only to the server. Servers are free to encode the state in any format (e.g., plain JSON, base64-encoded JSON, encrypted JWT, serialized binary). |
There was a problem hiding this comment.
Hmm, do we really want this to be so permissive? If we say this, I guarantee servers will return plain JSON, and we are guaranteed to see a CVE. I think we should just specify that it MUST be signed and encrypted with protections against replay attacks also.
i.e. rather than "you can do whatever you want, but if you care about security, you should do xyz" it should be "you must do xyz" and MAYBE with a small "(but if you REALLY KNOW WHAT YOUR'E DOING AND IN A TRUSTED ENVIRONMENT then you can consider plain json)" at the end -- but tbh, I'd rather this was just a MUST and people go against it at their peril.
There was a problem hiding this comment.
Have we thought through the potential for cross-request replay attacks and mitigations?
client sends request R1
server responds with input required, state=S1
client responds
request completes
client then sends request R2
server responds with input required, state=S2
**client responds with state=S1
Depending on the request, S1 may be valid state, signed with the same key as S2 -- but may allow the user to do something that they weren't supposed to do (e.g. reclaim a coupon twice).
We probably need to say that servers need sign with the request ID, or a new secret per request or something.
There was a problem hiding this comment.
Is this any different from an HTTP cookie value? The value can be anything the server wants, and if the server sets it to something that isn't validated and that causes a security flaw, then it's a security flaw in the application, not a security flaw in the HTTP protocol.
I think it should really be up to the application to figure out what they need here. I think we need to point out that this is something for the application to consider, but we shouldn't artificially mandate what the application decides to do about it -- they will know the needs of their use-case better than we do.
Co-authored-by: Peter Alexander <pja@anthropic.com>
Co-authored-by: Mark D. Roth <roth@google.com>
…ontextprotocol into mrtr-docUpdates
3 participants
Updating Spec Docs to reflect the changes in this SEP