WebMCP: Giving AI Agents a Reliable Interface to the Web

AI agents can already operate websites, but most websites were designed for humans rather than machines. Agents usually have to inspect the DOM, accessibility tree, or screenshots, then simulate clicks, typing, and navigation.

This works, but it is often slow and fragile.

Before WebMCP: How Agents Used Websites

Traditionally, browser agents interacted with websites in several ways:

• Reading HTML and searching for buttons, links, and form fields.
• Using accessibility labels and semantic roles.
• Analyzing screenshots with computer vision.
• Automating UI interactions with tools such as Playwright, Puppeteer, or Selenium.

For example:

await page.getByRole("button", { name: "Add to cart" }).click();

The main weakness is that the agent interacts with the presentation layer. For example, a changed button label, redesigned layout, popup, responsive breakpoint, or new confirmation dialog may break the workflow. The agent must also repeatedly infer what each element does.

What Does WebMCP Solve?

WebMCP provides several advantages:

Less dependence on the UI

Tools connect to application functionality rather than specific buttons or page layouts. The UI can change without necessarily breaking the agent integration.

Fewer interaction steps

A workflow that previously required several clicks and input actions may become a single structured tool call.

Better input validation

Tool schemas can specify required fields, value types, enumerations, and numeric limits.

Better understanding

Tool names and descriptions explain the intended capability directly, reducing the amount of guessing required from the agent.

WebMCP and MCP

WebMCP is inspired by the Model Context Protocol, but it is not a replacement for MCP.

MCP is generally used to connect agents to persistent backend services, databases, files, APIs, and external systems, while WebMCP is focused on the website currently open in the browser. Its tools can access the current page state, DOM, application data, and authenticated browser session.

A simplified comparison:

MCP	WebMCP
Usually server-side	Browser and page-oriented
Persistent service	Available while the page is open
Connects to external systems	Connects to the current website
Independent of the UI	Aware of the current page state

An application may use both: MCP for backend capabilities and WebMCP for interactions with the live website.

How WebMCP Works

WebMCP supports declarative tools based on HTML forms and imperative tools registered with JavaScript.

A simple imperative tool could look like this:

await document.modelContext.registerTool({​
 name: 'add_to_cart',​
 description: 'Add a product to the visible cart.',​
 inputSchema: {​
  type: 'object',​
  properties: {​
   productId: { type: 'string' },​
   quantity: { type: 'number' }​
  },​
  required: ['productId', 'quantity']​
 },​
 execute: async ({ productId, quantity }) => {​
  return addToCart(productId, quantity);​
 }​
});​

For existing HTML forms, WebMCP can generate a tool from the form structure. Add toolname and tooldescription to the <form> element, while standard form fields become the tool parameters.

<form
  toolname="createSupportRequest"
  tooldescription="Submits a customer support request."
  action="/api/support-requests"
  method="post"
>
  <label>
    Subject
    <input
      type="text"
      name="subject"
      required
      maxlength="100"
    />
  </label>

  <label>
    Description
    <textarea
      name="description"
      required
      maxlength="1000"
    ></textarea>
  </label>

  <button type="submit">Submit request</button>
</form>

The browser uses the form metadata, field names, input types, and validation attributes to create a structured tool that an agent can discover and complete. This approach is suitable when the website already has a standard form and does not need custom JavaScript execution logic.

So, What’s The Catch?

WebMCP is experimental

WebMCP is still a proposed standard. Its APIs and browser support may change. Applications should treat it as progressive enhancement rather than a required feature.

Browser support is limited

Developers should use feature detection:

if ("modelContext" in document) { 
  // Register WebMCP tools.
}

The normal website experience must continue to work without WebMCP.

Agent behavior is not deterministic

An agent may choose the wrong tool, call tools in the wrong order, or provide semantically incorrect values. Tool descriptions and schemas reduce these risks but do not eliminate them.

Schemas do not replace backend validation

The server must still validate inputs, enforce permissions, check business rules, and reject unauthorized operations. A WebMCP call must never be treated as trusted simply because it came from the browser’s model context.

Tools depend on page state

Some tools are only valid when the user is authenticated, a particular record is selected, or an action is currently allowed. Developers should register and unregister tools as application state changes.

Best Practices

Give each tool one responsibility

Prefer focused tools:

• search_products
• add_product_to_cart
• remove_product_from_cart
• start_checkout

Avoid broad tools such as:

• manage_store

Focused tools are easier for agents to select, test, secure, and monitor.

Use clear names and descriptions

The tool name should accurately describe its effect.

For example:

• preview_order should not place an order.
• place_order should clearly indicate that a transaction occurs.
• open_checkout_form should not imply that checkout is complete.

Keep schemas strict

Use required properties, enumerations, length limits, and numeric constraints.

inputSchema: { 
  type: "object", 
  additionalProperties: false, 
  properties: { 
    status: { 
      type: "string", 
      enum: ["draft", "submitted", "cancelled"] 
    } 
  }, 
  required: ["status"] 
}

Avoid overlapping tools

Tools with similar names and purposes make selection harder. Instead of exposing find_product, search_item, and lookup_product, provide one clearly defined search tool.

Return concise structured results

Avoid returning raw HTML, complete API responses, or unnecessary internal data.

Prefer:

return { 
  success: true, 
  orderId: "ORD-1042", 
  status: "submitted" 
};

Register tools only when they are usable

A cancel_order tool should only be available when the current order can actually be cancelled. This is safer and clearer than exposing it permanently and relying on the agent to understand every restriction.

Require confirmation for consequential actions

Purchases, deletions, financial operations, permission changes, and published content should require visible user confirmation or another strong verification step.

Security Considerations

WebMCP tools operate through AI agents, so developers must account for indirect prompt injection. Because an LLM processes instructions and external content within the same context, malicious text returned by a tool may influence later agent actions. Model-level protections reduce risk but cannot guarantee safety.

Use untrustedContentHint when a tool returns user-generated or externally sourced content. For tools that do not modify application state, add readOnlyHint so the agent can make better decisions about user confirmation.

Tools are not exposed to unrelated websites or cross-origin frames by default. When using exposedTo, allow only specific trusted HTTPS origins. Even read-only tools may reveal private user information, while write tools can perform actions on the user’s behalf.

Keep tool metadata and outputs concise. Chrome currently recommends limits of approximately 30 characters for names, 150 characters for parameter descriptions, 500 characters for tool descriptions, and 1,500 characters for each tool output. These limits may change as WebMCP evolves.

Conclusion

WebMCP gives websites a structured way to expose actions to AI agents, reducing dependence on fragile DOM inspection, visual interpretation, and simulated clicks. It complements MCP by focusing on tools available within the current browser page and user session.

Because WebMCP is still experimental, it should be implemented as progressive enhancement. Clear tool definitions, strict schemas, minimal outputs, and careful security controls are essential for making agent interactions reliable without exposing users or applications to unnecessary risk.

References

Chrome for Developers official documentation: https://developer.chrome.com/docs/ai/webmcp