What is MCP Multi Round-Trip Requests?

MRTR lets a server return an input_required result with inputRequests and requestState; the client gathers input and retries the original request with inputResponses.

What changed for MCP Tasks?

The 2026-07-28 revision moves Tasks into the io.modelcontextprotocol/tasks extension, uses tasks/get polling and tasks/update for client input, and removes tasks/list.

Does MRTR make destructive retries safe?

No. Applications still need authorization, scope confirmation, idempotency, state validation, expiry, and audit controls.

AI Agent - Aug 6, 2026

MCP Multi-Round-Trip Requests and Tasks Guide

Quick answer

MCP 2026-07-28 separates two multi-step patterns:

MRTR returns resultType: "input_required" with inputRequests and a requestState; the client gathers input and retries the original request with inputResponses.
The Tasks extension handles asynchronous work through a task handle, tasks/get polling, and tasks/update for client-to-server input.

Use MRTR when the current request needs clarification or approval. Use Tasks when work must continue asynchronously.

Pattern comparison

Need	MRTR	Tasks extension
Missing field or confirmation	Yes	Only if part of async task input
Long-running processing	No by itself	Yes
Resume mechanism	Retry original request with state and responses	Task handle plus extension methods
Server-initiated request	Replaced by returned input request	Client polls or updates task
Transport session required	No	No, but durable task state is required

All ordinary results now carry resultType: "complete"; clients must treat older results that omit it as complete.

Safe implementation sequence

Define which inputs can be requested and who may answer them.
Bind requestState or a task handle to user, tenant, action, scope, and expiry.
Sign or otherwise protect opaque state against tampering.
Make retries idempotent before adding approval or payment flows.
Revalidate authorization and current resource state on resume.
Expose explicit working, completed, failed, expired, and cancelled outcomes.
Test duplicate responses, stale state, reordered updates, timeout, and worker restart.

For protocol-level statelessness, use the migration guide. For deprecated server-initiated patterns, use the deprecation migration guide.

Frequently asked questions

What is MRTR?

A returned input-required result followed by a client retry carrying responses and the original request state.

What changed for Tasks?

Tasks moved to an extension with tasks/get and tasks/update; tasks/list was removed.

Are retries automatically safe?

No. Authorization, idempotency, state binding, expiry, and audit remain application responsibilities.

Official sources

Source check: August 6, 2026. Verify final extension schemas and SDK behavior before implementation.