The web has always explained products visually: labels, controls, hierarchy and feedback tell a person what can happen next. An AI agent can try to interpret those same clues, but screen-reading and simulated clicks are brittle. WebMCP proposes another layer in which a page describes useful actions as structured tools, giving the agent an explicit route to the product’s capabilities.
The Web Machine Learning Community Group’s 26 August 2026 draft defines JavaScript APIs for registering tools with names, descriptions, input schemas and execution logic. The proposal is still experimental, but the direction is concrete: a website can state what it offers instead of asking an agent to infer every action from rendered pixels.
From clickable pages to understandable products
Consider a travel site. Today an agent may need to find the destination field, select dates, interpret validation, press Search and scrape the results. With a structured tool, the site could expose searchTrips with explicit destination, departure and return parameters. The visual interface still serves people; the tool becomes an additional interaction layer for agents and assistive technology.
That distinction matters for product design. A screen is no longer the only expression of a feature. The underlying capability also needs a clear name, a bounded input model, understandable feedback and predictable failure states. Interaction design starts to include the semantics of the product, not only its pixels.
An agent-ready interface should not hide complexity. It should expose intent clearly enough that both the agent and the person can understand what will happen next.
The new design surface is intent
Tool names and descriptions may sound like implementation details, but they shape behaviour in the same way that labels and information architecture do. A vague tool called manageAccount is the agent equivalent of an ambiguous button. A narrower action such as updateDeliveryAddress communicates scope, expected inputs and likely consequences.
Design teams should treat these definitions as product copy. They need content design, edge-case mapping and user research. Teams should also decide which actions remain visual-only, which require confirmation, which are read-only and which can make consequential changes.
- Make each tool represent one clear user intention.
- Return feedback that a person can verify in the visible interface.
- Separate exploration from finalisation for consequential actions.
- Use the smallest input schema that can complete the task safely.
- Design failure messages as recovery guidance, not technical errors.
Shared context is powerful—and sensitive
WebMCP runs in the browser context, which means it can work alongside a signed-in experience. That is useful: the site can reuse existing application logic and reflect changes immediately in the same interface. It also raises the stakes. The specification devotes substantial attention to prompt injection, misrepresented intent, privacy leakage and same-origin boundaries.
A good implementation cannot assume that a technically valid tool call represents the person’s real intention. For sensitive actions, the interface should show what is about to change, who or what will receive data, and whether the action can be reversed. Confirmation is not friction when it provides necessary understanding.
What product teams can do now
WebMCP remains a draft, so this is not the moment to rebuild every product around it. It is the moment to audit product capabilities. Can the team describe each important action precisely? Are permissions and consequences visible? Does the UI reflect state changes reliably? Those questions improve conventional APIs and accessible interfaces even if the standard evolves.
The broader direction is clear. The web is gaining an interaction layer where agents can collaborate with people inside the same product. Designers who understand systems, language, permissions and feedback will have as much influence on that layer as engineers. This is exactly where design engineering becomes valuable: connecting human intention, interface behaviour and technical execution. See how I approach product and design engineering ↗
