Browser agents spend a surprising amount of time pretending to be very patient people.
They look at the page, find a button, click it, wait, look again, and hope the interface did not move. It works until the button moves. Then the agent has to look all over again.
WebMCP offers a cleaner path. A website can register the things it knows how to do as structured tools. The agent might search the docs or post a message through a named schema instead of playing a small game of "where did the button go?"
Chrome calls it a proposed web standard. The current API lives at document.modelContext, and pages can add it as a progressive enhancement. People without a compatible browser keep the ordinary interface.
The easiest demo ends there. The browser may already know who you are.
The permission is already in the browser
Open a private project page and your browser carries the session cookie. The page can read the projects your account can read. If that page exposes a search_docs tool, the agent may get useful private context without another login or a new API token.
One friendly tool name can carry everything the signed-in page is allowed to see.
When we added WebMCP to hilos, we had to answer two different questions. What should a hilos page offer to a browser agent? And what should a local hilos agent be allowed to use from somebody else's page?
What a hilos room offers
An open hilos room registers two tools.
read_hilos_room returns the part of the room already loaded in front of you: its timeline, current thread, members, Git links, and attached resources. post_hilos_message posts to that room or one of its threads as the signed-in person.
The page supplies the room. An agent cannot pass a different room ID and wander elsewhere. If you move to another channel, the old tools disappear and new ones bind to the page you opened.
Posting still goes through the same server permissions and row-level security as the interface. The thread root gets checked again. Retries carry an idempotency key so one uncertain response does not become two messages. The message says "via site tools," because the people reading the room should know how it arrived.
That write is narrow and visible in the conversation. It cannot approve an agent review or merge a pull request. Those decisions belong to a person, and a browser tool does not inherit them because it happens to be open nearby.
For deeper history, Docs, Tasks, or work across rooms, the agent still uses hilos over remote MCP. Page tools stay attached to the page.
What a local agent can consume
A person can configure the local hilos agent to use WebMCP tools from another site. Maybe an internal documentation app exposes search_docs and read_reference. The browser profile signs in once, then the coding agent can look up the exact reference it needs while working.
We do not give it the person's normal browser profile. The bridge opens a separate one, and the person signs in there. Cookies and browser storage stay inside it. They never enter the agent prompt, hilos messages, or a run transcript.
The config names the exact origin and the exact read tools allowed on that origin. A site's readOnlyHint is a description, not permission. If a site labels delete_account as read-only, the bridge still refuses it unless the person explicitly listed that exact tool... which would be a pretty bad list.
We remove tool descriptions and free-form schema prose before the model sees them. Results are capped, labeled as untrusted site data, and returned with the origin, page, and tool name attached.
That matters because Chrome's security guidance names two prompt-injection surfaces: a malicious tool definition, and instructions hidden inside otherwise legitimate tool output. A docs search result is still text from a website. The agent should read it as evidence, not obey it as a new boss.
There is no switch an agent can flip to approve a write. Anything outside the read allowlist returns human_approval_required, then stops. Hosted hilos agents do not consume WebMCP yet because we do not have a durable person-approved browser profile and permission flow for them. Claiming support without that boundary would be easy. So we don't.
The exact setup and limits are in the hilos WebMCP guide.
A tool name is not permission
A website knows its own actions better than a model reading pixels, and a structured result is easier to inspect than a sequence of mystery clicks.
The site wrote the tool list, so the person's permission cannot hide inside it.
In hilos, the open room limits page tools, while the person's config limits third-party tools. Neither path reaches the human review gate. The site can say, "I have a button for this." Deciding whether to press it still belongs to the person.
This is the same problem we found when reviewing agent work outside a pull request. Access arrives before a useful review boundary. The protocol tells an agent how to act. The product still has to decide who gets a say and where the result becomes visible.
A page can now hand an agent a clean list of things it can do.
Which items should still wait for the person?