This is a submission for the Google I/O Writing Challenge

A 100-line recipe for making a React site agent-ready, with the diff, the new Lighthouse Agentic Browsing audit results, and what is coming next.

1. The hook

At Google I/O 2026, Matias mentioned, on the way to a different demo, that Google's Modern Web Guidance lifts coding-agent pass rates on web-development tasks by 37 percentage points versus unguided coding. He said it once and moved on, but the number stuck with me. Underneath that single statistic is the most actionable web-platform shift of the year: the "agent-ready web." I wanted to know what it actually takes to make a real site agent-ready, so I built a small React demo, added three new files plus a handful of HTML attributes, and ran the new Lighthouse Agentic Browsing audit.

About a hundred lines of code, 3 of 3 on Agentic Browsing, accessibility score still 100. Here is the recipe.

2. The four pieces

Four pieces of the agent-ready stack are worth knowing by name:

• WebMCP. A proposed browser standard that lets your site expose typed tools to AI agents. The producer-side API ships in the Chrome 149 origin trial.
• llms.txt. A Markdown site map for models, served at the site root.
• Declarative form metadata. Standard HTML5 autocomplete (in the spec since 2014), ARIA roles and labels, and the new WebMCP attributes (toolname, tooldescription, toolparamdescription) on forms and inputs.
• Lighthouse Agentic Browsing. A new audit category that ships with Chrome DevTools for Agents, available at I/O 2026 for Antigravity and more than twenty other coding agents.

One sentence on lineage: WebMCP is Google's browser-side adaptation of Model Context Protocol (which originated at Anthropic and is now broadly adopted across model vendors), developed in the open at the W3C Web Machine Learning Community Group, a multi-vendor body. From here I'll call it the Web ML CG.

3. The diff, llms.txt first

The recipe starts with the smallest possible file. Drop a public/llms.txt at the root of your site. Here is the entire file from my demo, 21 lines, verbatim:

# Acme Dashboard

Acme is a project-management tool for solo developers. This is the customer
dashboard.

## Primary pages
- [Sign in](/login)
- [Dashboard home](/dashboard)
- [Account settings](/settings/account)
- [Billing](/settings/billing)

## Public docs
- [API reference](/docs/api)
- [Getting started](/docs/quickstart)

## Notes for models
- Authentication is via email + password or Google OAuth.
- The dashboard requires a signed-in session.
- The sign-in form is annotated with declarative WebMCP attributes
  (`toolname="signIn"`); the dashboard exposes imperative WebMCP tools
  (`signOut`, `changePlan`) via `navigator.modelContext.registerTool()`.

The shape is straightforward: a one-line H1 title, a short summary, H2 sections for primary pages, public docs, and notes-for-models. The Lighthouse llms-txt check requires the file to be served, to have at least one H1, and to contain at least one link. Beyond that, the format is a convention. Think of it as the model-facing counterpart to robots.txt and sitemap.xml: a polite, deterministic introduction to your site, expressed in the language the consumer (a language model) actually parses well.

The notes-for-models section is the high-leverage bit. That is where you describe behaviors and constraints that are not obvious from page titles alone: auth requirements, which form is the sign-in form, which tools the dashboard exposes. Spend a minute writing it as if a new contractor were reading it.

4. The diff, declarative WebMCP attributes

The second file to touch is the login form. Here is the "before" version, the kind of code a working React developer ships in a hurry:

<form onSubmit={(e) => {
  e.preventDefault();
  if (email && pw) setSignedIn(true);
}}>
  <input
    type="email"
    placeholder="Email"
    value={email}
    onChange={(e) => setEmail(e.target.value)}
  />
  <input
    type="password"
    placeholder="Password"
    value={pw}
    onChange={(e) => setPw(e.target.value)}
  />
  <button type="submit">Sign in</button>
</form>

And here is the "after" version with the four kinds of changes layered on:

<form
  aria-label="Sign in to Acme"
  toolname="signIn"
  tooldescription="Sign in to the Acme dashboard with email and password."
  onSubmit={(e) => {
    e.preventDefault();
    if (email && pw) setSignedIn(true);
  }}
>
  <label htmlFor="email">Email</label>
  <input
    id="email"
    name="email"
    type="email"
    autoComplete="email"
    required
    toolparamdescription="The user's email address."
    value={email}
    onChange={(e) => setEmail(e.target.value)}
  />

  <label htmlFor="password">Password</label>
  <input
    id="password"
    name="password"
    type="password"
    autoComplete="current-password"
    required
    toolparamdescription="The user's password."
    value={pw}
    onChange={(e) => setPw(e.target.value)}
  />

  <button type="submit">Sign in</button>
</form>

Four kinds of additions:

1. Real <label> elements bound to inputs via htmlFor. Pure accessibility win.
2. autoComplete="email" and autoComplete="current-password". Standard HTML5 since 2014, but easy to forget in a hand-rolled React form.
3. aria-label on the form region.
4. The new WebMCP attributes: toolname and tooldescription on the <form>, plus toolparamdescription on each <input>.

The first three changes help screen-reader users; the fourth helps AI agents. The same diff buys both. That overlap is the part I find most encouraging about the agent-ready story: most of the work is good old-fashioned semantic HTML, with a thin layer of new attributes on top.

What the WebMCP attributes actually do: when an agent lands on your page, it can read the form as a typed tool surface with named parameters, instead of guessing what each input represents from heuristics on placeholders or visual proximity. No manifest file, no separate registration, just attributes on the elements the agent already sees.

5. The diff, imperative WebMCP for dashboard actions

The declarative attributes cover form fills. For dashboard-style actions that have no associated form (sign out, change plan, run a job), there is an imperative API: navigator.modelContext.registerTool(). Here is the real useEffect from my demo:

useEffect(() => {
  const mc = typeof navigator !== 'undefined' && navigator.modelContext;
  if (!mc || typeof mc.registerTool !== 'function') return undefined;

  const controller = new AbortController();

  const signOutTool = {
    name: 'signOut',
    description:
      'Sign the current user out of the Acme dashboard and clear the session.',
    inputSchema: { type: 'object', properties: {} },
    execute: async () => {
      onSignOut();
      return { ok: true };
    },
  };

  const changePlanTool = {
    name: 'changePlan',
    description: 'Change the subscription plan for the current account.',
    inputSchema: {
      type: 'object',
      properties: {
        plan: {
          type: 'string',
          enum: ['free', 'pro', 'team'],
          description: 'The new plan to switch to.',
        },
      },
      required: ['plan'],
    },
    execute: async ({ plan }) => {
      onChangePlan(plan);
      return { ok: true, plan };
    },
  };

  mc.registerTool(signOutTool, { signal: controller.signal });
  mc.registerTool(changePlanTool, { signal: controller.signal });

  return () => controller.abort();
}, [onSignOut, onChangePlan]);

Three things worth noticing. First, the feature-detection guard at the top: on stable Chrome without the origin-trial token, the function is undefined and the effect cleanly no-ops, so the page works for every user. Second, the AbortController: the spec uses an AbortSignal for unregistration, which slots into React's component-unmount lifecycle naturally. Third, the tool object shape is small and familiar: name, description, inputSchema (JSON Schema), and an execute function that runs your code and returns a result. If you've used MCP tools from any model vendor's SDK, you have already seen this shape.

Declarative attributes describe form fields the agent might fill. The imperative API registers action tools that have no form. Use both, and your site has a typed surface that an agent can both query and act on.

6. Running the audit, real numbers

Lighthouse 13.3.0 ships an agentic-browsing config. Point it at your dev server:

npx lighthouse \
  --config-path=node_modules/lighthouse/core/config/agentic-browsing-config.js \
  http://localhost:5173

I ran the audit against three builds of the same React app: a vanilla "before" build, the "after" build with the recipe applied, and a "broken" build with deliberate violations sprinkled in.

A quick word on the audit floor. A site with no llms.txt and no WebMCP can still get a 2 of 2 on Agentic Browsing, because the category gates only on the checks that have something to evaluate against. The 3 of 3 you actually want comes from the form-metadata path, which requires real labels, autoComplete, and the WebMCP attributes; and from llms.txt presence with an H1 and a link.

Here is the relevant excerpt from the actual after.report.json, the category block at the bottom of the report:

"agentic-browsing": {
  "title": "Agentic Browsing",
  "categoryScoreDisplayMode": "fraction",
  "id": "agentic-browsing",
  "score": 1
}

score: 1 on a fraction-display category means full credit on every weighted ref. That is the audit pass you want to point at when you tell your team "we shipped agent-ready."

7. What is coming next

A short, forward-looking note. Chrome 149 ships the producer-side WebMCP API behind the origin trial flag, which is what wires up navigator.modelContext.registerTool() today. The consumer side, where Gemini in Chrome's side panel actually invokes the tools your site registers, is something Google has said will follow in a future Chrome build. The producer-side work pays off today (in Lighthouse audits, in accessibility scores, in a typed tool surface that any MCP-aware model can target), and it leaves you ready for the consumer side the moment it lands. The Lighthouse Agentic Browsing audit itself, importantly, runs on stable Chromium with no Chrome 149 dependency; the audit and the producer-side API ship on independent tracks.

8. Try it tonight

The full recipe in six steps:

1. npm create vite@latest a small React app, or open your existing one.
2. Add public/llms.txt with the shape above: H1, summary, H2 sections, notes-for-models.
3. Upgrade one form: real <label> elements with htmlFor, autoComplete values, an aria-label on the form, and the WebMCP attributes (toolname and tooldescription on the form, toolparamdescription on each input).
4. Register an imperative tool or two in a useEffect with navigator.modelContext.registerTool(tool, { signal }). Feature-detect the API first so stable Chrome users see a clean no-op.
5. Run the audit: npx lighthouse --config-path=node_modules/lighthouse/core/config/agentic-browsing-config.js http://localhost:5173. Requires lighthouse@13.3.0 or later.
6. Open the HTML report. Read the Agentic Browsing section. Tweak attributes, re-run.

If you have an evening, you have time for all six steps. Most of the diff is accessibility work you probably already know how to write. If your team is already doing WCAG compliance, you are roughly 70 percent of the way there; the new WebMCP attributes are the remaining 30 percent.

9. Closing

The mobile-friendly shift took five years to wash through the web. The accessibility shift is still in progress, decades in. The agent-ready shift is starting now, and the cost of entry is genuinely low: three new files, a handful of attributes, an audit you can run on a laptop. The producer-side work is cheap, visible in audits today, and useful to humans as a side effect. The consumer side, browsers actually invoking your registered tools, follows.

Spend a hundred lines on it before someone else makes that decision for you.

Are you starting on llms.txt and the form-metadata work tonight, or waiting for the consumer side to land in Chrome first? I'd love to hear which form on your site is the most obvious candidate for the first WebMCP annotation pass.