WebMCP: How to Make Your Site Ready for AI Agents

TL;DR WebMCP is a browser standard that lets AI agents use your website directly, calling its features instead of clicking around like a person. It is a joint Chrome and Edge effort, accepted by a W3C community group in September 2025, and it is in early preview in Chrome behind a flag. Native support is targeted for the second half of 2026. The one move to make now: get your site cited in AI answers first, because an agent only arrives if the AI sends it.

Agents are starting to act, not just read

AI agents are starting to act on websites, not just read them. They book, buy, fill forms and complete tasks on a user's behalf. The problem: a site built for human eyes and clicks is hard for an agent to operate. It has to guess what your buttons do.

WebMCP fixes that by letting your site tell an agent what it can do, in plain, structured terms. Think of it as a menu of actions an agent can call directly. This guide covers what WebMCP is, why Google and Microsoft are pushing it, and how to get your site ready, without betting your roadmap on a preview spec.

What WebMCP actually is

WebMCP is a browser-native API that lets a website publish a structured list of actions an AI agent can call. The browser exposes it through navigator.modelContext. Instead of an agent scanning your page and guessing which button books a flight, your site hands it a clear contract: here are my tools, here is what each one does, here are the inputs it needs.

Take a flight-booking site. Without WebMCP, an agent has to find the search form, identify each field, fill them, and hunt for the right button, and it breaks the moment you change the layout. With WebMCP, the site exposes a bookFlight() tool with clear parameters like origin, destination and date. The agent calls it directly. No guessing, no fragile screen-scraping. That published set of actions is the tool contract, and it is the core idea behind WebMCP.

WebMCP vs MCP

If you have heard of MCP, the Model Context Protocol, WebMCP is related but not the same. MCP runs as a separate server that an AI connects to, often to reach back-end systems and data. WebMCP runs inside the browser tab and inherits the user's logged-in session. That session point matters: the agent acts as the signed-in user, with their permissions, on the live page in front of them. The two are complementary. MCP connects models to servers; WebMCP connects them to the page.

Why Google and Microsoft are behind it

WebMCP is not a single vendor's side project. It is a joint Chrome and Edge effort, developed under the W3C Web Machine Learning Community Group, which accepted the spec in September 2025. An early preview shipped behind a flag in Chrome 146. Native support across Chrome and Edge is targeted for the second half of 2026.

Why the two biggest browser makers care: agents are becoming a primary way people get things done online, and both want the web to stay the platform where that happens, rather than ceding it to closed app ecosystems. A shared standard means a site builds once and works with any compliant agent.

How it works

WebMCP rests on three ideas.

• Discovery. The page advertises which tools it exposes, so an agent can find out what it can do without scraping the UI.
• JSON schemas. Each tool declares the inputs it expects and the outputs it returns, in a structured schema. The agent knows exactly how to call it and what it will get back.
• State. Tools appear and disappear as the page changes. A checkout tool shows up when there is something in the cart, not before. The contract reflects what is actually possible right now.

There are two ways to build it. The imperative API uses registerTool through navigator.modelContext, where you define tools in JavaScript with their parameters and logic. The declarative API is lighter: you add toolname and tooldescription attributes to existing HTML forms, turning forms you already have into agent-callable tools. Start declarative for speed, go imperative for control.

Why it beats the current options

Why not just let agents click around, or build an API? Both options fall short.

UI automation, where an agent drives the screen like a person, is fragile. It breaks the moment a button moves or a class name changes. Public APIs are better but rare, and they often miss the UI-driven flows real users rely on. WebMCP is the middle ground: structured like an API, but tied to the live page and the user's session.

	Without WebMCP	With WebMCP
How agents act	Guess from the screen or scrape the UI	Call published tools directly
Reliability	Breaks when layout or class names change	Stable contract, independent of layout
Coverage	Limited to what an API exposes, if any	Covers the live, session-based flows users actually use
Setup	Custom scripting per site, or a separate API	Annotate forms or register tools in the page

What this means for SEO and GEO

Here is the honest take, and it changes how you should prioritise. Agents do not start at your site. They start at an LLM's answer. The user asks an assistant, the assistant picks a source, and only then does an agent act. If you are not cited in that answer, the agent never arrives at your site, and your WebMCP tools never get called.

So AI visibility is the prerequisite, not the nice-to-have. Being cited comes first; being usable comes second. WebMCP is the execution layer that sits on top of visibility work. Get cited in AI search, then make sure that when an agent lands, it can actually do something. The order matters: cited first, usable second.

How to make your site agent-ready

You do not need to rebuild anything. Work incrementally.

• Annotate existing forms. Add declarative toolname and tooldescription attributes to forms you already have. This is the fastest way to expose real actions.
• Register your key actions as tools. For the handful of things that matter most, like search, booking or checkout, define them with the imperative API for full control.
• Publish a manifest and llms.txt. A /.well-known/webmcp.json manifest tells agents what your site exposes. An llms.txt tells AI crawlers what your site is about. Together they make you discoverable to both.
• Run the Lighthouse agentic-browsing audit. Chrome Canary ships a new Lighthouse audit that reports what an agent would find on your page. It is the readiness check: run it and fix what it flags.

If touching every page is not realistic, there is an edge option: a Cloudflare Worker can inject the discovery layer for you, so you add agent-readiness without rewriting the site.

Platform reality check

How you implement WebMCP depends on what you built on. On a visual builder like Webflow, you are mostly limited to the declarative path: form attributes and custom code embeds, plus Webflow's own MCP server for its data. On a Vercel and Next.js build, you have full control to register tools in code, define complex parameters and wire them to your logic. Neither is wrong; they are different ceilings. Our Webflow vs Vercel SEO guide and Next.js SEO guide posts go deeper on each.

Experiment now, but mind the caveats

WebMCP is worth experimenting with now. It is not worth betting your roadmap on yet. It is a preview spec, and one caveat stands out: cross-tab isolation is still immature, so hold off on high-trust flows like payments and banking until the security model matures. Annotate a few forms, run the Lighthouse audit, and learn how agents see your site. Keep the high-stakes actions manual for now.

Want to know whether your site is ready for AI agents and AI search? We can assess it. We will check your AI visibility first, since that is what brings the agent, then your WebMCP readiness, and tell you what to do next. For the visibility groundwork, see our JavaScript SEO guide.

Frequently asked questions

What is WebMCP?

WebMCP is a browser-native standard that lets a website publish a structured list of actions an AI agent can call directly, through the navigator.modelContext API. Instead of guessing from the screen, an agent reads the site's tool contract and calls actions like search or checkout straight away.

Is WebMCP the same as MCP (Model Context Protocol)?

No, but they are related. MCP runs as a separate server that connects AI to back-end systems. WebMCP runs inside the browser tab and inherits the user's logged-in session, so the agent acts as the signed-in user on the live page. They are complementary, not the same thing.

Who created WebMCP, and is it a real standard?

It is a joint Chrome and Edge effort developed under the W3C Web Machine Learning Community Group, which accepted the spec in September 2025. So it is a genuine standards-track effort backed by Google and Microsoft, not a single-vendor experiment.

Can I use WebMCP today?

Partly. An early preview shipped behind a flag in Chrome 146, and native support across Chrome and Edge is targeted for the second half of 2026. You can experiment now by annotating forms and running the Lighthouse agentic-browsing audit, but treat it as a preview, not production.

Does WebMCP replace SEO?

No. It sits on top of it. Agents start from an AI answer, so if you are not cited there, the agent never reaches your site. AI visibility comes first; WebMCP is the execution layer that makes your site usable once an agent arrives.

How do I make my website ready for AI agents?

Annotate existing forms with declarative attributes, register your key actions as tools, publish a /.well-known/webmcp.json manifest and an llms.txt, and run the Lighthouse agentic-browsing audit in Chrome Canary to see what an agent would find. Teams that cannot touch every page can use a Cloudflare Worker to inject the discovery layer.

Is WebMCP safe enough for payments or banking?

Not yet. It is an early preview, and cross-tab isolation is still immature. Hold off on high-trust flows like payments and banking until the security model matures. Experiment with low-risk actions for now and keep the high-stakes ones manual.