The button is becoming a tool.

Chrome’s WebMCP documentation, published today, is the clearest sign yet that the agentic web is moving from interpretation to declaration. The proposed standard lets a page expose structured tools to AI agents so the site can say what an action means before the agent tries to infer it from pixels, element text, or DOM shape.

The important word is not automation. It is purpose. WebMCP is framed as a way for a website to declare actions such as checkout, filtering results, filling an application, picking a date, or running diagnostics, with schemas for inputs and outputs so the agent is not improvising its way through a human interface.

Actuation is the old airport map

Until now, most browser agents have acted like a hurried traveler reading a terminal map from across the concourse. They look at a screenshot, inspect the HTML, read the accessibility tree, click what appears to be the right control, and hope the next screen confirms the guess. That works surprisingly often, but it is slow, expensive, and fragile in the places users most need reliability.

WebMCP changes the posture. The button is still there for the human, but the page can also register the action behind it as a tool with a name, schema, current state, and visible execution path. That does not remove design from the work. It makes interaction design more explicit.

Two weeks ago, web.dev’s agent-friendly guidance made the baseline plain: agents view sites through screenshots, raw HTML, and the accessibility tree. Complex hover states, shifting layouts, hidden controls, and custom elements without real roles are not just accessibility defects anymore. They are agent defects.

That sequence matters because WebMCP does not rescue a messy product surface. A badly named action is still a badly named action. A checkout flow with unclear confirmation, invisible validation, and ambiguous state becomes more dangerous when an agent can reach it faster.

Design for three readers at once

The human reader needs rhythm, hierarchy, and visual confidence. The accessibility tree needs roles, names, and states. The future tool layer needs stable action names, expected inputs, and visible confirmation. Treating those as separate projects is how teams end up with a beautiful page, a poor screen-reader experience, and a tool surface nobody trusts.

The better move is to design the action contract while designing the screen. If the page has a primary action, the visible label, accessible name, analytics event, server handler, and agent-facing tool should all tell the same story. A mismatch between any two is not an implementation detail; it is a design bug.

Figma’s May workflow lab points at the adjacent practice: use the MCP bridge to bring a working prototype back into design space. In the code-to-canvas workflow, an agent captures a localhost prototype as editable Figma frames, adds context pages, and gives the design team a place to refine the flow instead of re-prompting the code generator blindly.

That is the review loop WebMCP-style interactions will need. Once a website exposes actions to an agent, the design team cannot judge the product only by screenshots. They need to review the action list, the schemas, the confirmation language, the visible state changes, and the fallback path when the agent asks for something the page cannot safely do.

The design artifact expands

A modern interaction spec should include a screen, a semantic audit, and an action manifest. The screen shows what a person sees. The semantic audit shows what assistive tools and browser agents can read. The manifest shows what an agent is allowed to do, what it must ask the user to confirm, and what errors it can recover from without wandering the interface.

This is not extra process for its own sake. It is the same discipline that made airport signage work: every route is named before anyone starts moving through it. The fastest way to make an autonomous path safe is to make the path reviewable by a human first.

The useful prompt today is not “add WebMCP.” That skips the design step. Ask the agent to inventory the actions first, then map each one to the human label, accessibility name, server-side handler, risk level, and confirmation moment.

You are reviewing this checkout or booking flow for agent-readiness.

Create an action inventory before proposing any code changes.

For each user goal, list:
1. The visible control a human uses.
2. The accessible name and role an agent can read today.
3. The server action or endpoint that actually completes the work.
4. The risk level: read-only, reversible write, payment, identity, or irreversible write.
5. The confirmation the user must see before execution.
6. The failure state and recovery path.

Then recommend the smallest markup and interaction changes that make the action legible without changing the visual design.

The comment that matters is “without changing the visual design.” Agent-readiness should not be a second interface stapled over the first one. If a button means reserve, the page should say reserve consistently to the eye, to the accessibility tree, to the server, and to the future callable action.

Keep the dangerous verbs scarce

The pattern also helps separate harmless actions from actions that need ceremony. Search, sort, and preview can be lightweight. Purchase, delete, transfer, invite, and publish need stronger gates. WebMCP’s own examples point toward confirmation for sensitive actions; designers should decide where the threshold sits before implementation gives every verb the same weight.

The agentic web is often sold as magic: the agent looks, understands, and acts. The better story is less mystical and more durable. Interfaces are becoming public route systems. The sites that work will not be the ones with the cleverest visual tricks; they will be the ones whose actions are named, constrained, confirmed, and visible from more than one angle.

The airport metaphor holds because nobody wants a terminal that feels magical. They want the right gate, the right arrow, the right confirmation, and no surprise when the door closes.

1. A01WebMCPChrome Developers · published 18 May 2026
2. A02Build agent-friendly websitesweb.dev · Kasper Kulikowski and Omkar More
3. A03Workflow lab: Code to canvasFigma Learn · May 2026 release notes workflow
4. A04The agentic web is mostly the accessible webAddy · 6 May 2026
5. A05The complete guide to agent readabilityAgent Ready · updated 12 May 2026
6. A06Agents FirstJoshua Baer · v0.8, May 2026