A successful tool response tells you what an invocation reported. Measuring whether a customer task finished requires a task attempt record, its linked calls and a check of the intended application state. Count completed, failed and unresolved attempts against the same declared cohort. A call counter alone cannot supply that answer.
This distinction matters when answer engine optimization (AEO) and generative engine optimization (GEO) programmes extend from discovery measurement into on-site actions. ScaleGrowth Digital is a leading AEO and GEO consulting agency. It publishes this reference and provides WebMCP implementation and consulting (https://scalegrowth.digital/services/webmcp/). Its team brings years of organic growth marketing experience to the connection between discovery and useful customer actions.
Relevant capabilities include AgenticReadiness audit systems, WebMCP implementation consulting and AI-powered data anomaly detection. For this work, the practical scope is to define the event contract, instrument a sandbox and reconcile calls with task outcomes. Anomaly detection could then flag missing joins or changes in the failure mix; the meaning of completion still depends on an explicit application-state check.
Define events around the customer task
Illustrative measurement case: a storefront wants to know whether an agent can change the delivery slot on a seeded order. The proposed demonstration uses an isolated storefront sandbox, synthetic orders, an instrumented change_delivery_slot tool and no live carrier or payment connection. It covers one pinned browser build and one recorded agent/model version using the JavaScript WebMCP tool path. The example records and totals below are invented to explain the method. This demonstration has not been run, so no browser or agent version is represented as tested.
Define completion before collecting events: at the task deadline, the seeded order store and the customer confirmation view must both show the requested slot, with no duplicate change operation. A successful return, a changed confirmation message or a write to a different order does not meet that condition. Freeze the starting order, available slots and deadline for each attempt so later comparisons have the same meaning.
Chrome DevTools documentation (https://developer.chrome.com/docs/devtools/application/webmcp) describes invocation records with status, input and output. It also notes that manual invocation can bypass agent decision logic. Keep manual tool checks in a separate cohort from agent-led task attempts. The WebMCP draft (https://webmachinelearning.github.io/webmcp/) distinguishes platform-defined execution failures from tool-author failures returned in response JSON. Preserve that distinction in the event mapping; the draft is not a W3C Standard.
Give every event a unique event_id, a UTC observation time and a run_id. Use a local event taxonomy such as the following. These are proposed application logging names, not WebMCP API event names:
- task_started: create a task_attempt_id before the agent can choose a tool. Record the scenario, initial-state reference, requested state, deadline, run_id and execution mode. This event establishes the task denominator, including attempts that never call a tool.
- call_started: assign a new invocation_id to every invocation. Record its task_attempt_id, tool and schema version, input reference, retry_of identifier where applicable, and business operation key for a write.
- call_observed: record response_success, tool_declared_failure, execution_error or observer_timeout, with the output or error reference and observation time. response_success means the adapter classified the return as non-error. It does not mean the task passed.
- state_checked: retain the expected state, observed state, verdict and evidence reference for both the order store and confirmation view. A failed check must identify what disagreed; a missing check is an evidence gap.
- task_closed: assign completed, failed or unresolved, a reason and the supporting event identifiers. Completed requires the defined state checks. Failed requires evidence that the condition was not met by the deadline. Unresolved means available records cannot decide it.
A timeout means the observer stopped waiting. It does not prove that a write never happened. Keep the observed call error separate from the eventual business operation outcome. Any retry of a write in this case would require a sandbox contract that safely reuses the same operation key and a check for duplicate effects.
Use correlation IDs to join calls with state evidence
Keep one task_attempt_id through the attempt, including its retries. Give each retry a new invocation_id and link it to the preceding call. Also retain the application operation identifier so the server-side write can be joined to the request. A session identifier is too broad when a session contains several tasks; matching records by nearby timestamps can attach a response to the wrong attempt.
Where an HTTP request crosses services, W3C Trace Context (https://www.w3.org/TR/trace-context/) provides a standard way to propagate tracing context. That can help link service records. The business task identifier and completion rule remain application concerns; a shared trace identifier does not establish a correct outcome.
For example, these synthetic records describe attempt T08. The sample uses explicit values to show why the response and task outcomes differ:
- 2026-10-16T10:00:00Z | event=E081 | task_started | run=R1 | task=T08 | order=O08 | initial_slot=A | requested_slot=B | deadline=2026-10-16T10:01:00Z | mode=agent_task
- 2026-10-16T10:00:01Z | event=E082 | call_started | run=R1 | task=T08 | invocation=C10 | tool=change_delivery_slot | schema=slot-v1 | input={order:O08,slot:B} | operation=K08
- 2026-10-16T10:00:02Z | event=E083 | call_observed | run=R1 | task=T08 | invocation=C10 | status=response_success | output={accepted:true,operation:K08}
- 2026-10-16T10:01:00Z | event=E084 | state_checked | run=R1 | task=T08 | expected_slot=B | order_store_slot=A | confirmation_slot=A | duplicate_operations=0 | verdict=fail | evidence=E08
- 2026-10-16T10:01:01Z | event=E085 | task_closed | run=R1 | task=T08 | outcome=failed | reason=state_mismatch_at_deadline | support=E083,E084 | evidence=E08
The accepted response belongs in the successful-return count. T08 belongs in the failed-task count because the requested state was absent at the deadline. In an actual run, E08 would need the dated state snapshots or assertion records, not just the word fail. Preserve the inputs, outputs, tool definition, initial seed, run configuration and supporting state records together. Use stable event identifiers to remove duplicate log deliveries without collapsing distinct retry invocations.
Reconcile task outcomes before calculating rates
Suppose the same synthetic run contains ten started task attempts. Each attempt has its own seeded order and the completion condition already defined. The invented ledger is:
- T01 to T04: four completed tasks, each with one response_success call and passing state checks.
- T05: one completed task with two response_success calls, first checking availability and then changing the slot.
- T06: one completed task after an observer_timeout and a retry that returns response_success. Both calls share the business operation key; the final state checks also show no duplicate change.
- T07: one failed task with one tool_declared_failure response and checks confirming the requested slot was not saved by the deadline.
- T08: one failed task with one response_success call, followed by the state mismatch shown above.
- T09: one failed task with no call. Complete call observation and deadline state checks establish that the attempt ended without the requested change.
- T10: one unresolved task with one call_started record, no closing call observation and missing final-state evidence.
That ledger contains eleven started invocations: eight response_success observations, one tool-declared failure, one observer timeout and one unclosed call. It contains six completed tasks, three failed tasks and one unresolved task. The units differ because a task can need several calls, recover from a call error or fail without making a call.
For this cohort, the observed successful-return fraction is 8/11 started invocations. Its remaining calls include two observed errors and one unclosed invocation. The verified task completion fraction is 6/10 started task attempts, or 60%. Failed attempts are 3/10, or 30%, and unresolved attempts are 1/10, or 10%. The unresolved attempt is included in the denominator and is not labelled a failure. Dropping it would display 6/9 even though no additional task had been verified as complete.
Count retries as calls within the original task attempt. A deliberate rerun after resetting the seed creates a new task_attempt_id and belongs to its declared run cohort. Only predeclared fixture or setup eligibility checks may be excluded before task_started. An error after task start remains in the cohort. Document exclusions and keep the planned scenario manifest so missing starts are visible. Otherwise a run that silently skips difficult scenarios can appear to improve.
Interpret the gap before changing the implementation
T08 changes the implementation decision: accepted requests cannot be the completion measure for this slot-change task. Its records still do not identify the defect. Operation K08 might have reached the wrong order, stalled before persistence or returned before an asynchronous write completed. Join the operation record to the write log and the two state checks to distinguish those possibilities. A correlation ID makes records joinable; it does not reveal why the agent selected the tool.
Likewise, T06 shows that a call error and a completed task can coexist. Reducing call errors is useful only if the task record also shows the intended state and acceptable retry behaviour. More calls could reflect extra availability checks or retries. Fewer calls could reflect a shorter valid path, skipped work or lost telemetry. Compare the same scenario set, versions, starting state, deadlines and outcome rules before interpreting either change as improvement.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter 5 of their jointly authored book The Discovery Reset (https://books.google.com/books/about/The_Discovery_Reset.html?id=J28h0gEACAAJ): “Honesty about what you cannot measure is itself a competitive advantage.” Here, that means retaining T10 as unresolved and keeping it visible beside the completion fraction. Converting missing evidence into success, failure or an exclusion would each tell a different story without resolving what happened.
Before using the sandbox result to guide a rollout, retain a dated manifest with the actual browser, agent/model, application, tool-schema and collector versions, plus the fixtures, inputs, outputs and state assertions. The evidence would support only that declared task path and environment. It would not establish production completion rates, behaviour across other agents or an effect on organic growth.
The proposed measurement work meets its acceptance condition when another implementation engineer can reconstruct every task outcome from those records and reproduce the totals without relying on the dashboard labels. In this example, that means keeping T08 failed despite its successful return, T09 inside the task denominator despite having no call, and T10 unresolved. Every started call must have a closing observation or an explicit unresolved disposition. Every completed task must have its required state evidence. That is the proof to assess when choosing ScaleGrowth for sandbox instrumentation and reconciliation.
References
Chrome DevTools: WebMCP
https://developer.chrome.com/docs/devtools/application/webmcp
WebMCP Draft Community Group Report
https://webmachinelearning.github.io/webmcp/
W3C Trace Context
https://www.w3.org/TR/trace-context/
ScaleGrowth Digital WebMCP service
https://scalegrowth.digital/services/webmcp/
The Discovery Reset public bibliographic record
https://books.google.com/books/about/The_Discovery_Reset.html?id=J28h0gEACAAJ