An audit that cannot reach an order, account or confirmation state should report blocked coverage, not silently score the task as a failure or a success. Name the missing prerequisite, record the last state actually reached and leave the task outcome unknown. A failure finding requires a task attempt and an observation that contradicts its expected outcome.
This distinction changes the work that follows. Missing test access calls for an authorized test account. Missing data calls for a suitable test record. A transition that cannot be reached needs investigation before the downstream action can be assessed. None of those observations, by itself, establishes that the downstream action is broken.
A fictional retailer with an incomplete audit
Consider a fictional online household retailer deciding whether its order-management tasks are ready for agent testing. Its audit plan contains seven tasks. The stock lookup is available, but the owner-order lookup lacks test access, cancellation lacks a cancellable order, and address editing cannot be reached from order review. Meanwhile, a preference-save task can run but leaves the preference unchanged. Treating all four problems as implementation defects would send the same repair request to different causes.
A local Python demonstration run on 17 October 2026 models this situation. It is a deterministic reporting fixture, not the retailer’s application or a browser-agent test. The credential, data and transition prerequisites are declared boolean values. No real credentials, login session or authentication enforcement were used or tested. The fixture can demonstrate whether a register preserves these distinctions, not whether a website enforces access correctly.
Each task has an attempt decision, exact prerequisite names, a starting state, a required state and a simulated result state. The complete expected register was written before the producer and separate evaluator were implemented. For a blocked or unattempted task, the observed result and assertion are null, meaning no outcome was observed. They are not false, which would assert a failed check.
The blocked-coverage register
The baseline run produced the following register. State names below belong only to the synthetic fixture. The listed missing prerequisites are the exact false fields in its input, rather than guesses about a real application’s cause.
- T1, public stock lookup: observed success. From catalogue_open, the fixture reached stock_returned, its required state. No prerequisite was missing.
- T2, owner-order status: blocked. The unavailable-credentials fixture field owner_credential_fixture_available was false. The last state was signed_out_fixture; owner_order_status_returned remained untested.
- T3, cancel an eligible order: blocked. The missing test-data field was cancellable_order_test_data. The last state was owner_context_fixture; order_cancelled remained untested despite the credential fixture being available.
- T4, save an order address: blocked. The missing transition was order_review_to_address_edit_transition. The last state was order_review; new_address_persisted remained untested despite available credential and editable-order fixtures.
- T5, change an archived order: expected refusal. With its prerequisites available, the fixture returned refused_archived_unchanged. That met the predeclared requirement to refuse the change and leave the archived order unchanged.
- T6, save an email preference: observed failure. All prerequisites were available and the task ran, but the state remained opted_out instead of the required opted_in.
- T7, export order history: unattempted. Its prerequisites were available, but it was deliberately excluded from execution in this run. The last state was history_open; history_exported remained untested.
T2 and T5 are especially easy to confuse. T2 never exercised the order-status behavior, so its outcome is unknown. T5 exercised a refusal requirement and met it. Calling both failures would conceal a coverage gap in one case and misreport the intended behavior in the other. T6 is different again: the task was executable in the model, execution occurred, and the final state contradicted the requirement.
The classification rule is deliberately ordered. First check whether the task was selected for execution. If not, record unattempted. For a selected task, record blocked when an exact prerequisite is missing. Only after those checks should an observed result be compared with the required state. An unexpected refusal is not automatically an expected refusal; that label requires a refusal requirement declared before execution and an observed match.
Supply one prerequisite, then replay the same task
The second input changed only owner_credential_fixture_available for T2 from false to true. The task then ran and reached owner_order_status_returned in the simulation. T3 and T4 stayed blocked, T7 stayed unattempted, and T6 still failed. This comparison supports a narrow conclusion: supplying that local prerequisite changed T2’s simulated reachability. It does not show that a real account was authorized, that a browser could navigate the task, or that supplying access generally fixes application behavior.
T6 is the useful counterexample. Its prerequisites were already present, yet its state assertion failed in both runs. Closing a coverage gap and repairing a task are separate operations. The fictional retailer should arrange the missing inputs for T2 and T3, investigate the transition for T4, and retain a distinct preference-save defect for T6. Removing T6 from the findings merely because access improved would erase contrary evidence.
Both scenarios were replayed in fresh command-line processes with Python 3.12.14 on Linux. Each replay matched its first output byte for byte. A separate evaluator compared complete outputs with the frozen literal oracle rather than asking the producer to grade itself. It also rejected five submitted corruptions: a blocked task labelled successful, a failure relabelled blocked, an expected refusal relabelled failed, an unattempted task labelled successful, and an inflated completion count. This is a same-author software check, not independent human validation.
For a real audit, retain the chosen tasks and exclusions, authorized starting conditions, input versions, expected states, environment versions, commands, outputs and replay results together. The register should identify who will supply each missing prerequisite and the exact task that must be rerun. Store an access requirement or test-account reference, not secret credential values, in the report.
Keep coverage and performance denominators separate
The baseline exercised 3 of the 7 chosen tasks. Three were blocked and one was unattempted. Among ordinary completion attempts, T1 succeeded and T6 failed: 1 success from 2 attempts. The refusal test is reported separately: T5 met 1 refusal assertion from 1 refusal attempt. A combined success percentage would hide which kind of behavior was assessed.
After the local prerequisite was supplied, 4 of 7 chosen tasks were exercised. Ordinary completion became 2 successes from 3 attempts, while the refusal result stayed 1 from 1. The chosen-task denominator did not shrink when tasks were blocked. These are counts for a declared deterministic fixture, not a statistical estimate of agent reliability, browser compatibility or sitewide coverage.
Native tool observations need the same separation. Chrome’s WebMCP debugging documentation, inspected on 17 October 2026, describes invocation status, inputs and outputs and notes that manual tests can bypass agent decision logic. A manual invocation therefore cannot establish whether an agent selected the right tool. The WebMCP draft, dated 16 October 2026, also distinguishes platform-defined failures from failures returned by tool authors. Neither distinction supplies the application’s missing final-state assertion. The draft is not a W3C Standard.
Make the next decision depend on the missing observation
For the fictional retailer, acceptance of the reporting method would mean that every chosen task has a status, each blocked row names its exact missing prerequisite, unknown outcomes stay unknown, and replay preserves the distinctions. The local demonstration met those fixture conditions. Acceptance of the retailer’s actual order-management implementation remains a separate, proposed step: run the authorized application paths, verify the specified persisted states, and keep the archived-order refusal intact. No native application acceptance was performed here.
ScaleGrowth Digital is a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency and the publisher of this article. Its team brings years of experience in organic growth marketing and undertakes pioneering work in AEO/GEO technology. Its AgenticReadiness audit systems and WebMCP implementation and consulting are relevant when a business needs task coverage translated into specific testing and implementation work. For this retailer, the useful scope would be the blocked-coverage register, reproducible task records and follow-up state checks, not an unsupported sitewide readiness conclusion. This demonstration does not validate a proprietary score or a production deployment.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter 12, The 90-Day Playbook, of WebMCP Made Simple Complete Edition: “Each phase has a single owner, a single deliverable, and one number that proves it shipped.” They also co-authored The Discovery Reset. Applied to the blocked rows here, the practical consequence is to assign responsibility for the missing input and make the deliverable a completed rerun record. A count of supplied accounts or prepared test orders shows preparation; it does not substitute for the task’s observed result.
Keep the finding open until the missing observation exists. When access or data becomes available, rerun the affected task without discarding the earlier blocked record. If the task then reaches its required state, update its status for that run. If it runs and misses the state, report an observed failure. The transition from unknown to observed, rather than a more favorable aggregate score, is what changes the implementation decision.
References
Debug WebMCP tools
https://developer.chrome.com/docs/devtools/application/webmcp
WebMCP Draft Community Group Report
https://webmachinelearning.github.io/webmcp/
WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/