Google has moved WebMCP into a Chrome origin trial, starting with Chrome 149. Websites are being asked to expose actions and context in a way browser agents can understand.
The keyword is agent-ready websites. Not websites that paste an AI chatbot on top. The idea is a page that tells an agent what can be done here and what inputs are needed.
Chrome's WebMCP docs describe it as a proposed web standard for exposing structured tools to AI agents. A site can use JavaScript tools or annotated forms so an agent does not have to guess what a field, button, or flow means. That is the shift. If browser agents become normal, a website's UI is no longer only for humans. It may also need a machine-readable action layer.
What WebMCP actually does
Today, many agents act like impatient users. They inspect the page, infer meaning from labels and layout, then click through the interface. That gets fragile when forms are long, state changes are slow, or checkout logic hides behind client-side code.
WebMCP gives the page a way to register tools through discovery, JSON Schemas, and state.
Discovery lets an agent see tools such as search, filter results, or start checkout. JSON Schemas define inputs and outputs. State tells the agent what is currently available.
Google is supporting two paths. The Declarative API turns HTML forms into tools with annotations. The Imperative API uses JavaScript for actions such as form input, page state management, or custom site logic.
For developers, the boring version is the useful one: WebMCP is a bridge between UI and intent. It asks you to name the things your app already does.
Why this matters for real websites
The first obvious use case is structured forms. A human can often tell whether a form wants a full name or separate first and last names. An agent may not. WebMCP lets the site describe that clearly.
Google also mentions support flows, travel booking, ecommerce, and debugging tools. I would add admin dashboards and settings screens.
This matches a wider pattern I wrote about in Cloudflare temporary accounts and AI agents: platforms are starting to design for agent-run work instead of pretending agents are just unusual human users.
The win is fewer brittle clicks. A travel site could expose a tool for multi-city search instead of forcing an agent to operate each control one by one.
That is the real promise of agent-ready websites: fewer guesses, clearer permissions, and better user review before sensitive actions happen.
Do not treat this as fully baked
This is still early. Chrome calls WebMCP a proposed standard, not a settled web platform feature. The origin trial exists so developers can test the API with real users and send feedback before the shape hardens.
There are real limits. Chrome's docs say WebMCP needs a browsing context because tool calls are handled in JavaScript. Tools are discoverable only after a browser visits the site.
There are also browser support questions. Google wants an API that any browser with agentic capabilities can implement, but the current testing path is Chrome-specific. Treat WebMCP as a progressive addition, not the only way your site works.
If you build it now, keep the human UI complete. Treat WebMCP like structured metadata for action, not a replacement for accessible forms.
The security part is not optional
A website tool is not harmless just because an agent calls it. If a tool can read user data, change settings, submit a form, or start payment, it needs the same care as any product surface.
Chrome's security guidance calls out indirect prompt injection, where hostile or untrusted text tries to influence the agent through content it reads. Google is direct here: model-level safety cannot be guaranteed.
WebMCP includes hints that help agents reason about tools. Use readOnlyHint for tools that do not change state. Use untrustedContentHint when a tool returns user-generated or external content. Expose tools only to origins you trust.
For sensitive actions, user confirmation should stay visible and boring. As with passkeys replacing passwords, better flows still need user trust, clear prompts, and recovery plans.
A small checklist before adding WebMCP
Start by listing user tasks, not UI elements. "Submit expense report" is better than "click blue button."
Keep tools narrow. Chrome's best practices recommend one function per tool and warn that overlapping tools make selection harder for agents.
Prefer clear names. A tool named create_event should create the event. A tool named start_event_creation should only start the flow.
Validate in code, not only in schema. Schemas help, but they are not a security boundary. Your backend and frontend logic still need to reject bad input.
Test the tool alone, then test the full journey. Chrome's eval guidance says teams should test tool state, call order, arguments, and UI updates.
My read
WebMCP is not a reason to redesign every site this week. It is a signal that the browser may become an agent runtime, and that websites will need cleaner action surfaces.
If you run a web app, WebMCP is worth prototyping around one painful flow: support, checkout, booking, onboarding, or settings. Do not ship an agent path you cannot observe, test, or roll back.
Agent-ready websites are coming into view. The smart move is careful experiments where agents currently guess too much.
Sources
- Chrome for Developers: Join the WebMCP origin trial
- Chrome for Developers: WebMCP documentation
- Chrome for Developers: WebMCP best practices
- Chrome for Developers: WebMCP tool security
- LogRocket: How to make your website agent-ready with Google's Web MCP
