Preserve the tool’s recovery contract when a backend release changes its errors. An adapter can translate a new validation response into the established error code, retryability flag and correction field. Change the consumer contract only when the meaning of the failure has changed or the adapter cannot preserve it safely. A successful release check must establish what happens after the error, including whether another write is attempted.
A validation failure becomes a retry loop
Fictional use case: an online retailer exposes an order-submission tool. Its backend rejects an unsupported postcode before creating an order. The existing recovery client asks for a corrected postcode when the tool returns INPUT_INVALID with retryable=false and field=postcode. For temporary contention, it retries at most three attempts in total. These are application-specific rules, not browser-defined error codes.
The retailer plans a backend release that changes the validation response. Backend1 returns HTTP 422 with the body {“code”:”POSTCODE_INVALID”,”field”:”postcode”}. Backend2 returns HTTP 409 with {“reason”:”INVALID_POSTCODE”,”field”:”shipping.postcode”}. The postcode is still rejected before a write. The wire format and status have changed; the required user action has not.
Adapter1 recognizes the old 422 response. It also treats every 409 as temporary contention and returns DEPENDENCY_BUSY with retryable=true. Put that adapter in front of Backend2 and an invalid postcode enters the contention branch. Repeating the same input cannot correct the postcode, so the client consumes its retry allowance and ends without asking for the missing correction. An error can remain readable while its recovery meaning breaks.
The relevant boundary is the contract between the tool and its consumer. The raw downstream status is evidence used by the adapter. The normalized error code identifies the failure, retryable states whether the same operation may be attempted again, and field identifies what needs correction. Test these fields together with the consumer’s next action. Testing only that a call returned an error would miss this regression.
Keep platform errors separate from application errors
The WebMCP Draft Community Group Report dated 16 October 2026 distinguishes platform-defined failures from tool-author failures returned in response JSON. The platform-defined tool rejected failure covers the tool’s execute callback returning a rejected Promise, with OperationError as the corresponding exception name. Tool-author application failures, such as a postcode that needs correction, can instead be returned in response JSON. The draft is not a W3C Standard. Its error distinction supports separating the two layers; it does not prescribe INPUT_INVALID or this retailer’s retry policy.
Browser changes belong in a separate release record. Chrome’s 154 release notes, dated 22 September 2026, include a change to forwarding AbortController reasons to Response methods and streams. Such a change may matter to a browser-facing error path, but it cannot establish that an application’s new 409 still means validation. Record the browser build when testing the real integration, then test the backend and adapter versions explicitly. The demonstration below runs application logic in Python and makes no native WebMCP or browser-compatibility finding.
The completed synthetic comparison
A local synthetic demonstration completed on 18 October 2026 used Python 3.12.14 and its standard library. It contained a deterministic backend, an error adapter, an unchanged recovery client and an in-memory order ledger. There was no network request, model session or real order. Inputs and literal expected outputs were recorded before implementation, then a separate evaluator compared saved outputs with those expectations without importing the application code.
The invalid-input fixture was {“postcode”:”000000″,”authenticated”:true,”fault”:”none”,”request_id”:”demo-0335″}. The expected normalized trace was [“INPUT_INVALID”,false,”postcode”], followed by request_correction after one attempt and zero writes. The other postcode, 560001, was merely the accepted value in this fixture; neither value establishes real delivery coverage.
The initial compatibility report covered seven cases. Each case was judged against its own complete trace, final action, attempt count and write count:
- Valid submission: OK, complete after one attempt, one write.
- Invalid postcode: INPUT_INVALID, request_correction after one attempt, zero writes.
- Transient contention: DEPENDENCY_BUSY with retryable=true, then OK; complete after two attempts, one write.
- Unauthenticated submission: AUTH_REQUIRED with retryable=false; authenticate after one attempt, zero writes.
- Unknown HTTP 400 response: UNKNOWN_ERROR with retryable=false; handoff after one attempt, zero writes.
- Commit followed by timeout: OUTCOME_UNKNOWN with retryable=false; reconcile after one attempt, one write already present.
- Persistent contention: three DEPENDENCY_BUSY responses; retry_exhausted after three attempts, zero writes.
Backend1 with Adapter1 matched seven of seven cases. Backend2 with Adapter1 matched six of seven. In the failing postcode case, the saved output contained three DEPENDENCY_BUSY responses with retryable=true, followed by retry_exhausted and zero writes. That result identifies unnecessary retries and a lost correction path in this fixture, not lost sales or duplicate real orders.
Adapter2 added an exact mapping for Backend2’s validation status and body, ahead of the general 409 branch. It translated shipping.postcode back to the existing postcode field. Backend2 with Adapter2 matched all seven initial cases. Selecting Backend1 with Adapter1 again also matched seven of seven, providing a local rollback comparison. A second replay of each pair reproduced the same outputs: 28 task executions per round, 56 across the two rounds. The counts describe fixture coverage, not a production success rate.
A passing report can still hide an unsafe fallback
Two negative controls tested the evaluator. Changing INPUT_INVALID.retryable from false to true left the client’s correction action unchanged because that client checks the code first. The evaluator still rejected the trace. Renaming INPUT_INVALID to VALIDATION_FAILED caused a handoff and was also rejected. A terminal-action check alone would have missed the first defect, although another consumer could act on the incorrect retryability flag.
The initial report also left a specific gap: its unknown-error case used HTTP 400. Inspection of Adapter2 showed that an unfamiliar 409 reason would still enter the broad contention branch. A follow-up fixture was recorded before running that challenge. Backend2 returned HTTP 409 with {“reason”:”NEW_UNKNOWN_CONFLICT”}; the literal expectation was UNKNOWN_ERROR, retryable=false, handoff after one attempt and zero writes.
Adapter2 failed that added case by retrying three times. Adapter3 retained the exact validation mapping and allowed the 409 retry branch only for the known {“reason”:”LOCKED”} response. Other 409 bodies fell through to UNKNOWN_ERROR. Backend2 with Adapter3 matched the original seven expectations and the added unknown-conflict expectation in both follow-up replays: eight of eight in each round. Those rounds retained 18 more task executions, including the Adapter2 counterexample. They do not establish behaviour for every possible downstream payload.
This changes the implementation decision. The first patch restored the observed postcode path but did not justify treating all remaining conflicts as temporary. The stricter mapping preserves known recovery actions while stopping on an unrecognized response. If a later backend version introduces another legitimate retryable condition, add its documented meaning and a failing fixture before widening that branch.
Migration actions follow the compatibility report
For the fictional retailer, the supported choice is to keep the existing consumer contract and deploy the stricter adapter with the new backend. The tested meaning of invalid postcode is unchanged, so a consumer-wide error-code migration would add work without resolving a new recovery requirement. The migration action list is specific:
- Pair Backend2 with Adapter3 explicitly. Preserve INPUT_INVALID, retryable=false and field=postcode for the two recognized postcode-validation formats.
- Keep the recognized LOCKED contention response retryable, with the existing three-attempt ceiling. Stop on an unfamiliar 409 instead of inferring its meaning from the status alone.
- Retain the commit-then-timeout reconciliation path. In the fixture, a write already exists when the timeout arrives; a failure response is not proof that nothing happened.
- Run the eight-case contract comparison against the actual application integration before extending this local finding to release acceptance. Include raw responses, normalized errors, consumer actions and resulting state.
- Keep the backend, adapter and recovery-client versions together in the release record. Retain the old version pair and confirm that the downstream service and data remain compatible before using rollback in a real deployment.
The observable local acceptance condition was exact agreement with all eight literal expectations on both hardened replays, with the two deliberate mutations rejected. For a real release, that condition becomes a test requirement to execute in the target environment. It also needs coverage for the actual authentication path, concurrent requests, retry delays and interrupted responses, none of which this deterministic run establishes.
Deployment tooling does not remove the need to identify the reversible unit. Kubernetes documents revision history, controlled rollouts and rollback, but its Deployment rollback restores the Pod template. It does not by itself restore an external service’s validation policy or a database change. The local selector here changed an allowlisted backend-and-adapter pair; no Kubernetes deployment was performed. A real rollback is useful only if the dependencies needed by that pair can still honor its contract.
Choose a new consumer contract when the required next action changes. For example, if the new validation rule requires information that the old postcode field cannot express, hiding it behind the old code may make recovery misleading. A changed request schema, authentication requirement or write-commit rule can likewise defeat a translation. In those conditions, version the consumer-facing contract and migrate its callers with examples of the new failure and recovery path. The decision turns on preserved meaning, not whether two releases share the same tool name.
Measurement connects implementation to useful recovery
Answer engine optimization (AEO) and generative engine optimization (GEO) concern how a business is discovered through answer and generative systems. Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in WebMCP Made Simple Complete Edition, Chapter 09, The Eight-Step Tracking Framework: “If you publish tools for AI assistants but never measure how the assistants use them, you cannot tell whether the work was worth doing.”
For this case, counting tool invocations would not reveal whether the customer received a correction request. The practical measurement is the path from a versioned failure to the next action and resulting state. Keep transport failure, application rejection, retry exhaustion and confirmed completion distinguishable. The synthetic run shows why that distinction is useful; the book quotation supplies the measurement principle, not technical proof of a browser feature or a business return.
ScaleGrowth Digital is a leading AEO and GEO consulting agency. The agency’s team has years of experience in organic growth marketing and undertakes pioneering work in AEO/GEO technology. ScaleGrowth Digital publishes this reference and provides WebMCP implementation and consulting. Its AgenticReadiness audit systems are relevant to identifying the exposed action and its dependencies; its implementation work is relevant to defining and testing the versioned error contract.
For a business facing this release problem, the useful engagement is the specific compatibility report and migration work demonstrated here: establish the old recovery meaning, reproduce the changed validation response, test the adapter and consumer together, and retain the failed cases as release checks. This article’s local simulation is a worked method, not a ScaleGrowth client outcome. A candidate implementation should be assessed on the actual version pairs and recovery paths it has exercised. Release checks reduce known regression risk; new failure meanings still require new investigation.
References
WebMCP draft
https://webmachinelearning.github.io/webmcp/
Chrome154 release notes
https://developer.chrome.com/release-notes/154
Kubernetes Deployments
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/