What breaks in MCP clients when long-running or interactive tasks still assume a server callback model?

Clients that expect the server to call back can lose state when a user pause, approval, or payment step interrupts execution. The new model requires durable handling of input_required results, opaque requestState, and task handles that survive restarts. If the client cannot persist and replay those handoffs, interactive workflows fail mid-flight and resumability collapses.

Why server callbacks break the new MCP interaction model

MCP clients that still expect the server to “call back later” are built around a synchronous completion fantasy. In practice, long-running work can pause for a user decision, an approval gate, or a payment step, and the client has to keep the workflow alive across that pause instead of waiting for a server-initiated resume.

The core change is that the client now owns continuity. It must treat input_required as a durable state transition, not an exceptional message, and it must preserve the opaque request state and task handle so the interaction can continue after interruption, restart, or handoff.

That shifts the design from callback reliance to resumable orchestration. The important question is no longer “did the server eventually respond?” It is “can the client still reconstruct the in-flight task and reattach the right user context when the next step becomes available?”

What state the client must preserve to survive interruption

The minimum requirement is durable task state, not transient UI state. A client needs to keep enough information to match the resumed interaction to the original request without trying to interpret or rewrite server-owned state. That usually means persisting the task handle, the opaque requestState value, and whatever local workflow context is needed to route the user back into the same operation.

Resumption also has to be idempotent from the client side. If the process restarts, the client should be able to replay the handoff without creating a duplicate task, losing the pending approval, or forcing the user to start over. This is especially important when the interrupting event is external to the MCP session, such as a payment flow or an approval workflow.

For practitioners, the practical failure mode is not just “lost response.” It is broken continuity: the client cannot prove which task the user was approving, cannot restore the pending step, or cannot reconcile a resumed callback with the original request lineage.

How to tell when resumability is broken in practice

When clients are callback-shaped but the protocol expects durable handoff handling, the symptoms are predictable. Users see stalled tasks after approval, duplicate submissions after refresh, orphaned workflows after restart, or lost progress when a foreground session expires before the next step completes.

A related failure is state confusion. The client may receive a valid continuation signal but no longer know which local conversation, workspace, or job it belongs to. That is why the request handle matters: without a stable reference, the client cannot safely rebind the resumed work to the original intent.

These failures are operational, but they also become security-relevant when the client starts guessing. A brittle retry can replay the wrong task, associate a human approval with the wrong request, or leave an interactive action in a partially completed state that is hard to audit.

Risk and Threat Considerations

Interrupted MCP workflows create exposure when the client cannot persist handoffs cleanly. The result is not only failed automation, but also the possibility of duplicated actions, incorrect approvals, orphaned tasks, and stale execution paths that are difficult to observe or control.

Failure mechanism: The client treats a resumable interaction like a one-shot callback, so a restart, pause, or user decision breaks the linkage between the original task and the continuation state.

Impact: Long-running work can fail mid-flight, approval chains can be misbound, and resumability can collapse into manual recovery or unsafe replay behavior.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Interactive MCP handoffs can be misbound or replayed if task state is not durable.
Recommendation — Bind resumable MCP actions to durable task state and revalidate the active user context before continuing.
NIST SP 800-53 Rev 5	AU-12 — Audit Record Generation	Resumed tasks need correlation so interrupted workflows can be traced across restarts.
Recommendation — Generate durable audit records for task handoffs and resumption events.
ISO/IEC 27001:2022	A.5.15 — Access control	Continuation logic must preserve the right request-to-user binding across interrupted sessions.
Recommendation — Enforce access checks before allowing a resumed MCP task to continue.
NIST CSF 2.0	RC.RP-1 — Recovery plan is executed during or after an event	Client resumability is a recovery capability for interrupted long-running workflows.
Recommendation — Test recovery paths that restore interrupted client workflows without losing task state.
OWASP API Security Top 10	API1 — Broken Object Level Authorization	A resumed task must still map to the correct object or request, not a stale or wrong one.
Recommendation — Verify resumed requests still resolve to the original object before completing the task.

Practitioner Guidance

What to verify: Confirm that the client can persist and restore the exact handoff state it needs, including task identity, pending status, and any locally stored correlation needed to resume after process loss. If a restart destroys the workflow, the client is not actually resumable.

Decision rule: If the next step depends on user interaction, design for durable continuation first and callback convenience second. Treat any implementation that cannot replay the handoff as a non-resumable flow, even if it works in a single-session demo.

Common mistake: Teams often persist only visible UI state and forget the protocol state that actually binds the resumed interaction to the original task. That is the difference between a recoverable pause and a broken workflow.

Practitioner takeaway: MCP clients should be built to survive interruption, not merely to receive responses, because resumability depends on durable task continuity rather than a server-side callback assumption.