WebMCP: The Web Finally Gets an Agent API

Every agent that has ever tried to use your website has done it the same degrading way: read the rendered page, guess which pixels mean what, and click things. The agent is reverse-engineering your interface at runtime because you never gave it an alternative. WebMCP is the first credible attempt at an alternative — a way for a page to say "here are the things you can do here, here is what each one needs, call this one."

The problem with driving the DOM

Agents currently accomplish tasks on websites by simulating a user: locate the search box, type, click, wait, read the results, find the button, click it. This is bad for both sides, in ways worth enumerating because each one is a separate cost.

It is brittle. Your redesign is their outage. A CSS class rename, a reordered form, a new interstitial — any of it breaks an agent that had learned your layout. You will not know it broke, and you did not agree to keep it working.

It is invisible to you. DOM-driving produces no signal you can act on. It looks like a session with slightly odd timing. You cannot count it, segment it, rate-limit it separately, or decide anything about it, because you cannot see it.

It is indistinguishable from abuse. A well-intentioned agent filling a form on a user's behalf and a credential-stuffing script look similar enough that defensive infrastructure treats them the same. Legitimate agents get caught in bot mitigation; you lose customers and never find out why.

It forces inference. The agent has to derive intent from visual layout — what this button does, whether this action is reversible, which of these three similar-looking forms is the right one. Every inference is a chance to be confidently wrong on a real user's behalf.

None of that is fixed by better models. It is fixed by the site declaring what it offers.

What WebMCP actually does

The shape of it, in prose — and deliberately without example code, because the API surface is in flux and wrong code is worse than none:

A page registers tools with the browser. Each tool has a name, a human-and-model-readable description of what it does, a schema describing its inputs, and a JavaScript function that performs it. An agent operating in that browser — the user's assistant, a browser-integrated agent, an extension — discovers the tools the current page has declared and calls them by name with structured arguments. Your function runs in your page, in your JavaScript context, with your existing session and your existing code paths. It returns a structured result rather than a repainted screen the agent has to re-read.

The name is deliberate: this is the Model Context Protocol idea — tools with declared schemas that a model can call — relocated into the browser page rather than a separate server.

Two consequences follow immediately and are the whole reason this design is interesting.

Authentication is already solved. The agent operates inside the user's authenticated session. There is no OAuth flow, no API key, no token exchange, no separate account linking. If the user can see it in their browser, the agent acting for them can reach it. Anything the user cannot see, the agent cannot reach either — the permission model is the one you already built and already test.

Your existing app is the implementation. A tool handler calls the same functions your buttons call. You are not building and maintaining a parallel API; you are labeling entry points into the one you have.

WebMCP or an MCP server?

They are not competitors, they answer different questions. The deciding factor is where the agent is and whose session it is in.

The rule of thumb: if a human is present and logged in, WebMCP is the natural fit and enormously cheaper. If the work happens without a person sitting there — nightly syncs, server-to-server integration, agents acting across many users' data — you need a real MCP server, and no browser-side mechanism will substitute for it. Plenty of organizations will end up wanting both, exposing overlapping capability through each, and that is fine.

The interesting part: your tool surface is a design artifact

Here is what most coverage of WebMCP misses. Once agents call declared functions instead of clicking pixels, the set of functions you declare becomes a designed product surface — with naming, granularity, error semantics, and an intended audience that is not human.

The reflexive move is to expose your internal API as tools, one-for-one. This almost always produces a bad agent experience, for a reason worth stating directly: your internal API is decomposed around your data model, and an agent is trying to accomplish a user's task. Those decompose differently.

An internal API might offer create-cart, add-item, set-quantity, apply-promotion, set-shipping-address, and submit-order. An agent asked to "reorder what I got last month" must now sequence six calls correctly, handle partial failure in the middle, and know things about your domain that it can only guess at. A tool called reorder-previous-order, taking an order reference and returning a confirmation or a specific reason it could not proceed, is one call, and the failure modes are yours to handle rather than the agent's to improvise.

Practical guidance for that surface:

Name tools after intents, not endpoints. The name and description are the entire discovery mechanism. An agent decides whether to call your tool based on whether the description matches what it is trying to do. Write descriptions the way you would write them for a competent new colleague who has never seen your product.

Choose granularity by task, not by table. Prefer one tool that completes a recognizable unit of work over five that must be chained. Chains are where agents fail, and each additional required call multiplies the chance of an abandoned half-finished state on your side.

Make errors instructive. "Invalid input" tells an agent nothing and it will retry the same thing. "Quantity exceeds the 10-unit limit for this item" tells it what to do next, and often lets it recover without bothering the user. Error strings in an agent-facing surface are functional, not decorative.

Say what is irreversible. If a tool charges a card, cancels a subscription, or deletes something, the description should say so plainly. Agents pass descriptions to models that reason about risk, and many assistants will explicitly confirm with the user before calling something described as destructive. This is free safety, and you only get it if you write it down.

Do not expose everything. The right surface is the set of tasks users actually delegate, not a mirror of your feature list. A large tool surface is harder for an agent to select from correctly, and every declared tool is an authenticated entry point you now have to defend.

Security: this is an authenticated surface

Say that again, because the framing "it's just some JavaScript on my page" leads people astray: a WebMCP tool is an authenticated entry point into your application, invoked by a caller you did not write, based on instructions it may have picked up somewhere you cannot audit.

Prompt injection is the concrete threat and it is not hypothetical. An agent operating in a browser reads content from pages, and content is instructions to a language model. A hostile page — a different tab, an embedded widget, a comment on a forum, an email rendered in a webmail client — can contain text crafted to redirect the agent's behavior. That agent then arrives at your page carrying an objective the user never gave it and calls your declared tools with the user's full authority. Brave's security research on agentic browsers has documented both indirect injection through page content and "unseeable" prompt injection delivered through screenshots, where the injected text is imperceptible to a human looking at the same pixels the model is reading.

What follows for tool design:

• Treat every tool invocation as untrusted input from the public internet, because functionally that is what it is. Validate arguments server-side. The declared schema is a hint to the agent, not a security control.
• Keep destructive and financial operations behind human confirmation in your own UI, not behind a flag you trust the agent to respect. If a tool moves money or deletes data, the confirmation should be something the person sees and acts on.
• Apply your normal server-side authorization on every call. The tool handler running in the user's session does not mean the operation is permitted; check it as you would any request.
• Rate-limit per account, per operation. An agent in a retry loop is a load pattern you should survive without a human noticing.
• Log tool calls distinctly. This is the first time agent activity is legible to you — instrument it from day one rather than retrofitting later. Our measurement guide covers what agent-side signal is worth capturing.

Status, honestly

WebMCP is a Community Group draft, which in W3C terms means interested parties are working on it, not that anything has been standardized. Google and Microsoft co-editing it is a strong signal — those two ship the browsers most people use — but it is not a commitment, and the origin trial exists precisely to find out whether the design survives contact with real sites. Origin trials end. Some graduate; some quietly do not.

The reason to pay attention anyway is that the underlying pressure is real regardless of which specification wins. Agents are arriving inside real browser sessions with ordinary user-agents, in numbers that are growing, and they are currently reduced to guessing at your interface — a situation examined from the traffic side in Atlas is dead, agentic browsing isn't and from the legal side in the court just ruled your agent is you. Something will eventually let sites declare their capabilities rather than leaving them to be inferred. WebMCP is the most credible current candidate, and the design thinking it demands — what are the tasks, what are the tools, what is dangerous — is work that holds its value whatever the API ends up looking like.

References

• W3C Web Machine Learning Community Group, WebMCP explainer and draft
• Chrome for Developers, Origin trials
• Brave, "Unseeable prompt injections in screenshots and further model vulnerabilities"
• Brave, "Comet AI browser can get prompt injected from any site"
• Model Context Protocol specification