Measure WebMCP lift without inventing a universal ROI number
Compare equivalent completed journeys and publish the counting rules, evidence, and limitations behind the result.
The short version: A before-and-after number is useful only when the task, fixture, success criteria, and counting method are genuinely equivalent.
Define equivalence before you run
The UI and WebMCP paths must start from the same state, operate on the same data, and satisfy the same observable postconditions. If the agent path receives extra information or the UI path is intentionally obstructed, the comparison measures fixture design rather than interface quality.
Put successful outcome first
Record whether the task completed and every required assertion passed. Efficiency metrics should be secondary. A fast failed call is not an improvement over a slower successful journey, and a tool that silently changes the wrong record should score worse than an explicit failure.
Publish the counting rules
Define what counts as a UI action, a tool call, a retry, a human intervention, and elapsed time. Record setup and verification consistently across both paths. Store an event ledger so reviewers can recalculate the summary rather than trusting a dashboard number.
Avoid universal token, cost, or speed claims
HTML size and tool payload size are not the same as end-to-end model token use. Agent observations, screenshots, retries, hidden prompts, caching, and model behavior all matter. A measured reduction for one workflow is evidence for that workflow, not a guaranteed industry range.
Report uncertainty and failure honestly
Label synthetic fixtures, imported contracts, browser shims, and manually observed runs. Publish model and browser versions where selection is measured. If evidence is unavailable, show “not observed” instead of converting unknown into zero or a pass.
Primary references
Read the sources
Put it to work
Use the guide on a real product surface.