SEP-3182: Request Idempotency - #3182

The new stateless/MRTR section draws a useful distinction between continuing an MRTR exchange and retrying a request. I think one lost-response case still falls between those definitions.

SEP-2322 makes the initial and continuation tools/call requests independent. That suggests each round can carry its own key: K1 for the call that returns input_required, then K2 for the continuation that can produce the side effect. If the K2 response is lost, retrying that same continuation is exactly the ambiguity this SEP is meant to solve. But the current equivalence rule compares only tool name and arguments; it ignores the continuation's inputResponses and requestState, even though those values can change the operation's outcome.

A compact conformance sequence would be:

• K1 returns input_required;
• K2 plus the echoed state and responses completes once;
• an identical retry with K2 replays the final result;
• changed state or responses with K2 conflicts before dispatch.

That does not reuse one key across the MRTR exchange; it scopes a key to each independent round. I would either include inputResponses and requestState in equivalence when present, or explicitly exclude MRTR-bearing calls from this SEP.

The linked reference implementation has a separate wire-level mismatch: client_demo.py passes idempotencyKey inside the tool's arguments, server.py declares it as a charge_guarded parameter, and that tool performs the deduplication. It never sends params.idempotencyKey, discovers tools.idempotency, or handles duplicate/conflict cases before generic tool dispatch. It is a useful application-level failure-mode demo, but it does not yet demonstrate the proposed protocol mechanism. A protocol fixture could make that boundary observable by checking the request field and discovery capability, then proving a duplicate or conflict never reaches the tool handler.

Thanks for the detailed review, both observations are helpful.

On MRTR, I think you've identified a genuine ambiguity rather than a disagreement. My intent was exactly what you describe: the initial request and each continuation are independent tools/calls, so they would naturally use different idempotency keys rather than one key spanning the entire exchange. The current FAQ was only trying to discourage reusing a single key across the whole MRTR flow.

The gap, as you point out, is that if this SEP is taken to apply to MRTR continuation requests, the current equivalence rule doesn't account for requestState or inputResponses, even though they influence the logical operation. I think there are two coherent approaches: explicitly extend equivalence to include those fields, or explicitly exclude MRTR-bearing tools/calls from this SEP. I'm currently leaning toward the latter, since one of the goals of this proposal has been to stay narrowly scoped rather than partially specifying MRTR semantics without implementation experience. I'll revisit that section and the accompanying FAQ to make the intended scope clearer. If you think the initial proposal should cover MRTR continuations as well, I'd be interested in hearing the reasoning or implementation experience behind that view.

On the reference implementation, that's also a fair observation. The current prototype was written to demonstrate the behavioral semantics—the duplicate-execution failure mode and the proposed deduplication/conflict behavior—rather than the final protocol integration. It predates the draft settling on a dedicated params.idempotencyKey field and capability negotiation, which is why the key is currently passed through as a tool parameter. I'll update the prototype so it aligns with the current draft, with deduplication happening before tool dispatch, using params.idempotencyKey, advertising the capability, and ensuring duplicate/conflicting requests are intercepted before reaching the tool handler.

Thanks again for taking the time to dig into the details—this is exactly the kind of review that helps tighten both the specification and the prototype.

Pushed the fixes for both points:

MRTR: explicitly scoped MRTR continuation requests out of this SEP, rather than leaving it ambiguous whether the existing equivalence rule applied to them. inputResponses/requestState aren't accounted for in equivalence today, and I'd rather say so directly than partially extend the mechanism without implementation experience behind it. Happy to revisit if there's a concrete case for covering it now.
Reference implementation: reworked so idempotencyKey travels as params.idempotencyKey (sibling of arguments, matching the SEP's request format) and deduplication happens in server-side dispatch before charge_guarded is ever invoked — the tool function itself now has no idempotency logic at all. Verified end-to-end, including a genuine concurrent-duplicate case (two overlapping requests for the same key — exactly one succeeds, the other is rejected as in-progress) and retention-window expiry. Also tightened the SDK version-pin note: on mcp==2.0.0, idempotencyKey isn't just an import-away — it's silently dropped at construction with no error, so the demo would appear to work while deduplicating nothing. The pin and the note both now reflect that explicitly.

Thanks again for the close read — both were real gaps, not just wording.

Happy to change the proposal to use a reserved _meta key instead if reviewers feel that's a better fit for MCP's extension model. My preference is still a dedicated field because the guarantee this SEP is trying to standardize depends on the value surviving end-to-end, and today multiple SDKs/frameworks have been observed dropping _meta (as discussed in the SEP/FAQ). If the WG believes _meta is the right long-term home and is comfortable making preservation a normative requirement, I'm happy to update the proposal accordingly.