A browser agent sees a button and estimates its position. That can work. But a web application can also communicate its meaning more explicitly: this action searches for available appointments, expects a date and returns a list. It is precisely this shift from click position to described tool that makes WebMCP interesting.
As of the documented status, WebMCP is an experimental proposal. The current explainer covers imperative registration via JavaScript and document.modelContext. Declarative HTML form tools are being explored separately and are not currently part of this specification. The Chrome overview page dated 18 May 2026 is therefore no reason to claim a new universal browser feature in October.
A tool starts with a limited action
Our own example is called “find available appointments”. Its job ends with information. It does not create a reservation. The description itself should already make this clear, so that an agent does not turn a search result into a confirmed appointment.
The input contains a date and a service offered. The result names the same reference together with the available time slots. An isolated value such as “10:30” would be weaker: it could belong to a different day or service. A structured result is particularly helpful when its entries can be interpreted unambiguously.
{
"tool": "find_slots",
"input": {
"date": "2030-04-12",
"service": "intro"
},
"effect": "read_only"
}This is our teaching schema, not a WebMCP registration ready to copy. The future date and the service are invented. It shows the contract that an actual implementation would have to specify. For concrete API syntax, the current experimental documentation is authoritative.
Errors need an understandable meaning too
An invalid date, no available appointments and a service that cannot be reached for technical reasons are three different results. If all of them simply produce an empty list, the agent would have to guess the cause. The tool’s response should therefore carry an understandable state and the information needed for the next decision.
The same applies to partial information. Is the search complete, or is data still missing? Does the response belong to the latest request? Has the person changed the date in the meantime? Such questions exist regardless of whether the interface is addressed via a screenshot or through a tool.
A description is not a permission
A correct input schema says what form a request should take. It does not decide whether the caller is allowed to read this information. The application still has to enforce its own rules. A nice-sounding tool name is neither sign-in nor access control.
The transition to booking also needs a meaning of its own. “Search for available times” and “reserve this time for me” have different consequences. They should not quietly merge into a single function. An actual reservation would have to take into account the confirmed item and the intended instruction.
For a first, harmless design exercise, fixed sample data is therefore enough. Describe three response states and work out which next action would be reasonable in each case. This lets you test how understandable the contract is without faking a real booking or an existing WebMCP runtime.
WebMCP is not automatically an existing remote MCP server
The word MCP appears in various technical contexts. An action described on the browser side is not, for that reason alone, the same kind of connection as a remote tool server reachable over HTTP. For a specific connection, what counts is the client, the transport, sign-in and the tools actually offered.
Existing remote MCP access therefore does not prove that a website supports WebMCP. Likewise, an experimental browser proposal does not guarantee that every agent can already use it. This distinction is practical: it prevents a similar name from leading to the wrong integration plan.
The transferable question remains clear. Can an application express which action, with which inputs, has which result and which effect? The more precise this answer, the less an agent has to guess from a position on the screen. Good tool contracts make the room for manoeuvre easier to understand; the application’s rules nevertheless remain its own responsibility.
Sources and status
Research and documentation as of 25 October 2026. WebMCP · WebMCP explainer.
