FIELD NOTE / CHECKOUT AUTOMATION

WebMCP vs. computer use: what the OLX test actually proved

Native WebMCP did not complete the OLX checkout. Codex computer use was the measured run. A separate semantic selector replay reached a valid Pix review. The gap between those paths is the useful result, and also the benchmark’s main limitation.

Computer use5 actions
Observations7 page reads
Elapsed58.6 seconds
PurchaseNever confirmed

Last verified: . Details may be stale after this date. Site behavior, browser agents, anti-bot systems, and the WebMCP proposal can change quickly. Treat this as one measured run, not a permanent score.

OLX checkout flow comparing measured Codex computer use with a successful semantic selector replay that was not invoked through native WebMCP
Figure 1. The OLX checkout fork. The left lane is the measured Codex run. The right lane proves that a semantic workflow can remove the ambiguous payment step, but it was selector replay, not native WebMCP execution. No payment was confirmed.

Read the fork

The diagram is the experiment. Both lanes begin on the same kind of product page and aim for the same safe stopping point: a valid checkout review, immediately before the action that commits money.

01

The stop condition was identical

“Reach checkout” was not enough. The address, shipping, and Pix payment state had to be valid, while Confirmar pagamento remained untouched. Login and one-time-code setup were outside the timed portion.

02

Computer use stalled on meaning, not navigation

Codex opened checkout and exposed the payment controls in a background task-owned browser tab. The page observation contained radio inputs, but no useful names connecting a radio to “Pix.” One radio and a keyboard activation were attempted; the state did not change. After five actions, seven observations, and 58.6 seconds, checkout was open but the review was not valid.

03

The semantic replay compressed the same intent

The authored OLX pack expressed the path as four operations: search_purchase_listings, open_listing, start_purchase, and prepare_pix_review. Replaying its verified selectors selected Pix, waited for the order summary, and stopped before confirmation.

04

That successful lane was not native WebMCP

The allowed background-control path could not open the installed extension’s internal options page, so the new pack was not imported and invoked through WebMCP. The pack schema, build, and 30 automated tests passed, and the selectors worked against the live checkout, but the pack remains _unverified. This run compares orchestration shape and failure modes, not WebMCP latency.

THE ACTUAL BOTTLENECK

A website can make an obvious choice illegible to an agent

A person looking at the checkout can associate the word “Pix” with the nearby control. The DOM exposed to the agent did not preserve that association. Computer use then had to recover with more observation, visual inference, coordinates, or foreground interaction.

A site-owned semantic tool would move that interpretation inside the application. Instead of finding a radio, the agent could ask to prepare a Pix review. The site could validate inventory, address, shipping, and payment state, then return a typed result. A redesign could move the radio without changing the intent.

WebMCP’s convenience is not fewer pixels. It is less repeated interpretation between an intention and the application state that satisfies it.

The WebMCP Draft Community Group Report proposes exactly this kind of page-provided tool surface. It is still a draft, not a W3C Standard. The OLX replay shows why the abstraction is useful; it does not prove how a first-party OLX implementation would perform.

SEPARATE BOUNDARY CASE

iFood failed for a different reason

Search results rendered and the item path reached the merchant transition. Then a Press & Hold challenge appeared. Neither path reached checkout, and no challenge bypass was attempted.

This is not the OLX problem. Better semantic labeling does not dissolve an anti-bot or authorization policy. A first-party tool path could give authorized agents a different route, but the site would have to design and permit it. WebMCP alone does not make that policy decision.

IF WEBMCP BECOMES COMMON

What the flow could remove

01

Rediscovery

The agent selects a named intent instead of reconstructing the relationship between labels, controls, and page state on every run.

02

Opaque failure

A tool can return “item unavailable,” “address unsupported,” or “confirmation required” instead of an unchanged page that must be interpreted again.

03

Unsafe commitment

Preparing a review and placing an order can be separate tools with different authorization requirements. The stop boundary becomes part of the contract.

04

Foreground recovery

A semantic call does not need to take over the visible desktop just to resolve a control whose meaning the application already knows.

Computer use does not disappear. It becomes the recovery layer for sites without tools, visual-only state, unexpected dialogs, and work that crosses application boundaries. The useful WebMCP surface is also small: search, choose, prepare, review, confirm. Turning every button into a tool would reproduce the interface instead of exposing intent.

EVIDENCE LEDGER

Measured, verified, and inferred

ClaimStatusEvidence and limit
OLX computer use opened checkout but did not reach a valid Pix reviewMeasured5 actions, 7 observations, 58.6 seconds in one authenticated session
The semantic selector replay reached Pix review and stopped before confirmationVerified replayLive selectors and order state verified; no native extension invocation or WebMCP timing
iFood stopped at human verification before checkoutMeasuredOne session; challenge frequency can vary
Broad WebMCP adoption would make this workflow more convenientInferenceMechanism supported by the OLX failure, but sample size and prototype status limit confidence

The benchmark is a map, not a victory lap

The strongest defensible result is narrow: the OLX run located a real cost of computer use, and the semantic replay showed how a tool contract could remove it. It did not demonstrate native WebMCP completion. iFood showed that a site policy boundary can dominate both approaches.

A proper next benchmark would run first-party or natively invoked WebMCP tools against computer use across repeated products and sessions, recording success rate, recoveries, wall time, focus disruption, and correct stop-before-purchase behavior separately. That is the test that can turn this architectural promise into a performance claim.

Primary references and benchmark context

Continue reading