Agents that operate websites through the visual interface must perceive the page, locate controls, and infer which action will produce the intended result. This route is necessary when a site offers only a human interface. It is also expensive: each step may involve an image, a large DOM representation, a click attempt, and another verification.
WebMCP proposes an additional layer. The draft published by the Web Machine Learning Community Group allows web applications to register JavaScript tools that agents can discover and execute. Instead of interpreting a button and its surroundings, an agent receives a capability with a name, description, parameters, and result.
The API change looks small, but its architectural effect is large. A website stops being only a surface for automation and starts declaring how it wants to be operated.
Contracts beat perception for structured tasks
A visual interface carries information that people need: position, hierarchy, color, text, and feedback. For an agent that already knows the intent, some of that information is noise. If the task is adding an item to a cart, checking an order, or saving a preference, a well-defined function can represent the operation with much less context.
That reduction should not become a universal savings promise. Cost depends on the model, website, tool, and task. The specification defines how capabilities are exposed; it does not guarantee a fixed token percentage for every workflow.
The sound argument is structural. A compact schema usually requires less interpretation than an entire page. It also survives cosmetic changes better. Changing CSS classes or moving a button may break visual automation, while a tool with a stable contract can continue to work.
The human interface remains necessary
WebMCP serves actions that can be described as operations. It does not replace visual observation when a decision depends on composition, legibility, trust, or subjective comparison. An agent may use a tool to submit data and still need to inspect the page to verify how the result was presented.
Some tasks are exploratory because the user does not yet know which operation is needed. Browsing, reading, and forming an intent are part of the work. Exposing hundreds of functions to cover every possibility would recreate in the tool catalog the context overload that the approach is supposed to reduce.
A useful division is to keep perception for discovery and verification, while using explicit capabilities for known operations.
The contract becomes a security surface
A tool available to agents needs the same controls as any sensitive API. Authentication, authorization, input validation, confirmation for irreversible actions, and rate limits remain mandatory. A call happening in the browser does not make the operation safe.
Agency adds another problem. A person may authorize an agent to work on a website without authorizing every action to happen without review. Read operations have a different risk from purchases, deletions, messages, or account changes. The site must expose that difference clearly and preserve confirmation where the cost of error is high.
Tool descriptions are part of the trust boundary. An ambiguous name or permissive parameter can lead to misuse even without an attacker. Smaller contracts are easier to review when they are also specific.
The specification remains a work in progress
In September 2026, the specification identifies itself as a Draft Community Group Report. It explicitly says that it is neither a W3C Standard nor on the Standards Track. That status changes the adoption decision.
A team can experiment with one isolated flow, measure cost, and learn how to design capabilities. It should avoid making the draft a central dependency without accounting for API changes, browser support, and interoperability among agents.
The best pilot has a reversible action, a narrow contract, and a working alternative through the existing interface. The experiment then produces data without blocking current users or automation.
How to evaluate the actual gain
Compare two routes for the same task. In the first, the agent navigates visually. In the second, it discovers and calls a WebMCP tool. Record tokens, latency, failures, confirmations, and the quality of final verification.
The result may show that execution became cheap while discovery remained expensive. It may show fewer errors or reveal that the tool exposes too much authority. Those measurements guide design better than a benchmark copied from another website.
WebMCP points toward a plausible change: websites may have an interface for people and an operational layer for agents. Its value comes from reserving perception for decisions that need it and using explicit contracts where an operation is already clear.
Maintenance cost belongs in the comparison too. An abandoned tool or a contract that diverges from the public interface creates another form of breakage. The experiment wins only when the explicit capability is maintained as carefully as the visible action it represents.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
