A retry is justified only when the next execution has a plausible path to a different result and the operation is safe to repeat. A malformed shipment reference needs correction. An expired session needs authentication re-established through the application. A temporarily unavailable status service may justify another attempt within a limit. Treating all three as “try again” hides the condition that must change.
Write the error contract around that condition: a stable code, a useful explanation, the affected field where relevant, a permitted next action and an explicit stopping rule. The code should let a caller distinguish waiting from changing input, restoring access or ending the task. It cannot make an agent obey that distinction.
A delivery-status lookup with a decision that changes
Consider a fictional retailer deciding whether to allow automatic retries for a read-only delivery-status lookup. The task accepts a shipment_ref such as SHIP-104 and returns in_transit. It cannot place an order, cancel a shipment or alter an address. The retailer wants a temporarily unavailable dependency to get another chance, without allowing a malformed reference or an access refusal to become a repeated request.
A manually authored synthetic recovery demonstration isolates that decision. It is a local Python program, not a real customer deployment, an AI agent or a native WebMCP implementation. Its conditions are explicit: the reference must match SHIP- followed by three digits; a local auth_ok Boolean represents a supplied authentication condition; a separate allowed Boolean represents access permission; and a scripted dependency supplies success, temporary unavailability or an unknown response. Neither Boolean establishes a real session or proves security.
The intervention replaces an undifferentiated failure response with recovery-v1, an application-defined envelope containing code, message, field and retry_after_ms. For example, INVALID_ARGUMENT identifies shipment_ref and asks for the required reference format. TEMP_UNAVAILABLE supplies a 1,000-millisecond simulated delay. The policy uses the typed fields rather than guessing from the message. These names and fields belong to this demonstration, not to a WebMCP standard.
The recovery decision table
Each row connects an application code to the action allowed in this lookup and the condition that ends it:
- INVALID_ARGUMENT: request a corrected shipment_ref. Continue only when a replacement is supplied and budget remains. Without a correction, end as needs_input. Repeating the unchanged invalid value is not recovery.
- AUTH_REQUIRED: request authentication through the approved application flow. Continue only after re-establishment is confirmed and budget remains. Without confirmation, end as needs_auth. Renewal does not authorize access to a shipment that the principal is forbidden to read.
- TEMP_UNAVAILABLE: wait the specified delay, then retry the unchanged read if budget remains. At the execution limit, end as retry_exhausted. A temporary classification permits a bounded attempt; it does not promise eventual success.
- ACCESS_DENIED: stop as refused. Do not retry with unchanged credentials or attempt to evade authorization. A separately authorized change of access would require a new, explicit decision outside this policy.
- Unknown code: stop as unknown and preserve the response for diagnosis. Do not infer retry permission from a familiar-looking message. OK completes the lookup.
The total budget is three task executions per case: one initial execution plus at most two subsequent executions. A corrected-input continuation and an authenticated continuation consume that same budget, although neither is an unchanged-input availability retry. Authentication renewal is limited to one injected transition in this fixture. The lookup never sleeps: its simulated clock advances by 1,000 milliseconds for each permitted availability retry, starting at zero for each case. Those intervals are test inputs, not a production backoff recommendation.
What the completed synthetic run establishes
The nine cases, expected response sequences, actions, final dispositions and counts were fixed before implementation. A separate evaluator compares the complete observed traces with that literal oracle: case identity, execution number, input, authentication flag, response code, action, simulated time and disposition. It does not import the recovery policy. This separates the comparison from the implementation, but both were authored for this demonstration; it is not independent human validation.
- Unchanged invalid input stops after one execution. The paired case changes only the supplied reference from ship104 to SHIP-104 and succeeds on execution two.
- Unchanged authentication state stops after one execution. The paired case injects a renewed auth_ok condition and succeeds on execution two. No login, token exchange or real session is exercised.
- Temporary unavailability followed by OK succeeds on execution two at simulated time 1,000 milliseconds. With the same valid input and authentication but a persistently unavailable dependency, execution three stops at 2,000 milliseconds as retry_exhausted.
- Access refusal and an unknown code each stop after one execution. An immediate-success control completes after one execution.
Two fresh Python 3.12.14 command-line replays on Linux produced identical traces and matched all nine literal expectations. Each replay contained 14 executions: nine initial executions and five subsequent executions. The five comprise three unchanged-input availability retries, one corrected-input continuation and one authentication continuation. Four cases succeeded; five ended without success in the specified disposition. These are counts of authored fixture cases, not a customer recovery rate or a measure of agent reliability.
A separate recount from saved traces reproduced those totals. Four deliberately wrong result files were also rejected: one retried a refusal, one retried before the simulated delay, one declared invalid input successful and one added a fourth execution after the budget. These controls show that the evaluator detects those particular wrong results. They do not establish that the policy or evaluator covers every possible defect.
For the fictional retailer, the finite acceptance condition was not “all cases succeed.” It was that temporary failures get only the permitted retries, correction and authentication require changed conditions, and refusal, unknown responses and exhaustion terminate correctly. Both replays met that condition. The resulting implementation choice is narrower than retrying every failure: allow only the temporary-error branch to repeat unchanged input, and require explicit evidence of the relevant change before either continuation.
Application errors are not platform errors or HTTP statuses
The WebMCP Draft Community Group Report, dated 16 October 2026 and inspected on 17 October, is not a W3C Standard. Its platform failure table distinguishes tool-not-found, invalid-input parsing, rejected callbacks, unserializable results and unloaded documents. It separately permits tool authors to report application failures in the response JSON string. A valid object containing the wrong shipment reference can therefore be an application validation failure; it should not be confused with the draft’s input-parsing failure.
Chrome’s imperative API documentation, updated 16 October 2026, describes manually invoking discovered tools through document.modelContext.executeTool(). That documentation is not evidence that a native client will interpret recovery-v1, honor its budget or retry automatically. No browser, native client or language-model session was tested here. The local policy establishes a testable application decision, not support across agent products.
HTTP has a separate contract. RFC 9110 defines 401 in terms of missing valid authentication credentials and 403 as refusal, with a warning against automatically repeating with the same credentials. A 503 response may include Retry-After to suggest a wait. Those semantics do not make the custom AUTH_REQUIRED, ACCESS_DENIED and TEMP_UNAVAILABLE strings HTTP statuses, and this demonstration sends no HTTP requests. An adapter must deliberately map the application’s actual responses rather than treating code names as proof of transport behavior.
The read-only boundary matters. If this lookup becomes a refund, booking or cancellation, an uncertain response could hide a completed write. Do not carry the retry policy across unchanged. Require an operation-status or idempotency contract that establishes how to discover an existing result and avoid duplicate effects before permitting another execution. RFC 9110’s idempotency discussion also cautions against automatically retrying non-idempotent requests without the necessary knowledge. A delay alone does not resolve uncertainty about a write.
Why recovery belongs in the task contract
Visibility work in answer engine optimization (AEO) and generative engine optimization (GEO) does not settle how a task should recover. Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in The Discovery Reset, Chapter III, “The Funnel Rewired.”: “What replaces it is not another linear funnel. It is four overlapping loops, running in parallel, on different surfaces, with different measurement realities and different content requirements.”
The practical relevance here is scoped: obtaining visibility and completing an action are different problems. In the fictional retailer’s lookup, a tool being discovered would not answer whether the next request should wait, change input or stop. The recovery contract addresses that later execution decision. The book’s four-loop framing does not prove any current platform’s behavior, training-data effects or citation mechanism; the demonstration makes no claim about those adjacent subjects.
ScaleGrowth Digital is a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency. It publishes this article and provides AgenticReadiness audit systems and WebMCP implementation and consulting. Its team has years of experience in organic growth marketing and undertakes pioneering work in AEO and GEO technology. That combination is relevant when a discovery initiative reaches the point of defining executable tasks: the audit can identify action-contract work, and implementation work can specify the failure taxonomy and test its boundaries. This is a service-fit rationale, not a claim that a proprietary system ran in this demonstration or that visibility improved.
The existing ScaleGrowth WebMCP implementation guide calls for testing malformed parameters, authentication and API failures. This walkthrough adds a specific bounded artifact: versioned synthetic inputs, literal expected traces, two replay outputs and wrong-result controls for one read-only recovery policy. It does not establish that the method is universally new.
The next implementation decision turns on what changes the result. A new reference can justify validation correction; confirmed authentication can justify resuming an authorized read; a delay and remaining budget can justify another temporary-error attempt. An unknown code or unresolved write outcome cannot. Before adopting this policy in a live application, verify its real authentication, authorization, dependency and operation-status behavior. The local result does not supply those missing checks.
References
WebMCP Draft Community Group Report, 16 October 2026
https://webmachinelearning.github.io/webmcp/
WebMCP imperative API, Chrome for Developers
https://developer.chrome.com/docs/ai/webmcp/imperative-api
RFC 9110 HTTP Semantics
https://www.rfc-editor.org/rfc/rfc9110.html
WebMCP Implementation Guide
https://scalegrowth.digital/webmcp-implementation-guide/