What is MRTR (Multi Round-Trip Requests) in MCP?

The short answer

// Legacy: the server starts its OWN request
Client → Server:  tools/call            (id: 1)
Server → Client:  elicitation/create    (a NEW request, id: 99)
Client → Server:  response to id: 99
Server → Client:  final result for id: 1

// Two conversations interleaved on one connection.

// Modern: the server only ever REPLIES
Client → Server:  POST tools/call       (id: 1)
Server → Client:  { "result": {
                     "resultType": "input_required",
                     "inputRequests": [ … ] } }

// client gathers the input, then re-sends the SAME call
Client → Server:  POST tools/call       (id: 2, same params
                                          + inputResponses)
Server → Client:  { "result": { "resultType": "complete", … } }

Why callbacks had to go

A server sending its own request assumes a channel that outlives a single request-response pair — something to send into, and a client listening on it. That is a session by another name, and the stateless core removed it.

MRTR expresses the same need using only replies. Everything the server wants to say arrives as the answer to something the client asked, which means a load balancer can route each leg independently, a serverless function can handle each one cold, and nothing has to stay warm between them.

The shape of an MRTR exchange

{
  "jsonrpc": "2.0", "id": 1,
  "result": {
    "resultType": "input_required",
    "inputRequests": [
      {
        "type": "elicitation/create",
        "message": "Which workspace should I export?",
        "requestedSchema": {
          "type": "object",
          "properties": { "workspace": { "type": "string" } },
          "required": ["workspace"]
        }
      }
    ]
  }
}

{
  "jsonrpc": "2.0", "id": 2, "method": "tools/call",
  "params": {
    "name": "export_data",
    "arguments": { "format": "csv" },
    "inputResponses": [
      { "type": "elicitation/create", "content": { "workspace": "acme" } }
    ],
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28"
    }
  }
}

Note the retry carries a new JSON-RPC id and the same arguments. It is a fresh request as far as the transport is concerned — which is the point. Nothing links the two except the data the client chose to carry forward.

What this changed for sampling, elicitation and roots

Three features previously worked by the server issuing a request. All three moved into inputRequests:

Worth reading twice: Roots, Sampling and Logging are also deprecated as features, independently of the mechanism change. If you are building new, the answer is not “port my callback to MRTR” but “do I need this at all?”

What a response stream may still carry

MRTR does not ban streaming. A server may still answer with text/event-stream — it just may not use that stream to start its own conversation.

X-Accel-Buffering: no is the one that bites in production rather than in testing: nginx buffers proxied responses by default, which holds an SSE stream until it completes and makes a working server look like it is hanging.

State between round trips

The server does not get to remember what it was doing. If the first leg did expensive work before discovering it needed input, that work is gone unless you deliberately carry it.

// A. Redo it. Simplest, and correct when it's cheap.
//    Ask for everything you might need BEFORE doing the work.

// B. Hand the client an explicit handle to pass back.
{
  "resultType": "input_required",
  "inputRequests": [ … ],
  "_meta": {
    "com.example/draftId": "draft_01HZY…"   // your own namespace
  }
}

// What you MUST NOT do: key the work to the connection,
// the client's IP, or an implicit "current operation" —
// that is MCP-STL-004, and it will work in testing and
// fail behind a load balancer.

The 7 result-shape rules we check

Frequently asked

Related