mcpsnoop/docs/2026-07-28-mrtr-breaks-latency.md at main · kerlenton/mcpsnoop · GitHub
//blob/show" data-turbo-transient="true" />
Skip to content
Search or jump to...
Search code, repositories, users, issues, pull requests...
-->
Search
Clear
Search syntax tips
Provide feedback
--><br>We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel
Submit feedback
Saved searches
Use saved searches to filter your results more quickly
-->
Name
Query
To see all available qualifiers, see our documentation.
Cancel
Create saved search
Sign in
//blob/show;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
kerlenton
mcpsnoop
Public
Notifications<br>You must be signed in to change notification settings
Fork<br>23
Star<br>278
FilesExpand file tree
main
/2026-07-28-mrtr-breaks-latency.md
Copy path
Blame<br>More file actions
Blame<br>More file actions
Latest commit
History<br>History<br>History
66 lines (36 loc) · 7.26 KB
main
/2026-07-28-mrtr-breaks-latency.md
Copy path
Top
File metadata and controls<br>Preview
Code
Blame
66 lines (36 loc) · 7.26 KB
Raw<br>Copy raw file<br>Download raw file
OutlineEdit and raw actions
MCP's new spec quietly breaks latency measurement for every observability tool
The MCP 2026-07-28 revision is being written up all over the place, and almost all of it is about three things. The removal of the initialize handshake, the Tasks extension, and MCP Apps. There is a fourth change, tucked into a sub-page about a request pattern, and it is the one that broke something I maintain.
It is called Multi Round-Trip Requests, SEP-2322. On its own it reads like a transport detail. In practice it means that every tool measuring how long an MCP call took is now, quietly, wrong. Mine included, until I fixed it.
What actually changed
Before this revision, when a server needed something from the client mid-operation, say an elicitation, a sampling request, or a roots listing, it opened its own request back to the client over a held-open SSE stream and waited for the answer.
That standalone channel is gone. MRTR removes it outright, and the spec calls this a breaking change. A related rule, SEP-2260, says a server-initiated request may now only happen while the server is actively processing a client request. So instead of opening a free-standing request of its own, the server answers the client's request with an InputRequiredResult, a result whose resultType is input_required, carrying an inputRequests map of what it needs plus an opaque requestState blob. The client gathers the answers and re-issues the original request with inputResponses and the echoed requestState.
The detail the whole thing hangs on is in the spec, in plain language.
The JSON-RPC id MUST be different between the initial request and the retry, as<br>they are independent requests.
They have to be independent, because the entire point is that any stateless server replica can pick up the retry with no memory of the first leg. All the context rides in the payload.
Why that breaks measurement
Every MCP observability tool I know of correlates a request with its response by JSON-RPC id. It is the only identifier you get, so it is what everyone keys on.
MRTR makes one logical operation span several request and response pairs, each with a different id. So a tool keying on id sees N separate calls where there was one operation, most of them ending in a result that is not really a result but an I-need-more-input placeholder. And the duration of each fragment excludes the part that usually matters most, the seconds the human spent answering the elicitation.
Here is the concrete shape. A tools/call comes back in ten milliseconds with an input request. The user takes five seconds to answer. One more second for the real result. Six seconds of wall clock, one logical operation.
Measured through id-only correlation, which is what everything did before accounting for MRTR, you get this.
calls reported 2 (it was one operation)<br>duration measured 1s (the real answer took ~6s)<br>tool call count 2 (inflated)
The five seconds the user spent deciding vanish completely. On a server that uses elicitation for confirmations, think delete-these-three-files, that interval is exactly the thing you most want to see, and it is the thing that disappears.
Those numbers are not illustrative. They came out of running the proxy against a scripted MRTR exchange twice, once with plain id correlation and once with the fix. With the fix, one call, six seconds, one in the tool count. If you want to try it on real traffic rather than a fixture, the beta SDKs already speak the new pattern.
Correlating...