AI agents are beginning to use websites on behalf of people.

But those sites were built for humans. Agents don't handle visual layouts well, so they have to guess how to interact with the site, which is slow and error-prone.

WebMCP changes that by letting your site give agents a defined set of tools they can use directly.

It's early days, though. So you can ship tools before your competitors have looked at them. More on why that matters later.

This article covers what WebMCP is, how it works, how it differs from "traditional MCP," and how to implement it on your website to ensure you're prepared for the agentic era.

WebMCP (Web Model Context Protocol) is a proposed open web standard co-authored by Google and Microsoft. It's a way for your website to expose structured tools that AI agents can call, like "search products," "book a table," or "start checkout."

In the context of WebMCP, a tool isn’t a separate piece of software, a plug-in, or a new backend database. It is a small set of instructions added via simple HTML attributes or a few lines of JavaScript that are attached directly to existing elements of your webpage, like a checkout form or search bar.

These tools exist entirely in the front-end code delivered to the user’s browser and only exist while that specific web page is open and active. You are essentially adding invisible labels to your site’s existing buttons and forms that tell AI what to do and what data they need to complete actions on a user’s behalf. And since the tools sit on top of the site you already have, there's no rebuild needed or separate backend to maintain. 

Right now, most browser agents read a page by simulating how a person would, taking screenshots to try and identify potential actions, and reading the Document Object Model (DOM) and accessibility tree. As you can imagine, this is time-consuming, and the results are inconsistent.

WebMCP gives agents a faster, more reliable path. When a tool exists, the agent can call it directly, and when one doesn't, it can still fall back on the old method, so adding tools doesn't lock you into anything.

People tend to frame these two as competing standards, but they solve different problems and actually complement each other.

"Traditional MCP" works best when the value is in backend data and systems, like Moz data, Salesforce, or an internal database. Setting one up is real work, though, because you're building and running a server.

WebMCP fits the rest of the web, the places where people complete actions instead of pulling raw data, which covers everything from airlines and restaurants to e-commerce stores and SaaS signups.

Here’s a side-by-side comparison of WebMCP vs. MCP:

Plenty of organizations will end up using both, with MCP handling the backend work and WebMCP the on-page work. They even share the same building blocks, such as a name, description, input schema, and a handler.

Agents have started actually using websites, not just reading them. They'll book a table or run a checkout for you, and WebMCP is how you help them take those actions. Which means those actions fall within your scope as an SEO.

Keeping sites readable to machines through clean structure, solid markup, and structured data is already part of your job. WebMCP applies those same skills, telling an agent what your page can do and how to trigger it.

Remember, this is separate from showing up in AI-generated answers. That's discovery, and it's what AI search optimization covers.

WebMCP kicks in once the agent is on your page. And getting it there counts for nothing if it can't take action when it’s there. If the agent has to screenshot your booking form and fumble through checkout, the sale falls apart on the last step.

Get it right, though, and the payoff runs both ways:

Some common uses for WebMCP tools:

• E-commerce: search products, filter by size or price, add to cart, start checkout
• Travel and hospitality: book a table, room, or flight from one request
• SaaS: start a signup, choose a plan, or run an in-app action
• Local and professional services: request a quote or book an appointment
• Lead gen and publishing: newsletter signups and contact forms

Personally? I'm most excited to stop clicking through filter after filter on faceted navigation when I shop. Just tell the agent what I want and let it sort through the options.

In short, an agent comes to your website, discovers what WebMCP tools you offer, reads what each one does, and calls the one that fits the task.

There are two ways to set this up: HTML for forms or JavaScript for more complex uses.

Remember, these tools only work while the page is open; there's no headless or background mode, and the browser has to keep running.

Declarative API (HTML)

The declarative API is the easier implementation, meant for actions that already live in a form. For example, a reservation, signup, or contact request.

To implement this, you simply need to add a couple of attributes to the form you already have:

• toolname gives the tool a name
• tooldescription explains what it does
• toolparamdescription, optional, and tells the agent what that field expects

From there, the browser turns the form into a tool. By default, only your own site can use it.

To see the declarative API in action, I loaded Google's Le Petit Bistro demo with the Model Context Tool Inspector open. It’s a Chrome extension that lists the tools a page has registered and lets you enter a prompt and watch its Gemini-powered test agent call them.

Just a heads up, you’ll need a Gemini API key for this (you can use the free tier).

The demo is a restaurant reservation page with one booking form. The fields include name, phone number, date and time, etc.

Sure enough, the form showed up in the Inspector as a registered tool, complete with its schema. The panel shows exactly which WebMCP tools an agent can see on a site.

The tool is in the Inspector because of a handful of attributes on the demo's existing form, which is all the declarative API requires. Here’s what the HTML looks like from the Elements Panel in DevTools. I’ve drawn arrows to the attributes enabling WebMCP.

I wrote a prompt in the Inspector, executed the tool, and watched the form on the page fill itself in, field by field.

My prompt was: “Book a reservation for June 15, 2026, at 7:00 PM. There will be four guests for a birthday party. The name is Matt Hollingshead, and phone number is 123-555-5555.”

I manually clicked “Request Reservation” and got a confirmation page.

Your form’s existing validation still applies, too. The bistro form already requires a name, a 10-digit phone number, and a future date and time. An agent has to meet those same rules.

If agents send invalid data, the form rejects it the same way it would for a person. You don’t have to build a separate set of guardrails just for agents.

I refreshed the page and entered the prompt again, but this time I didn’t provide a phone number. The agent recognized the missing information and asked me to provide it.

The form stayed visible the whole time, and submitting was still up to me. That default carries over when an agent runs the tool. The user watches the form fill in and reviews it before anything goes through, and your design and branding stay in view.

Imperative API (JavaScript)

Use this JavaScript approach, called the imperative API, when the action isn't a form, or your tools need to change based on what's on the page.

Take a SaaS dashboard. A tool that reads the user's account state back to the agent has nothing to submit, so a form can't do it. And an "upgrade plan" tool only makes sense for free-tier users.

You register each tool with document.modelContext.registerTool, giving it a name, description, input schema, and a function that runs when the agent calls it.

In exchange for writing JavaScript, tools can come and go with the state of the page, so a checkout tool might exist only while the cart has something in it.

I opened Google's travel-booking demo, a flight search app built with React. On the search page, the Inspector listed a single tool, searchFlights, which kicks off a search using structured inputs like origin, destination, date, and passengers.

Now, if I check the Sources panel in DevTools, you can see that the app registered the searchFlights tool with its description and inputSchema.

In the Inspector’s User Prompt field, I entered: “Find me round-trip flights for two passengers from New York to London departing on July 10, 2026, and returning on July 20, 2026.”

The Gemini agent read the request and called searchFlights. When the results came back, the page registered three more tools, and the Inspector updated to show searchFlights again, along with listFlights to read back what’s on screen, setFilters to narrow results by price, airline, or time, and resetFilters to clear those filters.

Those tools appear only after results are available because there was nothing to list or filter until the search returned data.

The site provides the tools, but the agent decides which to call and in what order. From my one prompt, the Gemini test agent worked through the request using these tools:

1. searchFlights with the route and dates
2. setFilters to narrow the results
3. listFlights to read the results back

It didn’t use resetFilters because that wasn’t necessary for the agent’s task this time. 

An agent in someone's browser would do the same from a single request, choosing the calls itself, without having to take a screenshot or guess which dropdown is the filter.

The same pattern covers single-page app flows, filtered result lists, multi-step bookings, and anything that isn't a plain form.

Before implementing WebMCP, I'd suggest trying some of Google's WebMCP demos to get familiar with them. Then, follow these steps to add the tools to your site.

Step 1: Audit your site for agent-friendly actions

Start by listing the top three to five actions people come to your site to take, like booking a service, buying a product, searching a catalog, or subscribing to a newsletter. The best fits are standalone actions with inputs you can define clearly, and that a user would want an agent to complete for them.

From that shortlist, pick one simple action to start with, like a search widget, contact form, or newsletter signup. Save complex, higher-risk flows like checkout until you've got a simpler one working first.

Step 2: Write and test your first tool

HTML forms are the easiest place to start, since you can modify existing forms without recreating them. As in the demo walkthrough above, you can add these attributes:

• toolname — the identifier an agent uses to call the action, kept short with no spaces, like toolname="search_products".
• tooldescription — a plain-language sentence telling the agent what the action does and when to use it, like tooldescription="Search the catalog by keyword".
• toolparamdescription — added to each input so the agent knows what value that field expects, like toolparamdescription="The search term, e.g. red shoes".

Then test it. Turn on the WebMCP flag in Chrome at chrome://flags/#enable-webmcp-testing and select enable WebMCP for testing. Next, install the Model Context Tool Inspector, and enter a prompt to see whether the agent picks your tool and fills the arguments correctly.

If the agent gets something wrong, it’s usually your description or schema, not the agent itself. The Inspector’s Copy trace button exports the full session as JSON, so you can see exactly what the agent called.

From there, adjust and retest until it’s reliable.

Step 3: Secure the tools you expose

Adding tools comes with responsibility. When an agent uses your tools, it’s acting on your user’s behalf, and it can’t reliably tell the difference between content you meant to display and an instruction to act on.

This is a form of prompt injection. If malicious text reaches the agent through your tools(most likely inside third-party content that a tool returns, like reviews or comments), it can be tricked into acting against your user.

A few protections to add:

• When you define a tool in JavaScript, add a readOnlyHint to tools that only read data, like a search or list. Agents assume a tool changes something unless told otherwise, so flagging the read-only ones cuts out needless confirmation prompts.
• Also in the tool definition, add an untrustedContentHint to any tool that returns user-generated or outside content, like reviews or comments, so the agent treats that text with suspicion rather than as instructions.
• On a form, leave toolautosubmit off for anything critical, like bookings, purchases, or account changes. Having this on lets the agent submit without the user clicking submit, which removes the human check. With it off (the default), a person always reviews and confirms.

Handling this is a normal part of exposing tools to agents, the same way sanitizing user input is a normal part of building forms. 

Step 4: Ship it while it's early

Once your tools work in the Inspector, you can put them in front of real visitors. Because WebMCP is still being finalized, Chrome rolls it out through a time-limited trial you opt into, which lets you register your domain and serve tools on your live site rather than testing only on your own machine.

Remember that the agents that can actually use those tools are still limited today. Treat this less as a traffic source for now and more as staking out early ground before it’s picked up by the masses.

Start with the low-risk tools you built first, and check Chrome’s WebMCP documentation for the current way to enroll and which browsers and agents currently support it.

If you were doing SEO during the mobile shift, you'll remember how it went. Going mobile-friendly felt optional for years, right up until Google made it a ranking factor, and the sites that prepared early were glad they did.

WebMCP sits at a similar moment, where sites can ship it, but most haven't moved yet.

The sites that move early will be the ones that actually work when someone's agent shows up to book, buy, or sign up, while everyone else's site fails on the last step.