The Rise of WebMCP: How AI Agents Can Interact Directly with Your Website

An AI agent trying to use your website today is doing something that resembles guesswork. It looks at a screenshot and tries to identify buttons. It searches through the HTML structure and tries to infer what each element does. It then takes an action, waits for the result, and repeats — one step at a time, with no direct understanding of what the website can do.

WebMCP changes this relationship. Instead of forcing the agent to reverse-engineer the interface, the website publishes a set of structured tools that the agent can discover and call directly. The agent no longer needs to read the page to understand it — the page tells the agent exactly what it can do.

This article covers what WebMCP is, how it works step by step, why it matters for anyone building or marketing a website, how it compares to traditional MCP, and how to implement and test it — including a working code example.

What Is WebMCP

Today, when an AI agent tries to use a website, it typically works in one of two ways.

The first method uses a screenshot. The agent sees the page as an image, tries to recognize buttons, input fields, and menus, then guesses where to click. The second method uses the DOM — the HTML structure of the page. The agent searches through elements, labels, and attributes, then tries to identify which element performs the action it needs.

Both methods can work, but in both cases the agent is reconstructing the meaning of the website from clues. The website is not directly telling the agent what each action does or how it should be used.

This creates a repeated loop: inspect the page, guess what to do, perform the action, wait for the result, then inspect again. Every additional step adds time, cost, and another opportunity to fail. A new button label, a cookie banner, or a small design change can break the entire workflow.

The problem is not that the website cannot perform the action. The action already exists inside the website. The problem is that the agent can only see the interface around that action — it cannot access the action directly.

WebMCP changes this by allowing the website to publish structured tools that an AI agent can discover and use. A tool describes one action the website can perform. It includes a name, a description, the required inputs, and the logic that executes the action.

For example, a travel website can publish a tool called search_flights. The description explains what the tool does, and the input schema tells the agent it needs a destination, a date, and a number of passengers. The agent sends this information directly to the tool. The website runs the same search logic used by the normal interface and returns a structured result.

For this task, the agent no longer needs to analyze a screenshot or search through the DOM. It already knows which action to use, which information is required, and how to call it. This does not give the agent access to the complete website — the website decides which tools are available, what information they accept, and when the agent can use them.

How Does WebMCP Work

The complete WebMCP process can be explained in five steps: register, discover, invoke, execute, and respond.

The available tools can also change with the state of the page. A checkout tool can appear when a product is added to the cart, and disappear when the cart is empty. So the agent always receives the actions that are relevant to the current page and the current situation.

This state-awareness is one of the most important differences from traditional automation. The agent is not working from a static map of the website — it reads the available tools at the moment of the request, and those tools reflect exactly what is possible right now.

Why AI Agents Are Becoming a Primary Web User

Until recently, websites were built exclusively for human users. Every design decision — layout, navigation, labels, forms — was made for the human eye and the human hand. AI agents that needed to interact with websites had to adapt to those decisions, even when those decisions made no sense for a machine.

That assumption is changing. Agents are increasingly being used to search, compare, book, and purchase on behalf of users. A user who asks an AI assistant to "find the cheapest flight to Paris next Friday" expects the agent to actually search — not to describe how to do it. A user who says "cancel my last order" expects the agent to complete the action, not guide them through the interface.

WebMCP matters because it makes this possible in a controlled and intentional way. There are three specific benefits:

• Speed. Instead of navigating through several pages and visual elements, the agent can call the correct action directly. There is no page-by-page traversal, no guessing, no retry loop.
• Reliability. The tool clearly defines the required inputs, their data types, and the values that are accepted. The agent does not need to guess whether a field requires a city name, a date, or a flight number — the schema explains exactly what is needed.
• Efficiency. The agent does not need to analyze the complete page after every action. This reduces the amount of context, reasoning, and repeated attempts required to complete a task.

But adding more tools does not always create a better experience. If the website publishes too many tools with similar names or descriptions, the agent may have difficulty selecting the correct one. The goal is not to publish every function inside the website. The goal is to publish a small number of clear tools that represent the most important user actions.

Websites should not be built only for humans. They should also be ready for AI agents.

WebMCP vs. Traditional MCP: What's the Difference

WebMCP and MCP follow the same general idea — they both allow an AI agent to discover and use structured tools. But they operate in different layers.

WebMCP does not replace MCP. The two work together. MCP can manage the core business logic at the backend level. WebMCP can give the agent a direct, state-aware way to use that logic inside the live website.

MCP works at the service layer. WebMCP works at the website experience layer. Both are needed.

How to Implement WebMCP in Your Website

The best way to start using WebMCP is not to expose every action on the website. Begin with one useful, low-risk action. A read-only action is the strongest first tool — search, product availability, diagnostics, or order status. These are valuable enough to demonstrate the benefits but do not create the risk of an irreversible action.

Tool Design Principles

A well-designed WebMCP tool follows these rules:

• One tool, one intention. Each tool should represent a single clear user action — not a category of actions.
• Descriptive name. search_flights, check_order_status, and create_event are easier to select than a generic name like manage_travel.
• Clear description. Explain what the tool does and when the agent should use it. This helps the agent distinguish it from other tools with similar functions.
• Precise input schema. Define the required information, correct data types, and accepted values. The agent should never need to guess.
• Use existing logic. The execute function should call the same application logic as the normal website. Do not maintain two separate versions of the same action.
• Return structured results. Instead of returning only "success", return an order number, a status, the number of results, or the next available action.
• State-aware availability. Only expose a tool when it is relevant to the current page. A few clear, state-aware tools are easier for the agent to use than a long list of overlapping ones.

Code Demo: Registering a WebMCP Tool

Here is a full implementation example for a travel website registering a flight search tool. The same pattern applies to any domain — e-commerce, SaaS, content platforms, or marketplaces.

// Step 1 — Check for WebMCP support in the browser
if ('ai' in window && 'registerTool' in window.ai) {

  // Step 2 — Register a tool with name, description, schema, and execute function
  await window.ai.registerTool({
    name: 'search_flights',
    description: 'Search available flights to a destination. ' +
                 'Use this when the user wants to find or compare flights.',

    inputSchema: {
      type: 'object',
      properties: {
        destination: {
          type: 'string',
          description: 'Destination city or IATA airport code (e.g. "Paris" or "CDG")'
        },
        departure_date: {
          type: 'string',
          description: 'Travel date in YYYY-MM-DD format'
        },
        passengers: {
          type: 'integer',
          description: 'Number of passengers',
          default: 1
        }
      },
      required: ['destination', 'departure_date']
    },

    // Step 3 — Execute using the website's existing search logic
    execute: async ({ destination, departure_date, passengers = 1 }) => {
      const response = await fetch(
        `/api/flights?to=${destination}&date=${departure_date}&pax=${passengers}`
      );
      const flights = await response.json();

      // Step 4 — Return a structured result the agent can clearly understand
      return {
        success: true,
        count: flights.length,
        results: flights.slice(0, 5)  // return top 5
      };
    }
  });
}

State-Aware Tools

Some tools should only be available when the page is in a specific state. A checkout tool makes sense when the cart has items. A cancel order tool makes sense only when the order can still be cancelled. Register and unregister tools as the page state changes:

// Register the checkout tool only when the cart is not empty
function syncCartTools(cartItems) {
  if (cartItems.length > 0) {
    window.ai.registerTool({
      name: 'checkout',
      description: 'Proceed to checkout with the items currently in the cart.',
      inputSchema: {
        type: 'object',
        properties: {
          shipping_address: { type: 'string', description: 'Delivery address' }
        },
        required: ['shipping_address']
      },
      execute: async ({ shipping_address }) => {
        // Sensitive action — always ask for user confirmation first
        const confirmed = await confirmWithUser('Confirm checkout?');
        if (!confirmed) return { success: false, reason: 'Cancelled by user' };
        return await processCheckout(cartItems, shipping_address);
      }
    });
  } else {
    window.ai.unregisterTool('checkout');
  }
}

// Call this whenever the cart changes
cart.onChange(syncCartTools);

Note that sensitive or irreversible actions should always require explicit user confirmation before the tool executes. The agent should not complete a purchase, cancellation, or deletion without the user approving the specific action.

How to Test WebMCP

Enable WebMCP in Chrome

WebMCP is currently an experimental proposal available as a Chrome origin trial starting with Chrome 149. You can also enable it locally via a browser flag to test on your own website before joining the origin trial.

Because the API is still experimental, its names and behavior may change. Avoid depending on the current version as permanent production infrastructure. Continue following the specification as it develops.

WebMCP also operates inside browser security boundaries. It requires an origin-isolated page and is controlled through a Permissions Policy header. This means the website explicitly controls whether WebMCP tools can be registered at all:

# Add this header to allow WebMCP on your origin
Permissions-Policy: browsing-topics=(), ai-tool-registration=(*)

The MCP Tool Inspector

Chrome includes a Model Context Protocol Tool Inspector — a developer tool that shows every tool currently registered on the page. It displays the name, description, and input schema of each tool, and allows you to enter custom parameters and execute the tool manually.

The inspector helps you verify three things:

• Does the tool receive the correct input parameters?
• Does the execute function complete the action successfully?
• Is the structured result clear enough for the agent to understand?

Testing With Realistic Agent Requests

Verifying that a tool executes correctly is only one part of testing. You also need to verify that the agent selects the correct tool for each type of request.

A tool can execute perfectly and still create a bad experience if the agent uses it for the wrong request, or ignores it when it should be called. Test across five scenarios:

Measure these outcomes across test runs:

• Task completion rate
• Number of steps required
• Execution time per task
• Failure reasons and frequencies
• Cases where the agent selected the wrong tool

If the first tool improves the process, gradually expose more actions. Every new tool should solve a clear problem and create measurable value. A website that exposes twenty poorly-described tools is harder for an agent to use than one that exposes three well-described ones.

Key Takeaways

Three ideas to keep from this article:

1. Expose the intention of the website, not only its pixels and HTML structure. Tools give the agent direct access to actions that already exist inside the site. The interface remains for human users — tools add a second path for agents.
2. Use WebMCP and MCP together. MCP provides persistent backend services. WebMCP provides actions connected to the live website and the user's current session. They are complementary, not competing.
3. Keep tools clear, limited, and state-aware. Start with one useful, low-risk tool. Test it with real agent requests. Measure the result. Add more tools only when each one solves a specific, measurable problem.

WebMCP is not about teaching agents to click buttons more accurately. It is about giving them a direct way to use the actions that already exist inside the website.