An Asynchronous Tool Call Needs a Work Receipt

An agent invokes a tool. The tool accepts the work. Nothing useful is ready yet.

That middle state is where many agent designs become vague. A synchronous mental model has only two useful outcomes: return a value or raise an error. But an asynchronous operation can be accepted, still running, waiting for a decision, cancelled only in intent, completed with a domain failure, or completed with a usable result. Those are not variations of one return value. They are lifecycle facts with different implications for the agent and the user.

The design shift is simple: once external work is accepted, treat it as a task boundary. Record a work receipt. Do not pretend that the final tool result already exists.

Acceptance Precedes Completion

The current MCP Tasks extension development draft makes this distinction explicit. A tool can return a durable task handle and later expose states such as working, input required, completed, cancelled, or failed. The experimental MCP 2025-11-25 Tasks specification also models task state separately from result retrieval, although some of its cancellation and error semantics differ from the newer extension draft.

That distinction prevents four common errors:

1. A receipt is mistaken for a result. An acknowledgement only means the remote system accepted responsibility for work. It does not prove the requested effect occurred or that its output is correct.
2. A model keeps planning from stale assumptions. A tool may be waiting for input, a dependency may have changed, or the task may have failed while the agent still reasons as if it is progressing.
3. A restart loses track of live work. The MCP draft recommends preserving a task identifier so a client can resume status checks after a restart. A transient model turn is not a durable source of truth.
4. A cancellation request is reported as a cancellation outcome. The draft describes cancellation as cooperative and asynchronous: a system can acknowledge the request before the underlying work has reached its observed terminal state. The task may even finish before the cancellation takes effect.

These are operational semantics, not merely interface details. If the agent cannot state what it knows about the work, it cannot make a reliable next decision.

A task identifier can also be access-sensitive. The MCP 2025-11-25 security guidance warns that a party able to obtain or guess a task ID may be able to access task state or results when authorization controls are absent. A receipt should therefore retain the smallest safe reference, bind access to the appropriate authorization context where available, and avoid exposing the identifier in broad logs or user-facing artifacts.

The Tool Work Receipt

The Tool Work Receipt is a proposed minimal record for accepted asynchronous work. It is not a raw transcript, a duplicate of a vendor API response, or a cache of private payloads. It is a durable statement of what the agent is entitled to believe and what it must check next.

• Receipt element: Work reference — Question it answers: Which user objective and agent work unit initiated this operation? — Why it matters: Keeps a future result attached to the correct task rather than an arbitrary later turn.
• Receipt element: Operation purpose — Question it answers: What bounded question, artifact, or effect was requested? — Why it matters: Lets a reviewer distinguish meaningful progress from background activity.
• Receipt element: Accepted-at and status-at — Question it answers: When was work accepted, and when was its state last observed? — Why it matters: Makes freshness visible instead of presenting an old observation as live truth.
• Receipt element: Lifecycle state — Question it answers: Is the work working, input-required, completed, cancelled, or failed? — Why it matters: Tells the agent whether to wait, ask, inspect, or proceed.
• Receipt element: Decision boundary — Question it answers: Is user input, approval, or a changed prerequisite required before progress can continue? — Why it matters: Avoids silently inventing a decision simply because the tool is asynchronous.
• Receipt element: Retrieval and freshness policy — Question it answers: How should status be checked, and when should the receipt expire or be revalidated? — Why it matters: Prevents either busy polling or forgotten, stale work.
• Receipt element: Cancellation posture — Question it answers: Was cancellation requested, acknowledged, observed, unsupported, or unnecessary? — Why it matters: Separates intent from the actual state of the external effect.
• Receipt element: Final outcome and acceptance — Question it answers: What result was returned, what error class exists if any, and what acceptance check remains? — Why it matters: A terminal task state is not automatically a successful business outcome.
• Receipt element: Data boundary — Question it answers: What safe reference or summary may be retained? — Why it matters: Keeps private arguments, credentials, raw results, and sensitive data out of a broad coordination record.

The receipt gives an agent a conservative rule: it may reason from the latest observed state, but it must not claim a final result until it has retrieved and evaluated one.

Model the lifecycle as a decision loop

An asynchronous tool is usually not a request followed by one long wait. It is a bounded loop of observe, decide, and act.

• Observed state: Accepted or working — Safe next decision: Wait according to a stated policy, check status at an appropriate boundary, or continue independent work that does not depend on the result.
• Observed state: Input required — Safe next decision: Surface the exact decision category and options that are safe to present; do not manufacture consent or silently substitute a guess.
• Observed state: Completed with a result — Safe next decision: Retrieve the result, validate it against the task's acceptance condition, then update dependent work.
• Observed state: Completed with a domain error — Safe next decision: Treat the lifecycle as finished but the requested outcome as unresolved; classify whether to recover, narrow scope, or ask.
• Observed state: Cancellation requested — Safe next decision: Confirm whether the terminal state has actually changed. Preserve the possibility that the work completed before cancellation was observed.
• Observed state: Failed, unavailable, or unreachable — Safe next decision: Record the last known state and choose a bounded recovery path rather than replaying the action blindly. An expired task may surface as a retrieval error rather than a formal lifecycle state.

The MCP task materials support both polling and, where available, notifications. The experimental MCP 2025-11-25 Tasks specification cautions that notification delivery should not be the only source of truth; a client can still need to retrieve current state. This is a useful general rule for agent designs: a notification is a prompt to reconcile state, not proof that the agent's local view is complete.

Cancellation has two timestamps

The word “cancelled” often hides two different events:

• Cancellation requested: the client has asked the remote system to stop.
• Cancellation observed: the external work has reached a terminal state that confirms what happened.

Those events can be separated by time, and sometimes by uncertainty. A remote task may complete while a cancellation request is in flight. It may reject the request because the work is already terminal. It may acknowledge an intent before all downstream effects have settled. The MCP Tasks draft treats task cancellation as cooperative, which is a healthy reminder not to overstate a request as a guarantee.

The receipt should therefore record an observed status, not merely a client-side intention. Protocol version matters here: the experimental MCP 2025-11-25 specification requires a valid cancellation request to transition the task to cancelled before the response, while the newer extension development draft makes cancellation cooperative and eventually consistent. A client should follow the semantics it negotiated and avoid presenting either model as universal.

For consequential effects, the completion path should also include an acceptance or reconciliation check appropriate to the task. That check can be high-level: confirm the expected artifact exists, confirm a relevant state changed, or place the outcome in a review queue. It does not require exposing private endpoints, internal traces, or sensitive payloads.

Keep the result separate from the work handle

The task handle is a coordination object. The tool result is an outcome object. Combining the two makes agents prone to an especially subtle mistake: treating a completed lifecycle as a successful answer.

The extension development draft allows a completed task to carry a tool result that can still indicate an error. The experimental MCP 2025-11-25 specification instead places a task-wrapped tool result with isError: true in the failed state. In either model, protocol lifecycle and the calling workflow's acceptance decision remain separate; an agent should keep both visible and follow the negotiated version.

This separation also improves recovery. A later model turn can decide whether to retry, change approach, ask a user, or stop based on the observed result and the task's acceptance condition. It does not need to recreate the original request from a vague “still running” message.

A practical adoption path

1. Identify tool calls that can outlive one model turn, process, or user interaction.
2. Create a receipt only after the work has been durably accepted by the external system.
3. Persist a minimal, access-sensitive work reference and the last observed lifecycle state, not raw tool inputs or secrets.
4. Define how the agent handles each state before making the tool available to a long-running workflow.
5. Add a clear input-required path so the system pauses for a real decision instead of guessing.
6. Record cancellation intent separately from observed terminal state.
7. Require a result and acceptance check before dependent work or user-facing claims assume success.
8. Apply timeouts and bounded recovery policies. The MCP lifecycle guidance is a useful reminder that indefinite waiting is not a lifecycle strategy.

The goal is not to make every tool call bureaucratic. Short, truly synchronous reads can remain simple. The receipt belongs where a result can arrive later, where a user decision can interrupt progress, or where an unobserved external effect would make a claim unsafe.

A Virillio Code Editorial Perspective

Virillio Code Editorial uses this topic to articulate a general lesson: an accepted external operation needs a small, reviewable work receipt before an agent can safely act as if it has a completed result. The Tool Work Receipt is a proposed educational framework, not a description of a shipped or planned Virillio Code capability.

Sources and further reading

• Tasks extension — Model Context Protocol draft — The current draft extension describes durable asynchronous task handles, lifecycle states, result retrieval, cancellation requests, and restart-aware task retrieval.
• Tasks — Model Context Protocol 2025-11-25 — The experimental 2025-11-25 Tasks specification documents task status, polling, optional notifications, synchronous cancellation semantics, task-error handling, authorization-scoped access, and TTL concepts.
• Lifecycle — Model Context Protocol 2025-11-25 — Lifecycle guidance describes timeout expectations that support bounded handling of unresponsive peers.

Editorial disclosure

This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.