WebMCP Needs a Browser Tool Layer — So I’m Building webmcp.js

Most agents still use websites like a very fast human: read the page, inspect the DOM, click buttons, fill forms, and infer whether the action worked. That model is useful, but it is fragile. A label changes, a modal appears, a class name is renamed, or the layout moves, and the flow can break even though the product still works perfectly for a person.

WebMCP is about moving that contract out of the visual layer. Instead of making an agent rediscover app behavior from pixels and markup, the page can expose a small set of structured capabilities directly:

products.search
products.getDetails
cart.add
checkout.start

The agent should not have to ask which button to click. It should be able to ask which actions the website intentionally exposes, what inputs those actions accept, and which ones require approval. That is the idea behind webmcp.js.

From DOM actions to capabilities

A website already knows its own capabilities. It knows how to search products, add an item to a cart, open a project, create a task, or export a report. The missing piece is a simple browser-side tool layer for registering those capabilities in a form an agent can inspect and call.

mcp.tool("products.search", {
  description: "Search products by query",
  input: schema,
  run: searchProducts
});

The exact API may change, but the shape matters: tools have names, descriptions, input schemas, return values, and execution functions. The page becomes more than a rendered interface. It becomes a capability layer attached to the real app state.

Why safety matters

If websites expose tools to agents, those tools need different execution policies. Reading product details is not the same as adding something to a cart. Adding something to a cart is not the same as placing an order or deleting an account.

products.search
products.getDetails
cart.add
project.create

checkout.start
order.place
account.delete

The core policy question should be explicit: before this tool runs, does it need approval? Approval can mean no approval, human confirmation, an app-defined review step, or a stricter flow for sensitive actions.

mcp.tool("products.search", {
  approval: "none",
  run: searchProducts
});

mcp.tool("cart.add", {
  approval: "human",
  run: addToCart
});

The point is not to slow agents down everywhere. It is to let them move quickly where the action is safe, and require a deliberate step where the action changes state or carries real risk.

Why this belongs on the web page

The browser already has the real user session, the current app state, and the visible UI. That makes the page a natural place to expose agent-facing tools. Instead of giving an agent direct backend access, the application can decide exactly which operations are available from the current page and current user context.

• which tools exist
• what inputs they accept
• what they return
• which tools need approval
• which tools should never run automatically

That keeps control with the application. The website exposes the contract it is willing to support, and the agent stops treating the DOM as an unstable API surface.

What webmcp.js is trying to be

webmcp.js is not a replacement for the UI, authentication, or backend authorization. It is a small browser-side library for exposing clear, intentional, agent-friendly tools from the page. The useful version of this is boring: register tools, describe inputs, declare approval requirements, run handlers, and return structured results.

If AI agents are going to use the web as real software, websites need a better interface than guessing from rendered HTML. webmcp.js is my experiment in that direction: turn websites from interfaces agents must infer into capability layers agents can safely understand.