WebMCP, Service-Level MCP or Plain Browser Use: Where Agent Tools Belong

At first glance WebMCP is sensible. A user is already signed in, an agent works inside the browser, and the site can say what actions exist so the agent need not guess at fields and buttons. The discomfort concerns where that interface sits. When effort goes into making an app usable by agents, should the capabilities be exposed by the page or by the services beneath it? And what does a page-level tool interface add to general browser tools?

Those two questions frame the assessment below.

What WebMCP is

With WebMCP, a site registers structured tools that a compatible agent can call via the browser. Each tool states what it does, what inputs it accepts and which code executes it. Registration happens in JavaScript or through annotated HTML forms. Chrome documents the idea as a proposed standard whose origin trial begins with Chrome 149, and the API is liable to shift.

Picture a flight search page. Without WebMCP, an agent reads the page, locates the destination field, sets dates and presses Search. With it, the site could publish a search_flights tool taking a destination and dates. The agent only fills in arguments, and the application carries out the search.

Three routes should be kept distinct: service-level MCP, WebMCP and general browser use. Nothing forces a choice of one, and a single agent may call a service tool for one product, a page tool for another and drive the browser directly for a third.

The architectural worry

A first reaction is that WebMCP drags service concerns into the presentation layer. Searching inventory, changing a booking or placing an order in a typical business application ends at a backend service, and the browser already calls an endpoint that does the job. So why define an agent-facing contract inside the page rather than next to that service?

A natural alternative starts from the service contract that exists, such as an OpenAPI specification or a gRPC definition, and builds the MCP interface on it. The appeal is ownership. The team responsible for the business operation could version, test and govern the agent-facing contract, and interactive agents, batch jobs and scheduled workflows could all use it.

Wrapping an internal endpoint in a page tool also does not make the contract a lighter commitment. Agents receive an operation with expected inputs and behavior, and workflows break if that behavior changes. Wherever the tool is exposed, the team must decide what compatibility and support it promises, and putting the interface in the web tier does not by itself reduce those duties.

Looking closer weakens some of those first assumptions.

• The browser holds real state. An editor may contain an unsaved draft, a live selection or local operations with no worthwhile server counterpart, and calling the client an empty shell ignores all of that.
• Logic need not be duplicated. A tool can invoke the same client function as a button and, through it, the same backend endpoint. The real worry is the added tool contract with its own lifecycle, and the way business rules could pile up around it over time.
• Multi-screen flows are the hard case. Selecting several flights, assigning passengers and validating a booking before submission can be much cheaper if existing client orchestration is reused. A sequence written purely for the agent raises the question of which pieces are presentation and which are business rules. Eligibility and authorization belong in the service, and when the page tool and service tool disagree, someone has to own the mismatch and a shared set of contract checks.
• The service route is harder than it looks. Auto-generating tools from hundreds of API endpoints does not yield a useful agent interface. Descriptions need agent-oriented wording, responses need size limits, certain operations should be merged, and a person must decide what gets exposed.

Maturity matters too. Some experimentation is expected, but an interface built on a changing browser API adds one more source of maintenance work.

The refined position, then, is that a durable business operation is best owned and governed close to the service that implements it, and putting its contract in the page needs a specific reason.

Session reuse versus delegated access

The authentication benefit comes from operating inside a signed-in browser, and WebMCP and ordinary browser use share it. The comparison here sets that convenience against delegated service access. What explicit WebMCP tools add over ordinary browser interaction is a separate matter, covered further down.

When an agent clicks a control on a signed-in site, the application sends its request under the existing session, and a WebMCP tool invoked directly can use the same session. Neither needs a separate delegated grant between the agent host and the service.

The attraction grows across applications. A workflow touching five services might need five grants, five token lifecycles and five sets of integration requirements, plus client registration work that depends on each service. If the user is already signed in to all five sites, reusing those sessions avoids much of that setup.

Calling this free authentication would overstate it. A live session has its own security lifecycle, and being logged in is not consent to everything an agent might attempt. Even so, the integration work saved is real. Prompt injection and unwanted actions are not solved by picking a layer, since both routes need safeguards such as confirmation for consequential operations, with different exposure and enforcement, so each design must assess those risks on its own.

How CIMD narrows the gap

Service-level access is also getting better. Client ID Metadata Documents (CIMD) tackle one piece of OAuth friction: how a brand-new client identifies itself to an authorization server that has never met it. The client uses an HTTPS URL as its ID, and that URL serves a metadata document listing items such as allowed redirect URIs. A supporting server fetches and checks it, which removes the need to register each client and server pair ahead of time. The MCP authorization specification of November 2025 recommends supporting CIMD and puts it ahead of dynamic client registration whenever no preregistered client details exist.

Back in the five-service case, CIMD support on all five authorization servers removes the advance registrations. Authorization requirements and token lifecycles per service stay in place, though existing grants or sessions can reduce prompts, so five new logins do not necessarily follow. The authorization decisions themselves are untouched by CIMD.

Context, lifecycle and discovery

An unsaved document shows the value of local browser state. A tool that edits the selected paragraph of an unfinished draft works with state the service has not seen, which is a more specific reason to expose a page tool than forwarding a backend operation.

The catch is that local state binds the tools to the page. After a user navigates away or closes it, an agent may need to reopen the application and rebuild context first. The login session may well survive the closed page, and what disappears is the unsaved state or the tools that lived there.

Discovery is a separate matter: how does an agent find out what a site offers? Chrome's documented limitations state that the site must be visited before its WebMCP tools are known. A known MCP endpoint can be queried directly with no human interface involved, but locating one from a bare web address is a separate challenge, and OAuth metadata only finds the authorization server for a protected resource already known, with no universal listing of MCP capabilities.

SEP-2127, titled MCP Server Cards, proposes a standard way to publish structured server metadata over HTTP so that clients can discover service interfaces before opening an MCP connection and without operating a human-facing page. That is a promising direction. At the time of writing the pull request is still open, so it is a proposal for the gap and not an adopted solution that can be assumed everywhere.

Neither side has a settled advantage on discovery, since page tools need a site visit while service discovery from an arbitrary address has no universal convention yet. Neither layer guarantees good governance either, because WebMCP tools can be well tested and maintained and service tools can be badly designed. The real question is ownership and which workflows the interface must support.

Browser agents already work without it

It is worth checking what a browser agent can learn without WebMCP. Browser-tool definitions in one coding-agent desktop session preferred accessibility-based element actions where available, using screenshots for visual context or as a fallback, and the accessibility output returned for a documentation page was informative. That is a session-specific observation and not a claim about every version or default.

The integration handed the agent a structured description of the rendered interface, with textboxes, buttons, labels, values and states, and DOM-oriented tools were available for suitable tasks. More of the page arrived as structured text than screenshot-heavy expectations would predict. For a simple search form, the agent might receive something like this.

1 textbox “Destination”, value: “Tokyo”
2 button “Search flights”, enabled

From that, an agent can identify the destination field, click the Search flights button and check the updated state. HTML semantics and accessibility labels already carry much of an interface's meaning. Which view of a page a model receives depends on the integration and not on the model's name, and OpenAI's computer-use documentation shows integrations where screenshots go to the model and actions return through application-provided tools.

The upshot is that agents can operate a site without WebMCP, which reduces what site developers must build. That does not settle whether WebMCP is worthwhile. An accessibility tree lists controls, whereas a well-designed tool can describe an entire operation with its inputs, cutting interactions and guesswork. Where a browser agent works through a form of ten controls, the application could offer one tool for the task. Chrome frames WebMCP as a progressive enhancement and includes an inspector for trying tools out.

No controlled comparison with and without WebMCP tools was run for this assessment, so it is an architectural judgment and not a performance result. A fair verdict would measure task completion, interaction count and elapsed time across several workflows. One successful demo is a fine starting point and does not answer that broader question.

What can be deployed also depends on which interfaces a team controls. WebMCP needs the site's cooperation, and a service integration needs an accessible, authorized service interface. For a third-party application offering neither, ordinary browser use may be the only workable route.

Where this leaves things

The starting points that follow from all this are:

• Service-level tools suit durable business operations, particularly unattended or long-running flows.
• WebMCP fits when local application state matters or when reusing an authenticated client workflow saves a great deal of integration work.
• General browser use covers the cases lacking dedicated tools, above all applications outside the team's control.

Unease remains when WebMCP becomes the default home for capabilities that already have a clear service boundary. Session convenience is a strong implementation argument, and it should not alone determine long-term architecture.

Evidence that could change this view would show, for a particular application, that page-defined tools clearly beat ordinary browser use at lower total cost than building and maintaining a service interface, where that cost includes authorization, maintenance, governance and the workflows the interface cannot cover.

WebMCP is at its strongest where three things coincide: a live authenticated session, valuable local state and client workflows worth reusing. Ordinary browser use also offers session reuse, so the open question is what explicit tools contribute. A page tool that merely forwards an operation to a service still needs a justification for keeping the agent-facing contract on the page.