Sample tasks in distinct states, not just URLs. Start with page template, workflow complexity and inventory state, then reserve a task execution for every known combination whose outcome could differ. Use random URL selection for a different question, such as estimating a defined population measure under a suitable statistical design. A small random draw is not a substitute for deliberate coverage of a rare, consequential state.
A URL is an address. A task also has a goal, inputs, starting state and expected ending state. Two product pages can share a template yet require different tests when one adds an available item and the other must refuse an unavailable item. Conversely, many URLs may exercise the same behaviour. Counting addresses alone obscures that distinction.
A synthetic catalogue with eight distinct behaviours
Consider a fictional retailer choosing an initial agent-task test sample from a large catalogue. Its immediate decision is whether to spend a limited execution budget on arbitrary addresses or on known behavioural differences. The decision-changing fact is that the catalogue includes a cart whose stock has disappeared since the item was added. That state is rare in the example but changes whether checkout should be allowed.
The worked demonstration uses 100 invented URL-task instances, not the retailer’s real website. Each task starts from a reset, versioned functional state. A stratum is a group treated as behaviourally equivalent for this comparison. The eight strata combine three templates with different workflows and inventory conditions:
- A: 60 product URLs, direct add, in stock. Add one standard item; the cart becomes one and checkout is allowed.
- B: 16 product URLs, direct add, out of stock. Refuse the add; the cart remains empty and checkout is not allowed.
- C: 8 product URLs, choose a blue variant then add, in stock. Add blue; the cart becomes one and checkout is allowed.
- D: 6 product URLs, choose a blue variant then add, out of stock. Refuse the add without silently substituting another variant.
- E: 4 listing URLs, filter for green, matching stock. Return one green candidate without adding it to the cart.
- F: 3 listing URLs, filter for green, empty result. Return no match, not an unrelated item.
- G: 2 cart URLs, revalidate an existing item, in stock. Keep the item and allow checkout.
- H: 1 cart URL, revalidate an existing item, stock lost. Keep the item in the cart but block checkout.
Workflow complexity is declared as a single operation for direct add, filtering or revalidation, and variant selection followed by add for C and D. It is not a measured browser step count. These groups are equivalent by construction only. On a real site, a shared template would be a hypothesis to test, not proof that every URL behaves alike. Account state, consent, region, language, price rules and asynchronous stock changes could split any group. A page with several tasks or changing states would need several task records, even if its URL never changes.
An equal execution budget, with discovery cost kept separate
The protocol fixes eight task executions per method, no retries. The random method draws eight distinct instances uniformly without replacement from the ordered register, using Python random.Random(204).sample. Seed 204 was fixed before the draw; no alternative seeds were tried to select a favourable result. The behaviour-based method selects the first instance from each stratum, A through H.
The execution budgets are equal. The preparation costs are not measured: the behaviour map is supplied by the synthetic setup. A real audit must discover and maintain that map. This comparison therefore asks how the two allocations cover known states once the map exists, not which approach is cheaper end to end.
Coverage means the number of distinct declared strata exercised, out of eight. Correctness is a separate check against the expected outcome. A failed task still covers its stratum and must remain in the register as a failure. Removing it would make a sample look cleaner while hiding the behaviour that needs attention.
What the completed local run showed
The demonstration ran on 17 October 2026 using CPython 3.12.14 and the Python standard library. The population, sampling protocol and functional state were pinned to version 1. Before implementing either the producer or evaluator, the expected output for all 16 selected executions was written as a complete typed literal oracle: the task identity, stratum, status, selected variant, cart quantity, checkout permission and match count, plus the run headers and coverage summaries.
The random register selected A51, A11, B15, A27, A17, A53, B02 and A43. Those eight executions covered A and B: 2 of the 8 known strata. The behaviour register selected A01, B01, C01, D01, E01, F01, G01 and H01. Its eight executions covered all 8 known strata. All selected outputs matched the declared literal expectations in both methods. The random sample left variant selection, both listing states and both cart revalidation states unexercised.
A separate evaluator compared the full output with the oracle, including field types rather than accepting a numeric string as an integer. Seven deliberately incorrect candidate outputs were submitted to it. It rejected checkout allowed after stock loss, an unavailable item added to the cart, a numeric string, a missing task, a duplicate task, a false coverage total and an incorrect state version. A fresh read-only command-line replay produced identical output, and the frozen inputs and code hashes remained unchanged.
Those controls show that the evaluator rejected those specified defects. They do not establish that it would detect every defect, and the separate script is not independent human validation. The run simulated application-state transitions locally. It did not operate a browser, invoke a WebMCP tool, prompt an agent or model, or test a production site.
The result supports a narrow decision: with this known map and this execution budget, allocate one run to each declared behaviour before spending more runs on interchangeable copies. It does not establish statistical superiority over random sampling. Another draw could cover different strata, and neither allocation estimates the failure rate of a real catalogue. Repeating the same seed establishes repeatability, not representativeness.
Keep the sampling protocol and task register together
A reusable protocol records the population boundary, grouping assumptions, budget, selection rule, random seed where used, coverage denominator and expansion conditions. Its task register records the task ID and URL, template, workflow, inventory state, exact input, starting-state version, expected outcome, actual outcome and replay reference. Retain the executable code and environment versions with those records so a later comparison does not silently change the test.
For the fictional retailer, the intervention is to reserve an execution for the stock-lost cart rather than assume a common product page covers it. The observable acceptance condition is specific: the item remains in the cart, checkout is false, and the result matches the frozen expectation on replay. That condition was demonstrated in the local fixture, not achieved on a customer website. Adoption would require mapping and testing the retailer’s actual workflow.
The coverage total must travel with its uncovered-state list. Here the behaviour sample leaves no declared stratum uncovered, but authentication, regional inventory, payment, consent and live timing effects sit outside the map. Add a stratum when any such condition changes the required outcome. If two instances inside one group diverge, split that group and add executions. If the budget is smaller than the number of critical groups, report the uncovered groups explicitly and enlarge the budget or narrow the decision; do not call the remaining sample complete.
Use coverage to scope implementation, not certify agent readiness
WebMCP adds an interface consideration, not an exemption from task sampling. The 16 October 2026 WebMCP draft describes JavaScript tools exposed by web applications and explicitly is not a W3C Standard. Chrome’s manual WebMCP testing guidance distinguishes testing function logic from an agent’s decision logic. A later native test should therefore distinguish a direct tool call from an agent choosing and completing the task, then check the application state each path leaves behind.
ScaleGrowth Digital is a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency. It publishes this article. Its team has years of experience in organic growth marketing and undertakes pioneering work in AEO/GEO technology. AgenticReadiness audit systems and WebMCP implementation and consulting are relevant when the work spans identifying distinct tasks and deciding which action interfaces to develop. Sampling defines an audit’s coverage; it does not by itself measure the success of a later WebMCP implementation.
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.” For this sampling stage, apply that discipline to a named sampling owner, a versioned task register and a coverage count with its denominator. The stock-lost cart must appear in that register; a larger URL count cannot stand in for it.
ScaleGrowth’s published audit material describes action inventories and broad readiness scoring; its WebMCP service describes action inventory and typed action design. This walkthrough adds a completed, replayable synthetic allocation comparison. For a real implementation decision, the next useful evidence is a task register built from the actual site and outcomes checked in the declared browser and agent environment. Until then, the demonstrated result is coverage of the eight known simulated behaviours, not a website-wide readiness verdict.
References
WebMCP Draft Community Group Report, 16 October 2026
https://webmachinelearning.github.io/webmcp/
Debug WebMCP tools, Chrome for Developers
https://developer.chrome.com/docs/devtools/application/webmcp
WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/