WebMCP: When Websites Become Tools for AI Agents
Until now, AI assistants have largely had to operate websites the way people do: open a page, identify buttons, find fields, enter text, and hope every step was interpreted correctly. This works surprisingly often, but not reliably enough for important processes.
WebMCP proposes a different approach. A website should not only show an AI agent what is on the page. It should be able to state explicitly which actions are available, which inputs they expect, and which result they return. An interface the agent has to guess becomes a defined interaction layer within the visible website.
Chrome describes WebMCP as a proposed web standard for structured tools that websites can expose to AI agents. An origin trial has been available since Chrome 149. The standard is therefore not finished and does not belong on every project roadmap yet. But the direction matters: after machine readability comes machine operability.
WebMCP does not replace the visible website. It adds clearly defined actions for AI agents.
From understanding a page to completing a task
Our previous article on Machine Experience asked a central question: can an AI system reliably understand a website’s offer, evidence, and next steps? WebMCP starts one step later. Once the agent understands the page, can it act there reliably?
Browser agents currently complete many tasks through the user interface. They analyse visible content or the accessibility tree, identify likely buttons, and simulate clicks and text entry. Small changes can interrupt the process: a renamed field, a dialog covering the form, reordered navigation, or a selection whose meaning only becomes clear through visual context.
That may be sufficient for low-stakes tasks. It is not sufficient for a support request, application, reservation, or order. A date mapped to the wrong field, an overlooked requirement, or an ambiguous confirmation step can make the entire process unusable.
WebMCP aims to reduce that uncertainty. A website might define a submit_support_request tool, describe its inputs with a JSON Schema, and return a structured result. The agent no longer has to guess whether a field expects a first name or a full name. The website has declared the meaning explicitly.
What WebMCP changes technically
The proposal offers two ways to expose tools:
- Declaratively through HTML forms: Existing forms gain additional annotations, so agents can identify their purpose, inputs, and actions.
- Imperatively through JavaScript: More complex processes are registered as functions. This suits dynamic workflows, state changes, and multi-step tasks.
Both routes follow the same principle: the website controls which actions exist. The agent does not receive unrestricted access to the application. It sees defined tools with expected inputs, outputs, and failure cases.
According to Chrome’s early preview announcement, these tools should allow browser agents to act faster, more precisely, and more reliably than they can through raw Document Object Model interaction. Potential use cases include support tickets, product search, configuration, travel booking, and navigation through complex data.
What WebMCP is not also matters. Tools currently run in the context of an open website. A browser tab or webview remains necessary; an arbitrary agent cannot call them invisibly in a headless process. Browsers and assistants also need to implement the standard. WebMCP is therefore a progressive enhancement, not a replacement for accessible HTML, clear forms, or stable APIs.
Why businesses should understand it early
New web standards take time. Some become widely adopted; others disappear. The business consequences should still be considered before every browser supports them.
1. The website becomes part of an assistant’s working interface
A business website has traditionally been the destination of a search and the starting point of a human decision. In a web shaped more strongly by AI assistants, it can also become an executable part of a workflow.
A prospective client could ask an assistant to compare suitable services and prepare a qualified enquiry. An applicant could have documents checked and an application form completed. A customer could open a support case with device data, an error message, and contact details without navigating several pages.
The website remains visible. But part of its use is no longer driven by individual clicks. It begins with an intention expressed in natural language.
2. Good forms gain a second quality layer
A form can look understandable to people while remaining ambiguous to agents. “Name” might mean a full name or surname. A date picker could represent departure, appointment start, or requested delivery. Required fields can exist technically without explaining their purpose clearly.
WebMCP forces developers to model that meaning precisely. Agents are not the only beneficiaries. Clearly defined inputs, states, and errors usually produce better human forms too: clearer labels, understandable confirmations, and fewer hidden assumptions.
3. Brand control and automation do not have to conflict
A natural concern is that the business loses control of the experience when an agent performs the task. WebMCP tries to avoid that outcome. The action still runs on the website and in its visible interface. The business defines the tool, process, and confirmation.
The agent does not invent its own order or enquiry process. It uses an intended route. That is preferable to a future in which external systems interpret interfaces independently and miss important restrictions, explanations, or brand decisions.
4. Accessibility and agent readiness share a foundation
WebMCP is not a substitute for accessibility. Both, however, reward the same foundations: semantic HTML, clear labels, dependable state, understandable errors, and predictable processes.
A website that only works visually is difficult for many people to use and fragile for agents. A website with sound structure is easier to operate, test, and extend. Businesses should therefore not begin with a separate WebMCP project. They should begin with a dependable web foundation.
The more important question: what may an agent do?
As soon as websites expose actions, a presentation question becomes a governance question. Not every action carries the same level of risk.
A product search changes nothing. Pre-filling a contact form is manageable when the user reviews it before sending. A booking, order, cancellation, or change to personal data needs clear boundaries and deliberate confirmation.
Chrome’s documentation explicitly notes that sensitive processes can require user interaction. This is not an inconvenient obstacle. It is a central trust mechanism. A sound agent workflow makes clear:
- which action has been prepared,
- which data will be used,
- what the confirmation will cause,
- whether costs or obligations arise,
- how failure and cancellation are handled.
Businesses should therefore ask more than, “Which tools can we provide?” The better question is, “Which tools create value without blurring responsibility and consent?”
Five requirements for an agent-ready website
1. Clear tasks instead of generic functions
A tool named submit explains very little. request_consultation, check_delivery_status, or open_support_case describes a business task. Good naming reduces misunderstanding and forces the business to define the purpose of a process.
2. Unambiguous inputs and outputs
Every field needs a clear meaning, expected format, and understandable limits. The result also needs to be explicit: was a draft created, or was the enquiry actually sent? Is there a reference number? Is another confirmation required?
3. Visible confirmation for consequential actions
The greater the effect, the less should happen silently. An agent can prepare, compare, and fill in information. For binding actions, the person should understand and confirm what will happen.
4. Reliable error handling
“Something went wrong” helps neither people nor agents. Errors should identify which input is missing, which state has expired, or which next step remains available. Structured errors are part of the interface, not decoration added later.
5. Observability and abuse protection
Businesses need to know which tools are used, where processes fail, and whether automated access exceeds acceptable boundaries. Permissions, rate limits, logging, and privacy belong in the architecture. A new interaction model without an operating model creates new blind spots.
What makes sense now — and what does not
Rebuilding every website immediately for an experimental standard would be premature. WebMCP is under active development, and its interfaces and browser support can change. A production project should state that clearly rather than pretending the standard is settled.
A review is useful now:
- Which tasks do visitors repeatedly complete through forms or multi-step interfaces?
- Where are labels, states, or confirmations already ambiguous?
- Which processes could an assistant prepare?
- Which actions always require human consent?
- Is the technical foundation stable enough for progressive enhancement?
For businesses with complex booking, support, application, or configuration flows, a limited prototype may also be worthwhile. It should answer a specific question rather than support a grand promise: does the agent understand the intended tools? Does the process remain visible to the user? Are errors and confirmations unambiguous?
What does not make sense is adding WebMCP hurriedly to every contact form. It would be equally wrong to neglect conventional APIs, semantic HTML, or accessible forms because a new standard is expected to solve every problem. WebMCP is an additional layer. It does not repair weak foundations automatically.
The opportunity cost of ignoring the development
The immediate cost is still low because WebMCP remains experimental. The strategic cost emerges later, when businesses discover that their website shows content but does not offer clearly modelled tasks.
Ambiguous forms, fragile state, and hard-to-test workflows then have to be rebuilt under time pressure. External agents are already interpreting the interface while the business has not defined its own rules for confirmation, permission, and logging. The website is being used, but not on the business’s terms.
Improving the foundation now is not a blind bet on one standard. Clear forms, semantic structure, stable state, and sound action boundaries remain valuable regardless of WebMCP. If the standard succeeds, the website is prepared. If it does not, the website is still better.
Conclusion: the next web interface is not only for people
WebMCP represents a plausible next step for the web. Websites are not only being read and summarized. AI assistants are beginning to operate them — currently through uncertain click simulation and potentially through tools that sites deliberately expose.
For businesses, the point is not to add another acronym to the technology list. It is to address a new quality question: can the website describe a task clearly enough that the person, agent, and business all expect the same result?
WebMCP is still a proposed standard in an experimental phase. The right response is neither dismissal nor blind action. It is to build digital processes clearly enough that they remain open to new forms of interaction.
If you want to assess which website workflows could be prepared for AI assistants, we can discuss structure, boundaries, and useful prototypes in an initial consultation with no obligation.
Lindwurm Digital GmbH — Web development and digital solutions.