WebMCP Hands Agents Your Site Tools. Who Approves Write?

Why WebMCP Showed Up in Ops Slack This Week

WebMCP is a proposed browser API that lets a page register tools an agent can call by name. Think search_listings or filter_results instead of screenshot-and-guess. Google and Microsoft authors sit on the W3C Web Machine Learning work. Chrome is running an origin trial; the public target people keep quoting is Chrome 157.

It is not the same thing as Anthropic MCP in Claude Desktop or Cursor. Remote MCP attaches tools to your agent session. WebMCP attaches tools to the page you are already looking at, inside the user's browser session. That difference matters when the page can submit a form, change a cart, or send a message.

Early October 2026 coverage is loud for a reason. ChatGPT's desktop browser path already talks about Site tools for agents that can discover page tools. Adoption reports still show thin public deployment on top domains, mostly read-only docs and search helpers. Thin adoption is good news if you sell regulated work. It means you still have time to write the policy before customers ask why an agent clicked Buy.

What Breaks If You Treat Tools Like Buttons

Browser agents that scrape the DOM fail in boring ways: renamed buttons, lazy-loaded modals, captchas. WebMCP tries to fix that with schemas and named tools. The new failure mode is trust. If the page lies about a tool description, the agent can be steered without changing the visible UI.

Security writeups flag the obvious paths. Tool descriptions and tool results are prompt injection surfaces. A consequential tool can submit data the user never typed into a visible field. Extensions that auto-trust annotations make that worse. Google's secure-tools guidance names hints like readOnlyHint and consequentialHint for a reason. Hints are not a substitute for a human gate.

SMB desks feel this in the same places they already fight shadow AI: intake forms, estimate portals, booking pages, and support consoles. If an agent can call create_ticket or send_quote on a logged-in session, you have given it a junior staffer badge. Junior staffers need review. Agents need the same rule.

I keep a sticky note near the monitor for any agent that can act in a browser: browse is not the same as write. If the tool can submit, pay, delete, or export, it sits on the same list as human send. That habit survived every shiny demo this year.

• Treat tool output as untrusted text.
• Mark write tools as consequential, always.
• Require human approval before send or pay.

The Shift: Read-Only First, Writes Behind a Person

The teams that will sleep this quarter ship WebMCP the way they ship APIs: start read-only. Documentation search, product lookup, FAQ retrieval, and status checks are useful and cheap to revoke. Checkout, password reset, wire instructions, and client email stay off the tool list until a named owner signs a review.

Engine politics still matter. WebKit has opposed the idea, arguing agents should use accessibility layers instead of a parallel tool API. Mozilla is cautious about hostile sites and data harvest through tool inputs. You do not need to win that standards fight to set an internal rule: no write tools on customer-facing pages without an approval UX the user can see.

If a vendor sells you 'agent-ready storefront' features that auto-register write tools, ask for the consent model and the audit log. If they cannot show who approved a tool call, you are buying speed and importing incident response.

Playbook: Four Checks Before You Expose a Tool

Keep the response small enough for a Friday standup. Four checks cover most SMB risk without a six-month program.

Check one is inventory. List every page that might register WebMCP or Site tools: marketing site, app, booking widget, partner portals. If you did not build it, ask the vendor in writing.

Check two is classification. For each tool, mark read-only or write. Writes that move money, change account state, or leave the building need a human confirmation step that the user can refuse.

Check three is injection hygiene. Never feed raw tool results into another agent call without a scrub. Treat tool text like user paste from the open web.

Check four is an allowlist for staff agents. Internal Cursor or ChatGPT browser sessions that hit admin consoles should not auto-run consequential tools. Same rule as production: draft free, send gated.

One more practical note for client-facing teams. If your booking widget or estimate portal sits on a third-party domain, your policy still applies. Ask the vendor whether they plan WebMCP or Site tools, and whether write actions can be disabled at the account level. Put their answer in the same folder as your approved-tools list. When finance asks why a mystery agent charge appeared next to a web session, you want a paper trail that names the tool, the page, and the owner who said yes.

• Inventory pages that can register tools.
• Split read-only tools from write tools.
• Gate send, pay, delete, and export.

What Clients Will Ask Next Month

Prospects already ask which AI tools touch their files. Soon they will ask whether your site exposes tools to browser agents, and whether a human still owns checkout and support replies. Have a one-paragraph answer ready.

A clean answer sounds like this: we may expose read-only lookup tools; any action that changes data or sends a message requires a person; we keep an audit of who approved what. That sentence beats a slide about innovation.

If you are not ready to answer, do not enable write tools. Being late to WebMCP is cheaper than explaining an agent-sent quote that never got a human eye.

Write that answer once and reuse it on security questionnaires. Change the tools list when your site changes. Do not wait for a breach newsletter to invent the wording under deadline pressure.

Your Next Step This Week

Open a blank page titled WebMCP policy, October 2026. Write three lines: which domains may register tools, which tools are read-only, and which actions always need a human. Share it with whoever owns the website and the booking stack.

Then pick one read-only candidate (docs search or product lookup) if you must experiment. Leave send, pay, and account changes off the table until the approval UX is real and logged.

If a vendor demos agent checkout this week, ask them to show the refuse button and the audit export. No refuse button, no pilot.

• Write the three-line WebMCP policy today.
• Pilot only read-only tools first.
• Refuse write tools without a visible gate.