How to Make Your Website WebMCP-Ready

The web is quietly gaining a second kind of user: AI agents. Until now an agent had to look at your page — read the DOM, guess which button does what, and hope. WebMCP replaces the guessing with a contract: your site declares structured tools (a name, a description, typed inputs) that an agent running in the browser can call directly. It's the Model Context Protocol, brought to the web page itself.

WebMCP is a draft W3C Community Group standard from Google and Microsoft. It shipped as an early preview in Chrome 146 in early 2026, with wider rollout expected later in the year. This guide walks through making your site WebMCP-ready, step by step, in both of the ways the spec supports.

The one idea to grasp first

A WebMCP tool has three parts: a name, a description the agent reads to decide when to use it, and an input schema describing its parameters. When the agent calls the tool, your code runs — in the user's own tab, with their session and permissions — and returns a result. There are two ways to declare one: the declarative form API, and the imperative JavaScript API.

Path A — the declarative API (start here)

If the action is already a <form> — search, subscribe, log in, request a quote — you can expose it with two attributes. The form keeps working normally for humans.

Step 1. Find a real form on your page.

Step 2. Add tool-name and tool-description to the <form>.

Step 3. Add tool-param-description to each input so the agent knows what to fill.

<form
  tool-name="search-products"
  tool-description="Search the product catalog by keyword"
  action="/search" method="get"
>
  <input
    name="query"
    type="text"
    tool-param-description="Keywords to search for, e.g. 'running shoes'"
    required
  />
  <button type="submit">Search</button>
</form>

Step 4. That's it — a WebMCP-capable browser synthesizes a tool from the form. Because it's your normal form, submitting it still works for people. This is the lowest-risk way to start and covers a surprising share of real site actions.

Path B — the imperative API (for anything a form can't express)

For logic that isn't a simple form, register a tool in JavaScript. The current entry point is document.modelContext (older Chrome previews used navigator.modelContext).

Step 1. Feature-detect, so non-WebMCP browsers are unaffected:

const mc = document.modelContext || navigator.modelContext;
if (mc) {
  // register your tools here
}

Step 2. Call registerTool with a name, description and JSON-Schema inputs.

Step 3. Implement execute and return the content-block shape MCP uses.

mc.registerTool({
  name: "add-to-cart",
  description: "Add a product to the shopping cart by its SKU.",
  inputSchema: {
    type: "object",
    properties: {
      sku: { type: "string", description: "Product SKU, e.g. 'SHOE-42'" },
      quantity: { type: "integer", description: "How many to add" }
    },
    required: ["sku"],
    additionalProperties: false
  },
  async execute({ sku, quantity = 1 }) {
    const res = await addToCart(sku, quantity);   // your existing app logic
    return { content: [{ type: "text", text: JSON.stringify(res) }] };
  }
});

Step 4. Register on page load (and after client-side navigations, if your app is an SPA). Reuse the functions your UI already calls — the whole point is one layer of business logic that both humans and agents invoke.

Best practices

• Name tools in kebab-case and describe them the way you'd brief a new teammate — the description is how the agent decides when to call the tool.
• Describe every parameter. Vague inputs lead to wrong calls.
• Least privilege. Only expose actions the user could already perform themselves; the tool runs with their session.
• Guard destructive actions. Require confirmation for anything that deletes, pays, or sends — treat tool input as untrusted.
• Keep the human UI working. WebMCP augments your page; it should never replace a working form or button.

Step-by-step: test that it works

1. Generate correct snippets for your tool with the WebMCP Tool Generator — it outputs both the declarative HTML and the imperative JS with the feature-detection shim.
2. Add them to your page and deploy (or run locally).
3. Check the result with the WebMCP Readiness Checker: paste your HTML or scan your URL to confirm the tools are detected and well-described.
4. For a true end-to-end test, open the page in a WebMCP-capable browser build (Chrome 146+ with the flag enabled) and have its agent call the tool.

ToolsHub itself is WebMCP-ready — every page registers a search-tools tool, so you can scan toolhq.dev with the checker above and see a real imperative registration detected.

Where WebMCP fits with your other agent signals

Think of three complementary layers. llms.txt tells an AI assistant what your site is and points at your key pages. robots.txtdecides who may crawl. WebMCP declares what an agent can do once it's on the page. Together they make a site legible and actionable to the growing population of AI agents — the agentic-web equivalent of good SEO.

It's early, and the spec (especially the declarative attribute names) can still shift, so feature-detect and re-check against your target browser. But the upside is real: as agents become a way people reach and use websites, the sites that hand them clean tools will be the ones that actually get used.