List what the site can do
When source code is available, we inspect it and the site’s features to establish what can be read or changed and what counts as correct. Without source access, we assess which tasks can be covered.
Compare success, token usage, and time to completion.
We first establish the correct answer, then use WebMCP to attempt the task in fewer steps. Compare your computer-use agent: did it answer correctly, which extra actions did it take, and how many more tokens and seconds did it use?
FOR AGENT & MODEL TEAMS · COMPARE VERSION RESULTS
SAME SUCCESS. DIFFERENT COST.
65 books → the three cheapest
Fewer tokens
Less time
WebMCP vs CU · five-run medians for tokens and time; an observed reference, not a theoretical limit.
Check which tasks can be completed
Count the total tokens used for the task
Check completion, then compare elapsed time
WHY WEBMCP
Suppose the task is to find the three cheapest books on a site. CU typically browses pages, finds pagination controls, and reads prices. We can provide book lookup and price-reading tools through WebMCP. Then we compare whether both methods answer correctly and how many tokens and how much time each uses.
When source code is available, we inspect it and the site’s features to establish what can be read or changed and what counts as correct. Without source access, we assess which tasks can be covered.
WebMCP lists callable functions, their inputs, and their results. The model can choose a function without finding its button on the page each time.
Each extra page observation or attempted action can add tokens and waiting time. Calling a function directly can reduce these steps. We measure the savings by running the task.
If the required information and actions are available as text and tools, a tool-capable text model can attempt the task. This measures the tokens and time needed without locating buttons or interpreting screenshots.
This answers a specific question: how many resources does the task need when the model already knows the available functions and how to call them? Comparing that result with CU reveals the extra time and tokens.
We must build and check these tools against the site’s features. WebMCP does not automatically understand all source code or guarantee the fewest steps. Read about WebMCP ↗
GROUND TRUTH + REFERENCE EXECUTION
An evaluation needs two things: a definition of the correct result, called ground truth, and a tested way to reach it with recorded actions, tokens, and time. Comparing speed alone can make an unfinished task look faster.
For example: were the right three books selected, are their prices correct, and are they in the requested order? Check each requirement rather than whether an answer looks plausible.
DELIVERY: CORRECT RESULTS AND CHECKSRecord whether WebMCP completes the task, how many tokens it uses, and the time from start to finish. Then compare those figures with CU.
DELIVERY: COMPLETION, TOKENS, AND TIMEA successful WebMCP run shows that the task can be completed under those conditions. Its resource usage is an observed comparison point; another method may still be faster or use fewer tokens.
SUCCESS × TOKENS × TIME
Switch between three completed experiments to compare full-task success, total tokens, and elapsed time. Inspect completion and execution cost together, with unequal-work runs explained separately.
Successful runs / total runs
Total tokens · median per run
Seconds · median per run
Both groups passed 5/5 runs. WebMCP used 52.0% fewer median tokens and 36.2% less median time per run, exposing an efficiency gap beyond success rate.
Task: scan four pages and 65 books to find the three cheapest. These compare five-run medians, not theoretical minimum costs.Completed experiments, not a live evaluation. Total tokens are accumulated run usage, including repeated context; they are neither output length nor monetary cost. Results are shown per experiment, without pooling success rates.
Download comparison data ↓ONE TASK. TWO EXECUTION PATHS.
Agree on page data, task requirements, and run limits. WebMCP uses tools; CU uses the agreed interface controls. Independently check both answers and count tokens and elapsed time.
Function list → text-model calls → independent answer checks
Ground truth · Tokens · TimeDeclared screenshots / accessibility capabilities → UI actions → output
Completion · Tokens · TimeThe CU agent cannot access reference answers or grading interfaces. Reference and CU tracks declare their different capabilities.
Report success alongside tokens and time. Declare model, budget, environment, and retries; retain resource usage from failed runs.
Validate evaluators with known correct, incorrect, and partial states. Separate environment failures from agent failures.
COMPLETION BEFORE EFFICIENCY
In one HN CU run, all 100 text entries were correct, but only 25 reply relationships were confirmed. Ground truth must check the complete deliverable for resource comparisons to mean anything.
Verified correctUnverified
This criterion did not pass. With 75 relationships unverified, the complete task did not pass.
Data comes from a completed HN experiment verified independently against the page. This interactive example explains scoring; it does not run an agent. The WebMCP evaluator is the pilot design described below.
Download sample data ↓YOUR EVALUATION PACKAGE
Build a task suite for agent, model, or enterprise automation teams. Compare versions with consistent criteria and see whether capability improves—and what that improvement costs.
Site capability maps, task snapshots, target fields, business rules, and validated outcome evaluators.
Validated short paths, text-model conditions, per-run completion, tokens, and time; explicit mapping and setup costs.
Success, resource gaps, failed-run usage, and task-level evidence for version comparisons.
Repeat evaluation under agreed budgets; track success and resource usage with environment and version records.
Currently a browser-task pilot. Task scope, reference feasibility, delivery format, maintenance, and pricing are agreed per engagement.
READ THE METRICS CORRECTLY
No. Knowing the available functions and how to call them can reduce searching and retries. We record methods that have been tested, without claiming they are the only or best methods. The fewest steps may not mean the fewest tokens or the least time.
If information is returned as text and actions are available through tools, the model does not need to interpret screenshots. It must still understand the task, choose functions, and check the answer. Tasks that require judging images need a separate evaluation method.
It provides a tested comparison. If WebMCP finishes and CU does not, a working method existed under those conditions. If both finish, compare actions, tokens, and time. Differences may come from available information, tools, planning, or interface actions—not vision alone.
It is the evidence used to judge whether an answer is correct: for example, which three books should be selected, their prices, and their order. We check these answers independently rather than assuming a tool result is correct.
Tokens are units used to count the content a model processes as input and output. We show accumulated run usage, including repeated content. Tokens do not directly equal cost: model prices, caching, and billing rules also affect the bill.
Use the same page data, account permissions, and task requirements where possible. Record models, tools, retries, and other conditions. Report the resources spent preparing tools and documenting site functions separately. An unfinished task is not a faster completion; different page states or task sizes do not support a direct speedup claim.
We will contact you at the email you provide to agree on tasks, versions, deliverables, pricing, and timing. Applying does not charge you or activate a service.
BENCHMARK AGAINST WHAT’S POSSIBLE
Tell us the tasks and versions to compare, and whether you want higher success, fewer tokens, or less time. We will discuss the evaluation scope with you.