Canonical: https://botbento.com/blog/mcp-mrtr-elicitation-sampling-roots/ Format: Markdown representation of the public HTML page. [Home](/) / [Blog](/blog/) FIELD NOTES / 4 MIN READ # MCP Replaced Server-Initiated Requests With MRTR. What Changes for Your Bot? The MCP 2026-07-28 specification replaced server-initiated elicitation, sampling, and roots requests with a new pattern called Multi Round-Trip Requests (MRTR). Instead of a server holding a request open while it asks the client something mid-call, the server now returns an interim result and the client retries the original call with answers attached. If your bot's MCP client code still expects the old stream-based pattern, it will stop working against servers on the current spec. By BotBento Editorial · Published 2026-10-09 · Updated 2026-10-09 AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. [Editorial policy](/editorial/). ## In this article - [What MRTR actually replaces](#what-changed) - [Worked example: a delete-files confirmation](#worked-example) - [Where this breaks if you don't update](#failure-paths) - [What to actually do about it](#decision)[Read as Markdown ](/text/blog/mcp-mrtr-elicitation-sampling-roots/index.md) ## Key takeaways - MRTR replaces server-initiated roots/list, sampling/createMessage, and elicitation/create requests; the old held-open-stream pattern is no longer supported under MCP 2026-07-28. - A server now signals it needs input by returning resultType: "input\_required" with named inputRequests; your bot must resolve them and retry the original tools/call with inputResponses and the echoed requestState. - A server cannot send an input request type your client hasn't declared in its capabilities, and requestState must be echoed back exactly, unmodified, on every retry. ## What MRTR actually replaces Before the 2026-07-28 MCP spec, a server that needed something from the client mid-call — a confirmation, a sampled completion, an updated list of roots — sent a separate server-to-client request while the client's original call stayed open on a live stream. That pattern is gone. The current spec requires servers to send these interactions using MRTR instead, and the previous server-initiated pattern is no longer supported. Under MRTR, a tool call doesn't get interrupted by a side request. The server instead returns an incomplete result containing one or more input requests, and the client fulfills those and retries the original call with the answers attached. Every result in the current spec carries a required resultType field: "complete" for an ordinary finished result, or "input\_required" for an interim result that needs the client to do something before the call can finish. Clients talking to a server on an earlier protocol revision that omits this field must treat the missing value as "complete" — don't assume input\_required is the default. This matters because elicitation, sampling, and roots are the three mechanisms MCP gives a tool to ask the client for something it doesn't already have. If your bot connects to any MCP server that confirms destructive actions, asks the client's model to reason about something, or needs an updated filesystem root, that interaction now happens through this result-and-retry shape, not through a held-open connection. Sources: [Multi Round-Trip Requests - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr), [Key Changes - Model Context Protocol](https://modelcontextprotocol.io/specification/2026-07-28/changelog). ## Worked example: a delete-files confirmation Say your bot calls a tool named delete\_files on an MCP server. The server wants user confirmation before it deletes anything — this used to be a mid-call elicitation/create request sent down an open stream. Under MRTR, the server instead returns something shaped like: resultType "input\_required", an inputRequests map with one entry keyed "confirm" whose value is a full elicitation/create request asking "Delete 3 files?" with a requestedSchema expecting a boolean confirmed field, and a requestState string that is opaque and tamper-evident. Your client code resolves that single input request — in practice, surfacing the question to whoever or whatever approves the bot's actions — and then retries the exact same tools/call, this time attaching inputResponses keyed to "confirm" with the answer, and echoing requestState back unchanged. The server picks up where it left off and returns a resultType: "complete" result once the deletion is done or declined. The same shape covers sampling and roots. A tool that needs the client's model to draft text mid-call returns an input\_required result with a sampling/createMessage request instead of an elicitation one; a tool that needs an updated list of client-exposed directories does the same with roots/list. Your client-side handling logic is the same regardless of which of the three kinds of request arrives — only the request body differs. Sources: [Multi Round-Trip Requests - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr), [The 2026-07-28 Specification](https://blog.modelcontextprotocol.io/posts/2026-07-28/). ## Where this breaks if you don't update The most direct failure: if your bot's MCP client library predates this spec revision and still expects a server to hold a request open and send a side-channel server-to-client message, it simply won't understand an input\_required result. The call will look finished when it isn't, or your client will wait on a stream that never arrives, because the old server-initiated pattern is no longer part of the protocol. A second failure is subtler. The spec requires a server not to send an input request of a kind the client hasn't declared support for in its capabilities. If your bot's client never registered an elicitation or sampling handler, a well-behaved server won't try to use that path — but a server that does send one anyway, or a client that silently ignores a capability mismatch, is a sign your integration test coverage has a gap worth closing before it costs you a stuck task. A third failure is around requestState. It's described as opaque and tamper-evident, meaning the server expects to get the exact string back on retry. If your bot's code logs it, truncates it, or tries to parse and rebuild it instead of passing it through untouched, the server-side resumption will likely reject the retry or lose track of where the multi-step operation was. Sources: [SEP-2322: Multi Round-Trip Requests - Model Context Protocol](https://modelcontextprotocol.io/seps/2322-MRTR), [Multi Round-Trip Requests - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr). ## What to actually do about it Check which protocol revision your MCP client SDK defaults to. SDKs built around the current spec default to 2026-07-28 and therefore to MRTR; if your dependency is older, confirm whether it's been updated or whether you need to pin to a newer release before connecting to any server that uses elicitation, sampling, or roots. If your bot's tools never need user confirmation, a sampled completion, or a roots lookup, you can skip registering handlers for those three — but still handle the resultType field defensively, since a future tool addition on the server side could start using one of them without warning you in advance. If your bot does rely on any of the three, write a fixture that deliberately triggers the input\_required path — a tool call you know will ask for confirmation — and verify your retry logic resolves the request, attaches inputResponses under the right key, and echoes requestState unchanged. That's the concrete test that tells you whether your MRTR handling actually works, rather than assuming the SDK handles it transparently. Sources: [Multi Round-Trip Requests - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr), [Multi Round-Trip Requests (MRTR)](https://csharp.sdk.modelcontextprotocol.io/v2/concepts/mrtr/mrtr.html). ## Primary sources Sources checked 2026-10-09. Standards and product documentation can change; follow the linked version when implementing. - [Multi Round-Trip Requests - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr) — Model Context Protocol - [Key Changes - Model Context Protocol](https://modelcontextprotocol.io/specification/2026-07-28/changelog) — Model Context Protocol - [The 2026-07-28 Specification](https://blog.modelcontextprotocol.io/posts/2026-07-28/) — Model Context Protocol - [Multi Round-Trip Requests (MRTR)](https://csharp.sdk.modelcontextprotocol.io/v2/concepts/mrtr/mrtr.html) — Model Context Protocol C# SDK - [SEP-2322: Multi Round-Trip Requests - Model Context Protocol](https://modelcontextprotocol.io/seps/2322-MRTR) — Model Context Protocol BotBento is in development. [Suggest a correction](/contact/).