MCP Multi-Round-Trip Requests Explained

Status in the 2026-07-28 spec: core (a required message pattern)

Multi-round-trip requests (MRTR) are how an MCP server asks for more information in the middle of a request without sending its own request to the client. The server replies with a result marked input_required that lists what it needs. The client gathers the answers and sends the original request again, with the answers attached.

MRTR arrived in the 2026-07-28 spec. It replaced the older pattern where servers sent elicitation/create, sampling/createMessage or roots/list requests back to the client. The MRTR page calls this "a breaking change."

This page explains the pattern in plain English, as of October 2026.

What MRTR is

The spec describes a four-step flow:

1. The client sends a request with the parameters for the operation.
2. The server decides it needs more information and responds asking for it.
3. The client gathers that information "from the user or other sources," then retries the original request with it attached.
4. The server now has enough to finish and returns the final result.

The message patterns page lists MRTR as one of three core patterns, next to plain request-and-response and subscriptions. All implementations must support the message patterns.

Why it exists

The old approach did not fit a stateless, load-balanced world. SEP-2322, the proposal behind MRTR, walks through the problem. A tool call lands on server instance A. Server A sends an elicitation request on a stream. The user's answer comes back as a separate request, which the load balancer may send to instance B. Server A "must somehow discover the elicitation response delivered to server B."

The SEP notes that "the vast majority of MCP tools will be ephemeral," meaning they keep no state between steps, and "it is extremely common for tools to be deployed in a horizontally scaled, load balanced service." MRTR optimizes for that case. The server packs whatever it needs into the reply, and the retry carries it back. See why MCP became stateless for the bigger picture.

How it works

Step 1: the server asks

The server returns an InputRequiredResult. This example is trimmed from the spec to one elicitation request:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "github_login": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Please provide your GitHub username",
          "requestedSchema": {
            "type": "object",
            "properties": { "name": { "type": "string" } },
            "required": ["name"]
          }
        }
      }
    },
    "requestState": "AEAD-protected blob"
  }
}

The two fields:

Every input-required result must include at least one of the two.

Step 2: the client answers by retrying

The client asks the user, then sends the original tools/call again with a new ID. It adds inputResponses, keyed to match, and the exact requestState. The answer for the key above looks like this, per the spec:

{
  "github_login": {
    "action": "accept",
    "content": { "name": "octocat" }
  }
}

Step 3: the server finishes

The server reads the answers and the state, completes the work and returns a normal result with resultType: "complete". The spec stresses that "the server processing the retry does not need any information beyond what is directly present in the retry request."

Rules worth knowing

Server side

• Input-required results are allowed only on prompts/get, resources/read and tools/call.
• A server "MUST NOT send an inputRequests that the client has not declared support for in its capabilities." No elicitation capability, no elicitation request. See MCP capabilities explained.
• Servers "MUST NOT assume that clients will fulfill the inputRequests or retry." They may ask again if answers are missing, rather than returning an error.

Client side

• If inputRequests is present, the client must build those answers before retrying.
• The client must echo requestState exactly, and must not "inspect, parse, modify, or make any assumptions about" it.
• "The JSON-RPC id MUST be different between the initial request and the retry."
• The input fields apply only to that retry, never to other parallel requests.

Security: requestState is untrusted

Because requestState passes through the client, a malicious client could tamper with it. The spec is firm: servers "MUST treat requestState as an attacker-controlled input." If it influences authorization, resource access or business logic, servers must protect its integrity, for example with an HMAC or AEAD, and reject state that fails the check.

To limit replay, servers SHOULD bind the state to the signed-in user, a short expiry and the original request. The spec warns that this still does not guarantee single use. One-time actions, such as a redemption, need a server-side check. Our guide to MCP security risks covers related threats.

What changed across spec versions

• 2025-06-18 added elicitation as a server-to-client request, per its changelog.
• 2025-11-25 added URL-mode elicitation, along with a notifications/elicitation/complete notification and an elicitationId field, per its changelog.
• 2026-07-28 introduced MRTR and the required resultType field. It removed the elicitation-complete notification and elicitationId, since "the client learns the outcome of an out-of-band interaction by retrying the original request," per the 2026-07-28 changelog.

Sampling and roots can still be requested through MRTR, but both were deprecated in the same release. In practice, MRTR's main long-term job is elicitation.

Common mistakes

• Reusing the request ID on the retry. The retry is a new, independent request.
• Trusting requestState blindly. Sign or encrypt it whenever it affects who can do what.
• Asking for undeclared inputs. Check the client's capabilities first.
• Returning input-required on other methods. Only three methods allow it.
• Keeping the waiting work in server memory. That defeats the purpose. Encode what you need in requestState, or use the Tasks extension for long jobs.

Next step

MRTR shows how the spec can change shape between versions. Learn how those changes are announced, phased in and retired in MCP versioning and deprecation policy, or see the MCP specification hub.

Frequently asked questions