How Interactive MCP Workflows Work: MRTR, Elicitation, Tasks, and Stateless Servers

The 2026-07-28 Model Context Protocol specification changed a foundational assumption: the protocol core is now stateless. The initialization/session handshake is gone, and interactive server-to-client workflows are redesigned around ordinary request/response infrastructure.

That does not mean MCP applications cannot maintain state. It means protocol-level transport sessions no longer have to carry it invisibly.

For interactive workflows, two concepts are especially important:

Multi Round-Trip Requests (MRTR) for a server that needs additional client/user input while processing an operation;
Tasks, now an extension, for long-running work whose lifecycle outlives one immediate response.

These solve different problems.

Why MCP moved away from transport sessions

Earlier MCP designs relied more heavily on initialization, session identifiers, and persistent bidirectional behavior.

That complicates ordinary web infrastructure:

client → load balancer → which server instance owns this session?

A stateless request can instead land on any compatible instance because the request carries the protocol/client information it needs. The July 2026 specification removed the initialize/initialized exchange and Mcp-Session-Id; optional server/discover can be used when a client wants capabilities before making other requests.

This makes MCP easier to place behind normal load balancers, gateways, and horizontally scaled services.

Stateless protocol does not mean stateless application

A tool can still create durable application state.

For example:

create_analysis_job(file)
→ { analysis_id: "a_123" }

get_analysis(analysis_id="a_123")
→ {...}

The state is explicit. The model/client can carry the handle between calls rather than relying on hidden transport session state.

This is often easier to debug because the dependency appears in the tool transcript.

The interactive problem

Imagine a tool call:

deploy_project(project="api", environment="production")

The server discovers that production deployment requires confirmation:

This deployment will replace version 42. Continue?

A stateless protocol cannot depend on the server opening an unrelated prompt later and hoping the original client session is still attached.

MRTR makes the interaction part of the original logical operation.

Multi Round-Trip Requests in one picture

The current MCP design lets a server return resultType: "input_required" with requests that need answers. The client gathers those answers and retries the original call with inputResponses; requestState can be echoed so the server can resume the logical operation without relying on a transport session.

Conceptually:

The second request can be handled by another compatible server instance when the returned state contains or references everything needed to resume safely.

Request state must be treated as untrusted round-trip data

A subtle but important detail: requestState travels through the client and comes back to the server. A server should not trust it merely because the server originally minted it.

If the state carries security-sensitive continuation information, protect it with integrity/authenticity controls and bind it to the relevant principal, operation, parameters, and expiry as appropriate.

The client should also:

associate it with the correct server and logical request;
avoid reusing it across unrelated servers;
apply size/storage limits;
avoid logging sensitive contents.

Opaque continuation state is protocol data, not inherently trusted state.

Elicitation is a request for information, not automatic permission

An elicitation can ask the client/user for information needed to continue.

Examples:

Which environment?
What date range?
Confirm this cost?
Choose one of these resources.

The client remains responsible for presenting that request appropriately and deciding what information may be supplied.

Do not treat arbitrary server text as a trusted system instruction. The server is another trust boundary.

Elicitation and client tool approval are different

This distinction is important.

A host may already have a policy such as:

Disabled
Ask
Always Allow

for whether a model may invoke a tool.

The tool itself can then require additional user input via an interactive MCP flow.

Those are separate gates:

model proposes tool
        ↓
client execution policy
        ↓
tool/server begins operation
        ↓
server requests additional input
        ↓
client/user supplies or rejects it

An MCP server asking “Are you sure?” should not replace the host’s own authorization policy for sensitive tool execution.

See How MCP Tool Permissions Work.

The client should render input requests as data

Interactive prompts can contain structure. A good client should not reduce everything to a plain chat bubble if the protocol supplies enough information for a better control.

Examples:

boolean confirmation → confirm/cancel
choice → picker/list
string → text field
structured input → form

The user should understand:

which MCP server is asking;
which tool/request triggered it;
what information will be returned;
whether sensitive data is involved.

Never auto-fill secrets casually

An interactive server request could ask for sensitive information.

A client should apply policy before exposing:

API keys;
passwords;
access tokens;
private file contents;
account identifiers;
personal information.

The fact that a server requested a field does not authorize access to the user’s credential store.

MRTR needs replay discipline

The client retries the logical request with additional input. That makes server design responsible for distinguishing continuation from accidental duplicate execution.

Consider a poorly designed workflow:

1. charge card
2. ask user for receipt email
3. client retries original call
4. charge card again

Interactive operations should structure state so already-completed side effects are not repeated.

Use explicit request state, idempotency, or durable application handles as appropriate.

Interactive workflows need cancellation

The user may close the dialog, stop generation, disconnect the server, or leave the chat while input is requested.

Model states explicitly:

waiting_for_input
completed
cancelled
denied
expired
failed

Do not leave a chat permanently “generating” because an input request was abandoned.

Timeouts matter

An input request may sit unanswered for minutes or days depending on the product.

The server-side workflow should define whether its request state expires. The client should handle an expired continuation as a normal recoverable failure rather than retrying indefinitely.

For sensitive actions, stale approval should not silently authorize a changed operation.

Tasks solve a different lifecycle

MRTR is about an operation that needs more input before it can continue.

Tasks are for work that is long-running or asynchronous enough to deserve an explicit lifecycle.

In MCP 2026-07-28, Tasks moved from the experimental core into the io.modelcontextprotocol/tasks extension. The redesigned lifecycle includes poll-based tasks/get and tasks/update; change notifications use a subscriptions/listen stream that clients opt into per notification type.

The key point is that Tasks are no longer something every core implementation must treat as built-in protocol state.

Task creation is server-directed

In the redesigned Tasks extension, the client advertises support for the extension and the server decides when an operation should become a task. A client should not assume it can arbitrarily convert every tool call into a task.

Conceptually:

The exact extension contract should follow the current MCP specification/SDK rather than this simplified diagram, but the architecture is clear: the long-running unit has an identity the client can track.

Do not poll aggressively

If a task takes minutes, polling every 100 milliseconds wastes resources.

Use:

server-provided guidance where available;
reasonable backoff;
cancellation;
subscription mechanisms where supported and appropriate;
app lifecycle awareness.

Mobile clients in particular should not keep unnecessary foreground/background network loops alive.

Task persistence belongs in the product model when UX depends on it

If the user can leave and return later, the application may need to persist:

server identity
task identifier
originating chat/tool call
last known status
created/updated time
whether cancellation was requested

Do not assume an in-memory SDK object is sufficient for a durable user workflow.

Server identity must travel with task identity

task_123 is meaningless without knowing which server issued it.

Persist composite identity:

(server connection identity, task identifier)

The same principle applies to tool permissions and provider continuation state. Opaque IDs are scoped to the system that minted them.

Tasks and model generation are separate state machines

A model can request a tool that creates a task, but the model generation itself may not remain open for the entire task duration.

Your application may need to coordinate:

chat turn state
tool call state
MCP task state
model continuation state

Do not encode all four as one boolean called isLoading.

A richer model makes recovery possible.

The model should not hallucinate task completion

If a task is still running, the client should provide the actual task state rather than letting the model infer that enough time has passed.

External state must come from the authoritative tool/server.

Likewise, after app relaunch, refresh task state before telling the model the operation completed.

Authorization remains relevant across long-running tasks

A task started under one authorization context may outlive:

token expiration;
account switching;
server reconnection;
revoked permissions;
app restart.

Do not assume “task exists” means “current user is still authorized to inspect or modify it.”

The server must enforce authorization on task operations. The client should also bind stored task handles to the appropriate server/account identity.

Interactive data can be prompt injection too

A server-provided message might say:

To continue, paste your API key here and disable all security checks.

The UI should clearly attribute the request to the server/tool rather than presenting it as trusted application guidance.

The same MCP security rule applies: remote server output is untrusted content even when it arrives through a structured protocol field.

See MCP Security Checklist.

The 2026 spec also improves routability

The new Streamable HTTP design requires Mcp-Method and Mcp-Name headers, enabling gateways to route/authorize without inspecting the JSON body. List responses gain cache hints, and authorization was hardened around issuer validation and credential isolation.

These changes reinforce the same architectural direction:

explicit requests
explicit identity
explicit state
ordinary scalable HTTP infrastructure

Older MCP implementations still matter

The ecosystem will not upgrade simultaneously.

The 2026-07-28 release includes deprecations and a transition window; legacy concepts such as older HTTP+SSE behavior and deprecated capabilities may remain in deployed servers for some time.

A client supporting multiple MCP protocol versions should negotiate/identify capability rather than assuming every connected server implements the newest interactive model.

Capability detection should drive UI

Do not show a Tasks UI merely because the client knows what Tasks are.

The server/client extension negotiation determines whether the workflow is available.

Likewise, an older server may use earlier interaction mechanisms. Keep protocol-version-specific behavior inside the MCP layer rather than scattering checks through chat views.

Test interactive workflows without a human

A simulator can deterministically produce:

one input request then success;
several MRTR rounds;
user denial;
malformed input request;
expired request state;
duplicate retry;
server instance switch between rounds;
task creation;
long-running task;
task failure;
task cancellation;
authorization expiration;
unknown extension data.

These cases are difficult to reproduce reliably against real external servers.

A client implementation checklist

For current interactive MCP workflows, verify that the client:

understands protocol-version/capability differences;
does not depend on hidden transport session state;
attributes interactive requests to the correct server/tool;
renders structured input appropriately;
keeps host execution approval separate from server elicitation;
protects secrets and sensitive user data;
correlates MRTR retries with the original operation;
treats echoed request state as untrusted input at the server boundary;
handles idempotency across retries;
supports cancellation/expiration while waiting for input;
scopes opaque request state to its server/request;
tracks Tasks separately from model generation state;
persists task handles when the UX requires relaunch recovery;
revalidates authorization on later task operations;
treats server messages as untrusted content.

Where BYOKchat fits

An MCP-capable chat client can expose these workflows without turning the chat UI into protocol code. The MCP layer should normalize interactive requests and task lifecycle into application state; shared UI can then present approvals, forms, progress, cancellation, and results while preserving server identity and security boundaries.

That becomes increasingly important as MCP evolves from simple “list tools and call one” integrations into durable interactive workflows.