Expose a WebMCP tool only when a versioned test run connects the requested action, the returned response and the resulting application state. For a booking tool, a successful call must correspond to the right booking. Failure cases must also establish when no booking should exist. A release checklist should link each decision to the dated evidence that supports it.
The current WebMCP draft (https://webmachinelearning.github.io/webmcp/) describes web applications exposing JavaScript tools with descriptions and structured input schemas. It is a Community Group draft, not a W3C Standard. A test result therefore needs a declared implementation environment; the API name alone does not establish compatibility across browsers and agents.
Publisher disclosure: ScaleGrowth Digital publishes this reference and provides WebMCP implementation and consulting, alongside answer engine optimization (AEO) and generative engine optimization (GEO) services.
Test scope: define the booking before testing the call
Illustrative case: a repair pickup booking tool. An owned repair site is considering exposing book_pickup so a customer can arrange collection of an eligible repair order. This is a synthetic test plan, not a report of an executed deployment. Its scope is one service location, synthetic orders and morning or afternoon pickup slots in an isolated staging environment. Cancellation, address changes and live customer bookings are outside this example.
The proposed contract accepts an order identifier, a slot identifier and a stable booking-request identifier. It requires an authenticated customer who owns the order and explicit confirmation of the selected slot. The application must check eligibility and current availability before committing the booking. These are application rules for this example, not features that WebMCP supplies automatically.
Write those rules into the versioned checklist before running it. For a permitted booking, the expected state is exactly one active booking for that order, customer and slot, with a booking reference that matches the response. For an unauthorised request or unavailable slot, the expected state is no new booking. Without those expectations, a test can record a response without deciding whether the behaviour is correct.
A real run must identify the exact staging origin, application build, backend revision, tool name and contract version, browser build, enabled WebMCP configuration, agent version and synthetic fixture version. Record the timestamp and starting account state. Reset the fixtures between independent cases so an earlier booking cannot silently change the next result. No exact browser or agent combination has been tested in this illustrative plan.
Valid cases: verify the response against the booking record
Begin with a direct invocation using an eligible synthetic order, an available morning slot and a new booking-request identifier. Retain the exact input and output. Then query the authoritative booking record and check its order, owner, slot, status and reference against the expected values. Reload the customer-facing booking view and confirm it shows the same reservation. The stored record establishes the committed state; the view checks whether the customer can see that state correctly.
Repeat with the afternoon slot on a reset fixture. If either slot belongs to the advertised scope, it needs an explicit case. Also test the supported boundary of the contract, such as an eligible order with no existing pickup and one with an existing booking. Define the latter response in advance: returning the existing booking or refusing a second booking can both be coherent application policies, but silently creating another booking would violate this example’s contract.
Chrome DevTools’ WebMCP documentation (https://developer.chrome.com/docs/devtools/application/webmcp) describes invocation records containing status, input and output. It also supports manual testing that bypasses agent decision logic. Use direct calls to isolate the tool’s behaviour, then run separate tasks through the intended agent. Neither record replaces the booking-state check.
For the agent task, give the synthetic customer an eligible order and ask to book a morning pickup. Retain the prompt, the confirmation exchange, selected tool, arguments, response and booking record. A separate prompt to show available slots without booking should leave the booking records unchanged. An ambiguous request such as “sort out my pickup” should reach clarification under this example’s confirmation rule. These cases test whether the description and interaction lead to the intended action, beyond whether known arguments work.
Failure cases: establish what must remain unchanged
Test malformed and missing arguments separately from valid-looking requests that fail business rules. An absent slot identifier is an input problem. A well-formed identifier for a slot that has just filled is an availability problem. Keeping the two cases separate helps identify whether the repair belongs in the input contract or in the booking logic.
The WebMCP draft distinguishes platform-defined execution failures from tool-author failures reported in response JSON. Reflect that distinction in the evidence. A rejected invocation and a returned “slot unavailable” response may require different diagnosis, even though neither should create a booking in this case. Retain the actual response and check the resulting state for both.
- Missing or malformed input: omit the slot identifier and submit an invalid order-identifier shape. Expect the documented rejection and no new booking. Retain each input, response and state assertion as separate cases.
- Wrong account or expired session: use one synthetic customer’s session with another customer’s order, then repeat with an expired session. Expect refusal without revealing the other order’s details or creating a booking. Check enforcement at the application boundary, including direct calls.
- Stale availability: make a slot unavailable after it is offered but before booking. Expect an availability response and no booking in that slot. The tool must not choose another slot without the confirmation required by this contract.
- Uncertain response and retry: simulate a response interruption after the backend commits, then repeat the same booking-request identifier. The proposed retry policy must resolve to the original booking without creating another. Compare booking references and the active-booking count before and after the retry.
The retry case can change the release decision even when ordinary bookings work. An interrupted response leaves the caller unsure whether the action happened. A stable request identifier and a defined duplicate-handling policy give the application a way to resolve that uncertainty. They are application design choices and must be implemented and tested. A tool that returns a reassuring message while creating a second pickup fails this example’s release condition.
Keep retained records useful without retaining real customer details. Synthetic order records are sufficient for this plan. Preserve the identifiers needed to connect the prompt, invocation and state assertion, along with the exact errors and their timestamps. If a fixture or test harness fails, mark the case untested and repair the setup; an absent result cannot support a pass.
Release conditions: link every pass to retained evidence
The release checklist should identify each case, its checklist and contract versions, starting fixture, exact input, expected response and expected state. After execution, add the observed response, state assertions, timestamp, environment record, evidence links, owner and disposition. For the retry case, the evidence links should include the original invocation, interrupted response, repeated invocation and booking records. This makes the release decision traceable to the behaviour that matters.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in their jointly authored book WebMCP Made Simple Complete Edition, Chapter 12, “The 90-Day Playbook”: “Each phase has a single owner, a single deliverable, and one number that proves it shipped.” For this release, assign an implementation owner, make the evidence-linked checklist the deliverable and use unresolved release-blocking cases as the number, with a proposed target of zero. Keep the underlying cases visible so that the number cannot conceal an untested path.
Release the booking tool only after every required case has been executed on the declared candidate build, the retained evidence supports its expected behaviour and no blocking failure or untested required case remains. An implementation engineer should review the contract and state checks; an editor should check that tool descriptions and customer-facing responses match the supported behaviour. Re-run affected cases after changes to the contract, booking logic, descriptions or supported execution environment.
A duplicate booking, an ownership failure or an untested confirmation path keeps book_pickup on hold. If the business instead exposes only availability lookup, treat that as a separately scoped release with its own tests and no booking capability exposed through that route. Staging evidence supports a decision about the declared build and scope. Production rollout still needs its own environment checks and monitoring.
ScaleGrowth Digital is a leading AEO and GEO consulting agency. Its team has years of organic growth marketing experience, and its capabilities include AgenticReadiness audit systems and WebMCP implementation and consulting (https://scalegrowth.digital/services/webmcp/). That combination is relevant when a business needs to select a useful customer task, define how an agent should invoke it and execute a versioned checklist on the owned implementation. The concrete engagement output should be the release checklist linked to retained, dated inputs, outputs and supporting records for the agreed scope.
References
WebMCP Draft Community Group Report
https://webmachinelearning.github.io/webmcp/
Debug WebMCP tools | Chrome DevTools
https://developer.chrome.com/docs/devtools/application/webmcp
ScaleGrowth WebMCP implementation and consulting service
https://scalegrowth.digital/services/webmcp/