Guide 16 · Agents

WebMCP on WordPress: a working example, and what Lighthouse agentic browsing checks

By Alauddin Chowdhury · Updated 21 October 2026

Mostly yes, if your forms have real labels, your buttons are real buttons and nothing jumps while the page loads: that is what Lighthouse can score today. AI agents are starting to use websites for people: they fill in forms, run tools and read results. Lighthouse now has an Agentic browsing category that checks whether a page is ready for that, and Chrome is testing WebMCP, a way for a site to hand agents named tools instead of making them guess at buttons. We built both into this site and measured it before and after. Our contact page went from 3 of 3 checks, with the WebMCP audits not applicable, to 5 of 5. Here is what the audit checks, what it cost us, and what it does not tell you.

What does “agent-ready” mean for a website?

An agent is software that acts in a browser for someone: it opens your page, reads it, and tries to do a task, such as checking a plugin or sending a contact form. Today most agents do this the hard way. They read the page’s accessibility tree, guess which field is which, click, and hope the layout does not move under them.

Being agent-ready means two things. First, the page is easy to operate without eyes: every field has a real label, every button is a real button, and nothing jumps around while it loads. Second, and newer, the page can say outright what it can do. That second part is what WebMCP is for. Chrome describes it as a proposed web standard for exposing structured tools to AI agents. It is experimental and runs as an origin trial from Chrome 149.

What does Lighthouse’s Agentic browsing category check?

The category shows a fraction, such as 4/4, rather than a 0–100 score. Google’s documentation says that is deliberate, because the standards are still emerging and the aim is to give signals, not a ranking. It needs Chrome 150 or later, and the WebMCP checks only run when the page is registered for the origin trial. On our pages it ran these checks:

One of those needs a note. Lighthouse checks llms.txt here, but Google Search ignores llms.txt, and we found no evidence that it changes AI answers. It is in this category because agents may read it, not because it helps you rank. What our llms.txt test found.

What did our pages score before and after?

Before building anything we checked our three forms (contact, the retrievability check and the leaderboard search). All three already had labels tied to their fields and real buttons, so /contact/ passed the three checks that could run: accessibility tree, layout shift and llms.txt. The WebMCP audits showed as not applicable.

We then added three WebMCP tools and registered the site for the origin trial. The re-run on 25 September 2026:

Accessibility, Best Practices and SEO scored 98 to 100 on every page. The WebMCP schema check passed everywhere, and form coverage passed on /contact/, the one page where it was scored. Performance stayed in the mid-90s on mobile: the tools are one small script.

How do you give an agent a tool?

WebMCP has two routes, and we used both.

• Declarative, for an existing form. You add attributes to a normal HTML form: toolname and tooldescription on the form, and toolparamdescription on each field. That is how our contact form became the tool request_free_ai_visibility_check.
• Imperative, for anything else. A script calls document.modelContext.registerTool with a name, a description, an input schema and a function. Our check_plugin_retrievability tool is registered this way on every page, and lookup_plugin_ai_answers only where the leaderboard search exists.

Lighthouse still flags the retrievability and leaderboard forms as “missing annotations”. We left them that way on purpose. Those forms are already covered by the script tools, and annotating them too would show an agent the same action twice under two names.

WebMCP example: the registerTool code we run

Here is the imperative half, trimmed to the parts that matter. It ships in a small WordPress plugin that loads one deferred script on every page. The live version also drives the on-page form when one exists; this version only calls the REST route behind it.

var mc = document.modelContext || navigator.modelContext;
if (mc && typeof mc.registerTool === 'function') {
  mc.registerTool({
    name: 'check_plugin_retrievability',
    description: 'Check whether AI search crawlers (OAI-SearchBot, PerplexityBot, Claude-SearchBot, Googlebot, bingbot) can reach the website of a WordPress plugin. Takes the plugin\'s wordpress.org slug.',
    inputSchema: {
      type: 'object',
      properties: {
        slug: { type: 'string', description: 'The plugin slug from its wordpress.org URL, for example "wp-rocket".' }
      },
      required: ['slug']
    },
    annotations: { readOnlyHint: true, untrustedContentHint: true },
    execute: async function (input) {
      var res = await fetch('/wp-json/softrecs/v1/check', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ slug: input.slug })
      });
      return JSON.stringify(await res.json());
    }
  });
}

Three choices are worth copying. The tools are read-only and say so with readOnlyHint, so an agent can call them without stopping to ask the user. The contact form has no toolautosubmit, so an agent can fill it in but a person still presses send. And the feature check comes first: WebMCP only exists in Chrome while the origin trial runs (our token is valid until 17 November 2026), so in every other browser the script does nothing.

How do you add WebMCP to a WordPress site?

1. Put the code in a small plugin, not the theme, so a mistake cannot take the site down.
2. Enqueue one script on wp_enqueue_scripts with the defer strategy, so it never blocks rendering.
3. Register one tool per action a visitor can take, and point each execute function at a REST route you already have.
4. Mark read-only tools with readOnlyHint, and leave toolautosubmit off on any form that sends something.
5. Register your origin for the WebMCP origin trial, print the token in a meta tag, then check the page in Lighthouse’s Agentic browsing category.

What should you not hand to an agent?

Anything a person should confirm. The declarative API has a toolautosubmit attribute that lets the agent send the form by itself. Without it, the agent fills the form and the person clicks Submit. We did not add it to our contact form: an agent can prepare the request, but a human sends it. Our two script tools only read data, so there is nothing for them to break.

For a plugin business the same rule applies to checkout, licence activation, refunds and account changes. Chrome’s documentation says sensitive actions such as purchases can ask the user for confirmation. Start with read-only tools: a compatibility checker, a pricing calculator, a documentation search.

Does any of this help your plugin get cited by AI?

Not that anyone has shown. Google has not said the Agentic browsing results feed Search rankings, and its own documentation calls the category experimental. In our 17 September measurement this site was cited in zero of 72 unbranded AI answers, and we would not claim that tools will change it.

What it does change is what happens after the citation. If an agent is sent to your site to check whether your plugin fits, a site with a working tool gives it a straight answer. A site without one leaves it scraping your pricing page. Agents doing that at scale are early, and the WebMCP trial ends in November 2026 unless Chrome extends it. So we treat this as cheap preparation, not a growth channel.

What should a plugin site do first?

1. Run PageSpeed Insights on your pricing, contact and trial pages and read the Agentic browsing section. Fix any accessibility tree failure first: it is the same fix that helps screen-reader users.
2. Keep layout shift under 0.1, especially around buttons.
3. Give every form field a real label and every action a real button, not a styled div.
4. If you have a free tool or a search, register it as a read-only WebMCP tool, then register your origin for the trial so Lighthouse can check the schema.
5. Leave anything that spends money or changes an account for the person to confirm.

How this was made: WebMCP and Lighthouse details come from Chrome’s developer documentation on WebMCP, its declarative API and Agentic browsing scoring, read on 25 September 2026. Scores come from PageSpeed Insights runs on this site on 24 and 25 September 2026, and tool registration was checked in Chrome 153. Drafted with an AI assistant (Claude) and reviewed by Alauddin Chowdhury. Method and AI use.

---

Want to know how your plugin shows up across all three engines?

Send me your wordpress.org slug. I will run your category on Google AI Mode, ChatGPT and Perplexity, and show you which domains each engine reads and whether yours is one of them. Free, no call, usually within a day.