We let browser agents use our site. They still cannot hit send.
Browser agents are starting to visit websites on people's behalf. Chrome is running an origin trial for WebMCP, a draft standard where a page registers tools an agent can call directly instead of screen-reading the page and guessing at buttons. We shipped a pilot on our site this week. Three tools, one hard rule.
The three tools
get_services returns our service list with a URL and a one-line summary for each. Read-only, marked read-only in its annotations so the agent knows calling it changes nothing.
search_knowledge takes keywords and searches our published notes and guide articles by title and summary. Returns the top matches with URLs. Also read-only.
prepare_systems_review is the one with teeth. Someone tells their agent "get me set up with a systems review from these folks." The tool fills the request form with the details the agent provides, then scrolls the page to the form.
It does not submit. It cannot submit. There is no code path from that tool to the submit button.
Fill but never send
That last tool is the pattern worth stealing. The agent does the typing. The human does the sending. The tool even says so in its response: form filled, NOT submitted, a person must read the entries and click the button.
A power tool comes with a guard over the blade. Not because the tool is bad at cutting, but because the operator decides what gets cut. Same rule here. We want the agent to do the tedious part and we want a human to own the moment something actually leaves.
The form's human-verification step backs the rule up at a second layer. Even a hostile agent that wanted to submit would fail the check that only a person can pass.
Feature detection is the safe rollout
The whole pilot lives in one component. On load it tests for document.modelContext.
On every browser that has never heard of WebMCP, meaning nearly all of them today, it renders nothing and registers nothing. Zero effect on a normal visitor. No flags, no risk, no second code path to maintain.
Two smaller habits from the spec worth keeping. Clamp your tool inputs to a maximum length, since you are accepting strings from software you do not control. We cap ours at 2000 characters. And write tool descriptions like documentation, because they are: the agent reads the description to decide when to call you.
Why bother this early
The trial is young and the API may change under us. Fine. The pilot cost one component.
When an agent shows up shopping on someone's behalf, a site that answers in clean structured calls beats a site the agent has to squint at. We would rather be the first kind and find out early what breaks.