Google's Agentic Browsing Lighthouse Scoring Factor: WebMCP and Registered Tools

Part 4 of the AI Visibility Series. The frontier. This is where your website stops being something an AI only reads, and starts being something an AI can actually use.

An honest note before we begin. Of the four pillars in this series, this is the one we at Graceful Web Studio have not built yet. The first three, a clean accessibility tree, a stable layout, and an llms.txt file, work today, and they are where we are putting our energy for clients right now. WebMCP is newer, it is still an experiment, and we are studying it closely rather than rushing it. We are sharing it because it is where the web is going, and we want you to see it coming.

I want to be straight with you. This is the one piece we have not built yet. We are getting the first three foundations right first, because they work today, and we are watching WebMCP closely as it grows. I would rather master what is ready now and bring you the next step when it is truly ready than hand you something half finished. This is where the web is heading, and we will be ready for it.

Crystal Scott, CPWA, founder of Graceful Web Studio

With that said, let me show you what is coming, in plain language.

Meet WebMCP

WebMCP is a proposed web standard from the Web Machine Learning Community Group. Its job is simple to say and powerful in practice. It lets your website hand an AI agent a set of clearly named tools, so the agent can complete a real task on your site instead of guessing its way through your page.

To understand why that matters, you need one word: actuation. Actuation is when an agent acts on your site the way a person would, clicking buttons and typing into fields on your visitor's behalf. Booking an appointment. Filling a form. Completing a purchase. Today, the agent does this by looking at your page and guessing. It sees a field, decides what it probably wants, and types something in. Every step is a guess, and every guess is a chance to get it wrong.

WebMCP replaces the guessing with declaring. Instead of the agent reverse-engineering your booking form field by field, your site simply says: here is a tool called book_appointment, here is exactly what it needs, here is what it does. The agent calls that one tool, and the task gets done. Google's own guidance is blunt about the difference. Declaring a tool is far more reliable than actuation, where each step is left open to the agent's interpretation.

Here is the part business owners care about most. WebMCP tools run visibly, right on your page. The agent is not working in some hidden back room. It is using your real booking form and your real checkout, in the open, so your customer can watch the task happen and trust that it was done right. Your brand and your design stay intact.

Why this is the next step after accessibility

If you have followed this series, this will feel familiar. In Part 1, we made your site readable to machines by giving every button and field an honest name in the accessibility tree. That is what lets an agent understand your page in the first place.

WebMCP is the next step up. Accessibility lets an agent read your form. WebMCP lets an agent run your form as a single, named action. One labels the parts. The other labels the whole job. A well-labeled form tells an agent what each field is. A WebMCP tool tells the agent what the form is for, and hands it a clean, reliable way to finish it.

This is why we keep saying the same thing all series long. The accessibility work you do for people is the same work that makes you legible to machines. WebMCP sits right on top of that foundation. You cannot bolt it onto a messy, unlabeled site and expect good results. You build it on a site that is already honest in its code, which is exactly the site the first three pillars create.

It is also why this is the fourth pillar and not the first. Get the foundation right, and this becomes a natural next step. Skip the foundation, and this is just a fragile shortcut.

What a well-built tool looks like

A WebMCP tool is not complicated in spirit. It is a clear promise: here is an action my site can do, here is what it needs from you, and here is what you get back. The Chrome team's best practices come down to naming things well and describing them clearly. Here is what goes into a good one.

There are two ways to add these tools, and the names tell you most of what you need to know.

The declarative API is the simpler one. You add two attributes, toolname and tooldescription, directly to a normal HTML form. No new code, just labels on the form you already have. For a business like Riverside Dental, a booking form could become a tool like this:

<form toolname="book_appointment"
     tooldescription="Book a dental appointment. Collects the patient's name, phone number, preferred date, and reason for the visit.">
 ... your normal name, phone, date, and message fields ...
</form>

The imperative API is the powerful one. You use JavaScript to register a tool with navigator.modelContext.registerTool, which lets you build tools for things a plain form cannot do, like a custom date picker, a multi-step flow, or a change to the state of the page. More control, and more code.

For most small businesses, the declarative path is the realistic starting point, because it rides on the forms you already have.

How to check your own site

Here is the honest truth about checking this one, and it is different from the first three pillars. The accessibility tree, layout stability, and llms.txt all run in regular, up to date Chrome and in PageSpeed Insights. WebMCP does not, yet. Because it is still an origin trial, you have to switch it on before any of it works.

To turn it on for local testing, open Chrome, go to chrome://flags/#enable-webmcp-testing, set it to Enabled, and relaunch. To run it on a live site, you register for the WebMCP origin trial, which is available from Chrome 149. Once it is on, the Lighthouse agentic browsing category includes a set of WebMCP checks, and the tools below help you see and test what you have built.

How to handle it in Webflow

Good news and a caveat for Webflow users. The good news is that the simplest version of WebMCP fits Webflow surprisingly well. The declarative API is just two attributes on a form, and Webflow already lets you add custom attributes to any element in the Designer. So in principle, you can add toolname and tooldescription to a Webflow form without writing a single line of code.

The caveat is everything around it. You still need the origin trial turned on, which means adding the trial token to your site's head code. The imperative API needs real custom JavaScript. And because the standard is still changing, anything you build today may need to be redone tomorrow. So the Webflow path exists, but it is for experimenting, not for shipping a finished feature to every client.

Here is the order we recommend, and the order we are following ourselves. Get your accessibility tree clean. Get your layout stable. Add a well-formed llms.txt. Those three are ready now, they help you today, and they are the foundation WebMCP needs. When WebMCP settles and leaves the experimental stage, the sites that did this groundwork will be the easiest to upgrade. That is the kind of forward planning we build into ongoing maintenance for the clients we look after.

Four myths worth retiring

• “This is just SEO with extra steps.” No. SEO and llms.txt help an agent find you and read you. WebMCP helps an agent do something on your site, like book or buy, without guessing. Finding you and acting for you are two different jobs.
• “If my forms are accessible, I do not need WebMCP.” Accessibility gets you most of the way, because a well-labeled form is already readable. WebMCP goes one step further and names the whole action as a single tool, so the agent does not have to piece your form together field by field. It builds on accessibility, it does not replace it.
• “I have to rebuild my site for this.” No. WebMCP is a progressive enhancement. You add it on top of the site you already have, one tool at a time, starting with your single most important action.
• “It is locked in, and I am already behind.” No. WebMCP is a proposed standard, still in an origin trial, and still openly changing. Nobody is behind. The smart move is to get the first three foundations right now, because they work today, and add WebMCP when it settles.

The bottom line

WebMCP is a real glimpse of where the web is going. Soon, getting found by an agent will not be the finish line. Getting the job done by an agent will be. The sites that win will be the ones an agent can not only read, but trust to act on.

You do not need to chase that today. You need to build the foundation that makes it possible: a site that is honest in its code, stable on the screen, and clear about what it offers. Do that, and when WebMCP grows up, you are not starting over. You are one small step away.

That is not a trend. That is just good building.

See where your site stands

WebMCP is the horizon. The first three pillars are what move the needle today, and that is where a good audit starts. Get a free AI Visibility Report from certified accessibility and Webflow specialists. We will manually check how your business shows up when people ask Claude for a recommendation, then explain your new Lighthouse agentic browsing scores in clear, plain language. You get a personalized report within 24 hours. No sales pitch, just value.

Request yours at gracefulwebstudio.com/ai-visibility-report.

This is the final piece of the AI Visibility Series. If you are just arriving, start at the beginning and build in order:

• Part 1: The well-formed accessibility tree, the machine-eye view of your site.
• Part 2: Layout stability, why a jumpy page fails people and agents.
• Part 3: The llms.txt file, the honest truth about whether you need one.

Written by Crystal Scott, Certified Professional in Web Accessibility (CPWA), Certified Webflow expert and founder of Graceful Web Studio.