WebMCP explained: exposing your site's actions to AI agents

WebMCP is a draft web standard that lets a web page offer its key actions to AI agents as tools. Instead of an agent reading your page and clicking buttons, the page registers named tools, each with a description, a JSON Schema for its input and a function that does the work. An agent running in the visitor's browser can then call a tool directly and get a structured result back.

It is early, but it is one of the clearest signs of where agentic browsing is heading: sites telling agents what they can do, instead of agents guessing from the interface.

The problem it solves

Today, an agent that wants to use a website mostly behaves like a very literal person. It reads the page, finds a control, types, clicks and hopes the page responds as expected. That works on simple, well-labeled pages. It fails on complex forms, custom widgets, multi-step flows and anything that changes layout. We explain the reading side in how AI agents read a web page.

WebMCP skips the guessing for the actions that matter. If your site lets people search a catalog, check availability or send an inquiry, the page can say so directly: here is a tool called check_availability, it takes a date and a party size, and it returns open slots.

How it works

The draft, published by the W3C Web Machine Learning Community Group at webmachinelearning.github.io/webmcp, adds a navigator.modelContext object to the page. A script registers tools on it when the page loads. Each tool has:

• a name, such as send_project_inquiry;
• a description in plain language, which is what the agent reads to decide whether and how to use it;
• an input schema in JSON Schema, which tells the agent exactly which fields to send and in what shape;
• an execute function, which runs in the page with the visitor's session and returns a result.

A minimal registration looks like this:

if (navigator.modelContext) {
  navigator.modelContext.registerTool({
    name: "search_articles",
    description: "Search this site's articles by keyword.",
    inputSchema: {
      type: "object",
      properties: { query: { type: "string" } },
      required: ["query"]
    },
    async execute({ query }) {
      const res = await fetch("/search?q=" + encodeURIComponent(query));
      return { content: [{ type: "text", text: await res.text() }] };
    }
  });
}

The API has changed shape as the draft evolved, and earlier versions used a single provideContext() call to register a set of tools. Check the current specification before you build, and write your code so it detects which method exists. Chrome has published notes on its early preview at developer.chrome.com.

This site uses WebMCP itself. Pages here register tools to read the site guide, fetch any page as Markdown, run the agent-readiness scan and send a project inquiry, all built on the same endpoints the normal interface uses.

WebMCP and MCP servers

The name comes from the Model Context Protocol (MCP), an open protocol for connecting AI clients to tools and data. The two are related but work in different places.

An MCP server is a separate service that exposes back-end systems, such as your database, CRM or order system, to AI clients that are set up to connect to it. WebMCP lives in the page. It is found automatically by an agent in the browser, and it acts with the permissions of the person who is signed in, which makes it a good fit for actions tied to what that person is doing on your site. Many businesses will end up with both. Our guide to MCP servers for business covers the server side.

Doing it safely

A WebMCP tool is a new way into actions your site already offers, so the same rules apply as for any interface, plus a few that matter more when the caller is software.

• Expose only what the page already allows. A tool should never do more than the signed-in person could do by hand. It is an interface, not a back door.
• Validate on the server. The input schema helps the agent send the right shape, but the server must still check every value, exactly as it does for a normal form post.
• Keep people in charge of consequences. For payments, deletions, bookings and messages, have the tool prepare the action and require the person to confirm it, rather than completing it silently.
• Describe tools honestly. The description is what the agent relies on. Say what the tool does, what it does not do, and when it should be used only on the person's explicit request.
• Enhance progressively. Detect navigator.modelContext before registering anything, and unregister tools when the page no longer offers them. Browsers without support should see no difference.

What makes a good tool

Design tools around tasks, not around your page structure. find_available_slots is more useful to an agent than click_calendar_next. Keep inputs few and typed, use enums where the choices are fixed, and return results as short, plain text or structured data that the agent can relay to the person. When something fails, return the reason in words the person could act on, such as a date outside the booking window, rather than an error code.

Should you add it now?

If your site's value is in actions, such as searching, booking, quoting, ordering or contacting, adding one or two WebMCP tools is a low-risk experiment that positions you for agent traffic as support grows. If your site is mostly content, the basics come first: clean HTML, labeled forms, Markdown for agents and llms.txt. Either way, the underlying rule is the same: make what your site does explicit instead of leaving agents to infer it.

Next step

The free agent-readiness scan checks whether your pages register WebMCP tools, alongside 21 other checks. If you want tools designed and built for your site, tell us about it.