In my last post, most of the approaches I covered for making sites agent ready were about helping agents read a site. MCP servers (which are not the same as WebMCP despite the confusingly similar name) let agents act too, but only for people who connect the server to their AI assistant, which is a big ask. For everyone else, an agent that needs to submit a form, book a time, or add something to a cart still has to find the parts of the page made for people and type into them, which often fails. I wrapped up by saying we’d look at WebMCP next, which aims to let any visitor’s agent use a site’s forms and actions directly in the browser, without having to install or connect anything extra.

By the way, if you’re new to this series on agent readiness, the first post covers what agent-ready means.

What WebMCP is

WebMCP is a way for a website to tell the AI agent in your browser what it can do on the page, and how. Today, if you ask your AI assistant to send a message through a site’s contact form, it has to look at the page the way a person would, find the right fields, and type into them. With WebMCP, the site offers the agent a short list of clear actions, like “send a message” or “search products,” each with a description of what it does and what information it needs. WebMCP calls these actions “tools.” The agent picks the tool it needs and fills in the details, and the site’s own code does the rest.

WebMCP already works in Chrome and Edge, though it’s still being tested. Chrome opened an origin trial in Chrome 149, and Edge is running one too. That means the feature works for real visitors, but only on sites that sign up and add a trial token to their pages, and only while the trial runs.

Even this early, Google is already looking at WebMCP as part of a healthy site: Lighthouse now checks to see if a page has WebMCP tools, and whether its forms are marked up for them.

Where WebMCP wins

WebMCP’s big advantage is that it brings the act side of agent readiness seamlessly into the browser, which is great because everyone already knows how to use a browser. It works inside the user’s tab and with their login, so there’s no separate server to build, no OAuth flow, and nothing extra to install or connect. This simplicity gives WebMCP an advantage over MCP.

WebMCP not only works inside the browser you already have, it also reuses what sites have built. Tools can be applied to a site’s existing search, cart, and form code with a few lines of JavaScript, or set up in the HTML by just adding two attributes to a form. In WordPress, where most forms come from a handful of plugins, one plugin update could turn millions of forms into tools. Elementor is a good example of that: we’re planning WebMCP support for actions in our Atomic Elements, starting with Atomic Forms, as we announced with the Elementor 4.4 beta.

Yet again, WordPress proves itself to be agent ready, because it already has much of the groundwork in place for WebMCP. The Abilities API, added in WordPress 6.9, gives WordPress, plugins, and themes one place to declare what they can do: each ability has a name, a description, a schema for its inputs and outputs, and a permission check tied to WordPress’s own user roles. Abilities are private by default, so a plugin marks the ones it wants agents to reach, and the same ability can be offered through the REST API or used by AI features inside the admin. Today the WordPress MCP Adapter plugin offers those abilities as MCP tools from the site itself, with no separate server to run, which is great for site owners and teams who want to connect their own assistant. An ability already has what a WebMCP tool needs (a name, a description, and an input schema), so the same declaration could also be registered as a WebMCP tool for visitors. That takes some new code, but it’s a relatively small step, because it wraps functionality the site already has instead of building a tool from scratch.

What’s still unsolved

Despite all this, WebMCP is still an experiment, and the open questions about it are real.

The API itself is still changing. Chrome’s and Edge’s origin trials both run until March 30, 2027, and the API has already changed once, moving from navigator.modelContext to document.modelContext. Anything you build on it now may need further updating before it becomes a standard. That’s a good reason to let a plugin or your platform handle it so you don’t have to keep on top of these types of updates.

Not every browser is on board, either. WebKit, the engine behind Safari, opposes WebMCP, citing privacy, security, API design, and duplication among its concerns, and Mozilla’s position is labeled neutral. Almost every browser on an iPhone runs on WebKit, including Chrome, so unless WebKit changes its position, a large chunk of mobile visitors won’t get WebMCP.

Agents also have to start using these tools for them to be relevant. A site can register tools today, but that doesn’t mean an agent will call them.

Security is the most challenging open question. A tool runs with the visitor’s login, so it can do anything the visitor can do, and a malicious page, or a piece of content like a review or comment, could try to trick an agent into calling a tool it shouldn’t. This is called prompt injection, and nobody has fully solved it for any kind of agent, WebMCP or otherwise. The spec lets a tool mark itself as read-only, or as having consequences that are significant or can’t be undone, but those labels are only hints, and it’s up to the browser and the agent to decide whether to follow them.

Trying it on your own site

There are two ways to add WebMCP tools to a page. The simpler one is to add toolname and tooldescription attributes to a form that’s already there, and Chrome turns the form into a tool, with the form’s fields as its inputs. For anything that isn’t a form, a site can register a tool with JavaScript. It calls document.modelContext.registerTool() with a name, a description, a JSON Schema for the inputs, and a function to run when an agent calls the tool.

Start with one form, like your search or contact form. Add the two attributes, turn on chrome://flags/#enable-webmcp-testing in Chrome, and check the tool in Chrome DevTools under Application. Because of the security concerns above, start with read-only tools, and keep anything that sends or buys behind a human confirmation. If you want real visitors to get it, register for the WebMCP origin trial and add the token to your pages. For now, this works best as an extra layer on top of your forms, and shouldn’t be the only way they can be used.

Where this is going

This is what agent readiness comes down to: making sure your site works well for both people and agents. Sites essentially need two layers: the visual page for people, and described tools and clean content for agents, served from the same URLs and the same code. Platforms will probably end up providing most of the second layer, the way they already provide sitemaps and feeds, so most site owners won’t build it by hand. At Elementor, we’re already starting to do this: Elementor 4.4, now in beta, adds a new Agent Ready menu with read-only WebMCP tools, llms.txt, and markdown versions of pages, all free. WebMCP is the strongest candidate for helping agents take actions, because of its simplicity for end users, and because the companies building the browser agents are the ones shipping it.

What isn’t clear is when agents will catch up: sites can already register tools in Chrome and Edge, but when will an agent in an ordinary person’s browser check for those tools before it starts reading the page?

In my next post, I’ll look at how this kind of agent readiness, for agents visiting your site, differs from agents that you and your team connect to work on your own site, and why the two often get confused.