WebMCP: How to Make Your Website Agent-Ready for AI Browsing

WebMCP lets AI agents act on your site, not just read it. Learn declarative vs imperative WebMCP, llms.txt, Lighthouse agentic audits, and how to start.

WebMCP: How to Make Your Website Agent-Ready for AI Browsing

AI agents are starting to do more than read your website. They are beginning to act on it: filling forms, starting checkouts, booking calls, and running tools on a visitor’s behalf. For most sites, that is a problem, because an agent can only guess at what each button and field does by simulating clicks and reading the page like a human. WebMCP is the emerging standard that fixes this, and it is quickly becoming the next frontier of Answer Engine Optimization (AEO).

We recently made snezzi.com agent-ready end to end. This is what WebMCP is, how the two implementation paths differ, how Chrome scores agentic readiness, and the practical lessons we learned shipping it on a live site.

TL;DR

  • WebMCP lets your website expose actions as structured tools, so AI agents can complete workflows instead of guessing through clicks.
  • Start with your highest-intent forms: demo requests, audits, bookings, lead magnets, checkout steps, and quote requests.
  • Use declarative WebMCP for a fast baseline, then use the imperative API for your most important conversion paths so agents get a complete schema and your existing validation still runs.
  • Publish an llms.txt file, fix accessibility tree issues, reduce layout shift, and verify everything with Chrome’s experimental Lighthouse Agentic Browsing audit.
  • AEO helps your brand get cited by AI. WebMCP helps your brand get acted on by AI.

What WebMCP actually is

WebMCP is a proposed web standard, championed in Chrome, that lets a website declare its actions as structured tools that AI agents can call directly. Instead of an agent inferring that a field labeled “Website” expects a company URL, your site tells the agent exactly that, in a machine-readable schema.

The key term here is actuation: the act of an agent simulating mouse clicks and typing as if it were the human user. Actuation is brittle. Every step is open to interpretation, and a single misread field can derail a multi-step task like booking a call. WebMCP replaces guesswork with a contract. Your page says “this is the book-a-call tool, it needs a website and an email,” and the agent uses it the way you intended, visibly, on your page, with your brand and design intact.

That last point matters. Tools execute on your page, in front of the user, so trust stays where it belongs.

Why this is an AEO move, not a developer side quest

AEO got your brand cited in AI answers. Agent-readiness is the natural next step: getting your brand acted on. As more people delegate research and buying tasks to assistants, the sites that convert will be the ones an agent can complete a task on without friction.

If an agent lands on your pricing page for a high-intent query and cannot reliably start a conversation, that is a lost customer, the same way a confusing checkout loses a human. WebMCP is how you make your highest-intent pages agent-completable, not just agent-readable.

The two ways to implement WebMCP

There are two APIs, and most sites should use both.

Declarative: annotate your forms

The fastest start is declarative. You add three attributes to existing HTML forms:

  • toolname: a clear, action-oriented name such as book_appointment
  • tooldescription: what the tool does and when an agent should use it
  • toolparamdescription: on individual fields, so the agent understands each parameter

The browser turns the annotated form into a tool automatically. No new runtime, no JavaScript. This is the right baseline for the bulk of your conversion forms.

Imperative: register tools in JavaScript

The imperative API gives you full control. You register a tool with a name, a description, a complete JSON Schema for its inputs, and an execute function that runs when an agent calls it:

document.modelContext.registerTool({
  name: "book_strategy_session",
  description: "Collect a website, budget, and work email, then start booking.",
  inputSchema: {
    type: "object",
    properties: {
      website: { type: "string", description: "Company website URL." },
      email: { type: "string", description: "Work email." },
    },
    required: ["website", "email"],
  },
  execute: async ({ website, email }) => {
    // fill the real form, run your validation, submit your existing flow
    return "Strategy session request submitted.";
  },
});

Use imperative for your most important conversion paths. You author the schema by hand, so the agent sees exactly what each tool needs, and your execute function reuses your existing validation and lead flow.

Do not forget llms.txt

WebMCP covers actions. Discovery still matters. An llms.txt file at your domain root gives agents and answer engines a concise, machine-readable map of your most important pages. Treat it as the agent-facing equivalent of your homepage: a short summary, your core pages, and your primary conversion paths.

How Chrome scores agentic readiness

Chrome’s Lighthouse includes an experimental Agentic Browsing category. It is not a single weighted score. It is a set of deterministic checks that report a pass ratio, which makes it easy to track in a build pipeline. The checks include:

  • Registered WebMCP tools and whether their schemas are valid
  • Form coverage, which flags forms that lack annotations
  • The presence of llms.txt
  • A sound accessibility tree, since agents use it as their primary data model
  • Cumulative Layout Shift, because elements that move between identification and interaction break agent actions

To see the category, you run Lighthouse with the experimental preset.

Check your own page

Paste a URL and get a fractional agentic-readiness score across WebMCP tools, the accessibility tree, and layout stability, mirroring Chrome's Lighthouse agentic browsing audit.

Run the Agentic Readiness Checker

Five lessons from shipping it

  1. It is behind a flag today. WebMCP is available in Chrome for local development and is heading into an origin trial. Build it as a progressive enhancement. Visitors in a non-WebMCP browser see your normal site, and agent-enabled browsers get the tools.

  2. Declarative is fast, but check your schemas. On current Chrome builds, we found the declarative path could register a tool with an empty parameter schema. The agent could see the tool name but not what it needed. Moving our highest-value forms to the imperative API gave us real, populated schemas.

  3. Tool names must be unique per page. We hit a case where a sidebar form and an inline form shared a name, so the browser registered only one and the other became invisible to agents. Give each tool a distinct, descriptive name and test for it.

  4. Accessibility is not optional. Agents read the accessibility tree. Every interactive element needs a programmatic name, valid roles, and nothing important hidden from the tree. The work you do here pays off for humans and agents at once.

  5. Stability counts. Keep Cumulative Layout Shift low. An agent that locates a button and then watches it jump because of a late-loading image will fail the same way a person mis-taps.

Step-by-Step: Make a Page Agent-Ready

You do not need to rebuild your whole website. Start with one high-value page and one high-value workflow, then expand.

Step 1: Choose the Workflow

Pick a workflow where agent completion would clearly help revenue or lead quality. Good first candidates are:

  • Book a demo or strategy session
  • Run an audit or calculator
  • Submit a quote request
  • Download a gated resource
  • Start a checkout or trial
  • Contact sales

Do not start with every form on the site. Start with the workflow that has the highest commercial intent and the clearest required inputs.

Step 2: Make the Existing Form Clean

Before adding WebMCP, make sure the normal HTML form is agent-readable:

  • Every input has a stable name
  • Required fields use the required attribute
  • Inputs have visible labels or clear aria-label values
  • Select fields have meaningful option values
  • The form can be submitted without relying on hidden visual-only state
  • Validation errors are visible and specific

If a human using assistive technology would struggle with the form, an agent probably will too.

Step 3: Add Declarative WebMCP Metadata

For a simple form, add tool metadata directly to the form and its fields:

<form
  toolname="book_strategy_session"
  tooldescription="Collect a visitor's website and work email, then start the strategy session booking flow."
>
  <label>
    Website
    <input
      name="website"
      type="url"
      required
      toolparamdescription="The visitor's company website URL."
    />
  </label>

  <label>
    Work email
    <input
      name="email"
      type="email"
      required
      toolparamdescription="The visitor's work email address."
    />
  </label>
</form>

Keep the tool name action-oriented. book_strategy_session is better than form_1, and run_ai_visibility_audit is better than submit.

Step 4: Use Imperative WebMCP for the Highest-Value Flows

Declarative metadata is a strong baseline, but important conversion paths usually deserve the imperative API. Use it when you need:

  • A complete JSON Schema
  • Enum values for fields like budget or plan type
  • Custom validation before submit
  • Multi-step flows
  • Analytics or lead-capture logic
  • A controlled redirect after submission

The safest pattern is to let the tool fill and submit your real form, instead of creating a parallel conversion path. That way your existing validation, analytics, and CRM logic continue to run.

Step 5: Publish an llms.txt File

Create /llms.txt at your domain root. Keep it short and useful:

  • One-line brand summary
  • Core product or service pages
  • High-intent conversion pages
  • Important tools or resources
  • Canonical docs, pricing, and contact paths

This helps agents understand what your site offers before they decide which page or tool to use.

Step 6: Fix Accessibility and Layout Stability

WebMCP is not the only thing Chrome checks. Agentic browsing also depends on the page being easy to understand and stable to interact with.

Prioritize:

  • One clear h1
  • Semantic landmarks such as main, nav, and footer
  • Accessible names for buttons and links
  • Alt text for meaningful images
  • Explicit dimensions for images and embeds
  • Low Cumulative Layout Shift

These fixes improve the site for humans, search engines, and agents at the same time.

Step 7: Run Lighthouse with the Experimental Preset

Use Chrome’s experimental Lighthouse Agentic Browsing category to verify the page. In local testing, enable the WebMCP feature flag or pass it through Chrome flags:

lighthouse https://example.com/your-page/ \
  --preset=experimental \
  --chrome-flags="--enable-features=WebMCP"

Check for:

  • Registered WebMCP tools
  • Valid schemas
  • Annotated form coverage
  • llms.txt
  • Accessibility tree health
  • Cumulative Layout Shift

Treat the result as a regression test. If a future redesign removes a tool name, breaks a form label, or adds layout shift, your agent-readiness score should catch it.

Step 8: Expand Page by Page

Once the first workflow is clean, repeat the process across your highest-intent pages:

  1. Homepage
  2. Pricing page
  3. Product or service pages
  4. Audit or calculator tools
  5. Lead magnets
  6. Contact and booking pages

The goal is not to expose every possible click. The goal is to expose the actions a serious buyer or researcher would ask an AI agent to complete.

Where to go from here

Agent-readiness builds on the same foundation as AI visibility: clear structure, machine-readable signals, and pages that are easy to act on. If you want to see how visible your brand already is across AI answers, and where agent-ready conversion would move the needle, run a free AI visibility audit and we will show you exactly where you stand.