What changed
The Chrome team published a new practical guide for building agentic workflows with WebMCP on August 26. WebMCP is an experimental proposed web standard that lets a page expose JavaScript functions or HTML forms as structured tools for an agent. Instead of asking an agent to infer a button's meaning from pixels, the DOM, and a sequence of clicks, the site can describe the action, its inputs, and its expected result directly.
The important shift is that the website becomes an active participant in the agent interaction. A browser, extension, or embedded agent can discover tools on the current page, call them with structured arguments, and receive a result while the page updates its own UI and state. The WebMCP overview describes this as a progressive enhancement: the human interface stays primary, while agent-friendly capabilities are added alongside it.
The product pattern
Chrome's guidance starts with product design rather than API syntax. Define the user's goal, the starting application state, the information the agent needs, and the boundaries around what it must not do. Then role-play the conversation and map each turn to the tools and visible UI changes required to complete the journey.
That produces a more useful contract than a generic collection of functions. A CRM might expose findClient for a focused lookup, then add tools to summarize meeting notes and draft a follow-up. A travel product might expose search, filtering, and booking as separate steps, with the site displaying each new state. For a complex JavaScript workflow, the imperative API registers a tool with document.modelContext.registerTool(). For standard forms, the declarative API can describe a tool through HTML annotations. Both approaches use explicit schemas so the agent has less room to guess.
This is different from a backend MCP integration, not a replacement for it. A backend tool is useful when an agent should call a service directly. WebMCP is useful when the work belongs inside an existing authenticated, interactive page and the user should see the same state the agent is changing. The WebMCP explainer frames it as a client-side alternative that can reuse application logic instead of forcing teams to recreate UI state and authentication on a separate server.
Why it matters
For product teams, agent support is starting to look less like an integration checkbox and more like another interface contract. A well-designed tool can reduce the number of ambiguous interaction steps, keep brand and human review visible, and make flows such as support intake, filtering, scheduling, checkout, or diagnostics easier for an agent to complete reliably. It also gives the site more influence over how an agent uses its capabilities.
The guidance is equally clear about the unfinished parts. WebMCP is under active discussion, primarily targets local browser workflows with a human in the loop, and currently requires an origin-isolated document plus the tools Permissions Policy. Sensitive actions should still surface a confirmation step. Tool errors should explain the missing prerequisite or invalid input in language the agent can act on, and the resulting journeys should be tested with evaluations and production telemetry.
The practical takeaway is to start small: choose one high-value, reversible user journey, expose the smallest typed tool surface that supports it, preserve the existing UI as the source of visible state, and keep irreversible mutations behind explicit approval. The web is not becoming agent-only. It is gaining a second, more structured way for people and software to work together.