Vishal Singh

Posted on Sep 1

WebMCP: Make Your Website Agent-Ready Without Screen Scraping

#webmcp #a11y #webdev #ai

AI agents can already operate websites by reading text, inspecting accessibility trees, and clicking visible controls. That works, but it asks the agent to reverse-engineer an interface designed for humans.

WebMCP proposes a different model: a website can expose supported actions as structured tools. Instead of guessing which button completes a booking, an agent can discover a bookSlot tool with a description, typed inputs, and a defined result.

WebMCP is currently an emerging Chrome capability and origin-trial technology, not a cross-browser production standard. That makes it useful to study and experiment with, but too early to use as the only path for an important workflow.

Why screen-driven automation is fragile

A human can look at a page and understand that “Continue” advances a checkout. An agent has to infer that meaning from surrounding text and interface state.

That approach can break when:

button labels change
a responsive layout moves controls
a modal covers the next step
the page renders differently for another account
an A/B test changes the interface
an action has an important side effect that is not obvious from the label

A structured tool gives the browser and agent a clearer contract.

The basic WebMCP model

A site registers tools. Each tool has a name, description, input schema, and implementation. A compatible browser can expose those tools to an agent, and the agent supplies structured arguments.

For a consultation form, the conceptual flow looks like this:

The website registers bookSlot.
The tool describes required fields such as date, time, name, and email.
The browser presents the tool to an agent within the page's origin and permission context.
The agent asks for or confirms the required information.
The website's own code performs the booking.

The agent does not need to guess the DOM path to a submit button.

Declarative tools for existing forms

The declarative API is designed for standard HTML forms. A form can be annotated with a tool name and description while its controls become tool parameters.

<form
  action="/consultations"
  method="post"
  toolname="book_consultation"
  tooldescription="Book a 30-minute consultation slot"
>
  <label>
    Date
    <input name="date" type="date" required>
  </label>

  <label>
    Email
    <input name="email" type="email" required>
  </label>

  <button type="submit">Book</button>
</form>

The important idea is progressive enhancement. The form should remain a real, usable form for people and browsers that do not support WebMCP.

Imperative tools for application actions

Some actions do not map neatly to one form. The imperative API lets application code register a tool with a JSON schema and an execute function.

document.modelContext.registerTool({
  name: "checkOrderStatus",
  description: "Return the latest status for an order owned by the signed-in user",
  inputSchema: {
    type: "object",
    properties: {
      orderId: { type: "string" }
    },
    required: ["orderId"]
  },
  execute: async ({ orderId }) => {
    return await api.getOrderStatus(orderId);
  }
});

The tool should call the same trusted application layer used by the normal interface. WebMCP is an interaction surface, not a replacement for authorization or business rules.

Security responsibilities do not disappear

A structured action can be more reliable than screen scraping, but it can also make a sensitive capability easier to invoke. Treat every tool call as untrusted input.

Good rules include:

authenticate and authorize on the server
validate every input again on the server
make read-only and state-changing actions easy to distinguish
require confirmation for purchases, deletion, publication, or account changes
return the minimum necessary data
log important tool calls for audit and debugging
use idempotency protection for actions that must not run twice

Never assume that a tool is safe because it was called through a browser agent.

Start with narrow, high-confidence actions

The best first tool is usually not “control my entire application.” Choose one action with clear inputs, predictable output, and an existing server-side permission check.

Useful candidates include:

search public documentation
check an order status
calculate a quote without purchasing
find available appointment times
save a draft without publishing it

These actions are easier to test than a broad tool that hides many decisions.

How to evaluate a WebMCP tool

Test more than the happy path.

Ask whether the agent:

chooses the tool for the right user request
avoids it for unrelated requests
asks for missing required information
rejects invalid values cleanly
explains a failure without inventing a result
requests confirmation before a consequential action
behaves correctly when the user is signed out or unauthorized

Chrome's developer tooling and Lighthouse work around WebMCP are useful for inspecting registered tools, but application-level tests are still necessary.

A practical adoption plan

Keep the existing human interface fully functional.
Select one narrow action.
Define a clear name, description, and input schema.
Reuse existing server authorization and validation.
Add confirmation for meaningful side effects.
Test successful, invalid, unauthorized, cancelled, and repeated calls.
Treat the implementation as experimental while the API and browser support evolve.

Conclusion

WebMCP points toward a web where agents do not have to guess how every interface works. Sites can expose supported capabilities as explicit tools while preserving their normal human-facing experience.

The opportunity is not to give agents unlimited control. It is to make a small set of user-approved actions clearer, safer, and more reliable.

Sources:

DEV Community