core purpose. tech

insight

WebMCP and the dual-mode website: what leadership actually decides

Core Purpose Tech8 min read

Answer first

There is a widely held expectation that web pages end up as a prompt box. WebMCP is the more modest version of that future: the application stays visible, and a prompt is added as a second way to operate it. Two things have to exist for that to work. Only one of them is yours to build, and whether you build the second one as well is the decision about who controls the agent.

Ask where the web is heading and a version of the same answer comes back: pages give way to a prompt, and the user states an outcome instead of learning an interface. It is a plausible reading of the market, and it is the reading that makes boards nervous, because it implies that the application you have spent four years building becomes a text box somebody else owns.

WebMCP is the gradual version of that transition. The pages stay as they are. A prompt is added next to them, supplied by one of three different sources, and the agent behind it operates the application the user is already looking at. The user can watch it happen, take over mid-task, and hand the next step back. That is the whole idea, and it is a smaller idea than the one it is competing with.

Two components, and only one of them is yours

The first thing to settle in any leadership conversation about this: supporting WebMCP does not mean putting an AI assistant inside your product. Two separate things have to exist, and they do not have to come from the same organisation.

Where a WebMCP agent comes from, and what it callsThree possible agents sit outside the application: an assistant supplied by the browser, an approved extension or agent platform, and an assistant embedded in the product itself. Each calls the same WebMCP tool layer inside the application, which calls the services that already exist and passes a result back. A fourth lane shows the case with no agent available: the tools are declared and nothing ever calls them.Outside your applicationThe browserAn approved extensionAn assistant you embedNo agent availablethe tools are there, nothing calls themYours to buildWebMCP tool layernames · descriptionsinputs · permissionUnchangedServices youalready have■ a call · ○ the result
Your side is the middle box. The agent on the left can come from the browser, from an extension your organisation approves, or from an assistant you build into the product yourself. The fourth lane is the case where nobody supplies one.

Your application declares the operations an agent is allowed to perform. Something else understands the user's request, picks an operation, fills in its parameters and explains the result. The first is an integration job with a known size. The second is a product in its own right, and the interesting decision is whether you build it.

What a declared tool actually is

A tool is a short declaration with four parts, and it is worth seeing the shape of it once, because most of the discussion about agents assumes something far more elaborate.

What a declared tool containsA tool declared by the application has four parts: a name, a plain-language description of what it does, a typed list of the inputs it accepts, and a rule about confirmation. The agent reads the description to decide the tool applies, fills the inputs one by one, and the tool calls the booking service the application already has. Nothing about the booking rules moves into the tool.OutsideAgent reads thedescriptionOne tool, declared by your applicationcreate bookingBooks a garage for a customer, from a dateInputs it acceptswhich garagewhich customerfrom which dateConsequential: a person confirmsAlready existsBooking serviceand its rulesa garagea customera datethe tool describes and validates · the service decides
One tool: a name, a description in plain language, the inputs it accepts, and a rule about who confirms. The agent reads the description to decide the tool applies, then fills the inputs. The booking itself is still made by the service that already makes bookings.

That is real implementation work, and it is thinner than it looks, because it should be an adapter rather than a second implementation of the feature. WebMCP is designed to expose the functions, forms and application logic a page already has. If creating a booking is a service call today, the tool is a mapping onto that call, an authorisation check, and an honest description.

The cost sits in the decisions around it rather than in the code:

  • Which operations are exposed at all, and which stay reachable only by a person
  • Names and descriptions, which are the only thing the agent has to reason over
  • Input validation, because a parameter can now be generated rather than typed
  • Authorisation in the user's own session, not a broader one
  • Confirmation for anything consequential, and who gives it
  • Structured results and errors an agent can act on rather than paraphrase
  • Prompt injection and data exposure, which the specification treats as first-class concerns

Read that list as an integration and security surface, not as metadata added to buttons. The specification explicitly considers tool poisoning, privacy leakage and origin boundaries, which is a fair signal of what the review has to cover before anything ships.

Where the agent comes from

Three places, and the choice is an investment decision rather than a technical one.

AgentYou expose toolsYou build the assistantWhat you give up
Supplied by the browserYesNoControl over the model, the wording and the confirmation flow
Approved extension or agent platformYesNoDependence on a vendor's roadmap and its access rules
Embedded in your applicationYesYesBudget: UI, model, conversation state, logging, cost control
None availableYesNoNothing happens; the tools are there and nobody calls them
The last row is the one to hold onto. Tools without an agent are an API without a client: technically available, invisible to the user.

For a public-facing site aimed at browsers that will eventually ship an agent, exposing tools alone may turn out to be enough, and the annotation is cheap enough to place that bet now. For a controlled enterprise product, where you need consistent behaviour, an audit trail and a known model, an embedded assistant or a single approved extension is the clearer route, and the embedded option is the one with a real budget attached: assistant UI, model provider, conversation state, tool orchestration, authentication context, permissions, confirmations, logging, and rate and cost controls.

Building both is the control decision

Only the tool layer is required of you. The agent is optional in the sense that you need not build it, and not optional at all in the sense that somebody has to supply it. Exposing tools and stopping there is a decision, not the absence of one: it lets whoever the user arrives with drive your application, whether that is the browser vendor, an extension they installed, or the agent platform their employer approved.

Building the second half as well is what buys the control back. Your own assistant is where you decide the wording, the model, when a person has to confirm, what gets logged, and which requests it will not attempt at all. That is the difference between an interface you operate and one you have handed over, and it is why the embedded route exists despite carrying a running cost.

The two are not exclusive, which is the part usually missed. The same declared tools serve your own assistant and any outside agent that turns up later, so building one does not close the door on the others. It also does not close the door to them: what you expose is reachable by any agent that finds it, so the exposure decision stays where it always was, in the tool list and the permission check.

The question for a board is therefore not whether to build an assistant. It is which of your operations you are willing to have driven by an agent you do not control, and whether the ones that fail that test should be exposed at all.

often confusedWebMCP is not the MCP server you may already have, and the difference is where the agent runs

Both describe capabilities as named tools with typed inputs, and one set of definitions can serve both, which is why the two get treated as the same decision. They are not. A server-side MCP client is a separate process with its own credential, and it never sees the page. So if someone tells you the agent problem is already solved because there is an MCP server, this is what that version cannot do:

Who the agent acts as
In-page, WebMCPthe user's existing browser session, same origin
Server-side, MCPits own credential, a second authentication path you build
Page state: filters, selection, an unsaved form
In-page, WebMCPreadable and actionable
Server-side, MCPinvisible
Where the result appears
In-page, WebMCPyour interface, updating while the user watches
Server-side, MCPthe agent's own chat window
Where confirmation happens
In-page, WebMCPyour UI, your terms, your button
Server-side, MCPthe agent client's UI, in wording you do not control
Taking turns with the user
In-page, WebMCPthe point of it
Server-side, MCPnot available
What you can claim afterwards
In-page, WebMCPa person was present and clicked
Server-side, MCPan authenticated call arrived

Both are worth having, and neither substitutes for the other: only the in-page version can share a screen with your user, and only the server-side one works in every client today.

This is not remote-controlled clicking

The distinction matters for anyone who has watched a browser automation demo and concluded that the technology is unreliable. It usually is, and for a reason WebMCP removes.

Imitating a person versus calling a declared capabilityAbove: browser automation works through the interface one step at a time, finding a field, typing, finding the next field, and it stops when a label it was relying on has changed. Below: with WebMCP the agent makes one call that says what it wants, and the application decides what that means, setting its own filters, navigating and rendering the results in its own interface.Browser automation, imitating a personfind the fieldtype a cityfind the pricetype a numberpress searcha label was rewritten here, and it stopsWebMCP, one declared capabilityAgentgarages near Copenhagen, under 1,500Your application decidesset its own filtersmove to the results viewrender the matchesthe site declares the meaning once, instead of the agent guessing it every visit
Above, the agent works the interface a step at a time and stops when a label it depended on gets rewritten. Below, it makes one call, and the application decides what that means.

The effect on screen can look like navigation. A tool can move the user to another view, apply filters, populate a form, start a booking or display a result, and Chrome's documentation describes exactly that: tools execute visibly in the page, so the user sees the work happen inside your design and your branding. What has changed is who decides what the operation means. Your application does, once, rather than the agent inferring it again on every visit.

The user and the agent take turns

A customer looking for a garage to rent shows the pattern better than any diagram.

  • The customer states a goal: a garage near their workplace, large enough for an SUV
  • The agent asks for what is missing: the address, and a monthly budget
  • The agent does the tedious part: searches, filters, sorts, and shows three options
  • The customer takes over: photographs, access conditions, the neighbourhood
  • The customer delegates again: compare the first and third, and show the cancellation terms
  • The application presents the comparison in its normal interface
  • The agent proposes an action: shall I prepare the rental request?
  • The customer confirms, and the application shows the final terms before anything is submitted

No step in that sequence is a chatbot standing in front of a website. The prompt is good at expressing intent. The visual interface is good at comparison, inspection and building enough confidence to commit. The combination is stronger than either, which is the argument the WebMCP project makes with its own shopping example.

Keep the business logic where it is

For anything going to production, three layers, and the middle one stays thin.

Three layers, with the business rules left where they areThe agent layer handles the conversation, the planning and the confirmations. The adapter layer below it holds the tool descriptions, checks the values it was given and checks the user's permission, and holds no business rules of its own. The application services below that hold the rules, unchanged, and are the same ones the ordinary interface and the API already call. Three lanes on the right show what happens: a permitted call passes down to a service, its result travels back up, and a call the user has no permission for is stopped inside the adapter.Wherever the agent livesConversation, planning, confirmationThe layer you add — no business rules hereTool descriptions, validation, permission checkWhat you already have — same rules for every callerApplication services and their rulesallowedresultrefused■ a call · ○ one the user may not make
The adapter describes, validates and checks permission. It decides nothing the rest of the application does not already decide, and a call the user is not entitled to make stops there rather than at a service.

The permission check is the same one every other caller passes. An agent is a third way in, alongside the interface and the API, onto one implementation of the rules. Where that is true, an agent cannot do anything the person it is acting for could not have done by hand, which is the property that makes the rest of the discussion manageable.

Done this way, the WebMCP work is additive and reversible. The standard is in origin trial and will move. An adapter layer that holds no business logic can be rewritten in a sprint when it does, and can be removed entirely if the whole approach fails to find an audience.

The dual-mode website

One window, two ways to drive itA single application window contains the ordinary page, with its filters and its list of results, and a prompt bar along the bottom. The person can set the filters by hand, or type what they are looking for and let the agent call the same capability; either way the same results panel updates in the same window. Below the window, one task runs from left to right and control changes hands four times between the person and the agent.One window, two ways to drive itDirectyou clickDelegatedyou describeFiltersResultsa garage near Copenhagen, under 1,500 a monththe agent's call updates the same pageOne task, control changing handsagent filtersyou lookagent comparesyou confirmthe visual page stays the shared workspace
Two ways in, one set of rules underneath, and a task in which control changes hands several times. Whichever route the user takes, the same authorisation and the same business logic apply.

This is the part worth taking to a board. The likely future is not a choice between the site you have and a blank prompt. It is a site that supports both, where a customer can browse, compare and fill in a form by hand, or describe the outcome and let an agent do the repetitive parts, and switch between the two mid-task.

WebMCP is less about making websites invisible than about making what they can do reachable through intent.

What we recommend

Start with the forms, because that half of the API is declarative HTML attributes and costs an afternoon. Then pick two or three read-only operations, search and comparison rather than anything that writes, and expose those as tools over services you already have. That is enough to learn what the descriptions have to say and where your authorisation model is thinner than you assumed, without putting an irreversible action behind a generated parameter.

Hold the embedded assistant until something forces it. It is the only one of the three paths with a running cost, and the question that decides it is not whether agents are coming. It is whether your users need a consistent, audited assistant that you control, or whether they will arrive with one of their own.

We have taken the first of those steps on this site. The forms here are annotated, no form will submit itself, and what that cost and what it turned up is written down in the companion piece on forms an agent can fill. Deciding which operations belong on the list is the harder half. In our experience it is an afternoon with the people who own the services rather than a project, and it is the same question we ask at the start of any systems architecture engagement: which capability is this, who is allowed to invoke it, and what has to be true before it runs.

Does supporting WebMCP mean we have to build an AI assistant?
No. Supporting WebMCP means declaring your application's operations as named tools. The agent that calls them can be supplied by the browser, by an extension or agent platform your organisation approves, or by an assistant you embed yourself. Only the third is a product you have to build and run.
Is this useful before browsers ship an agent?
Not to end users. Tools with no agent to call them are an API with no client. The case for annotating early is that the work is small, it forces a useful review of your own operations and authorisation, and it is in place when an agent does arrive.
Does the agent click around our interface?
Not in the way browser automation does. The agent calls a capability your application declared, and your application decides what happens: apply filters, navigate, call a service, render a result. The user sees the work happen in the normal interface, which is what makes it reviewable.
Does this replace our website with a prompt?
It is designed not to. The application, the user and the agent share one interface, and the user can take over at any point. The visual page is still where people compare options, read terms and decide, which is most of what a considered purchase or an authority's case handling consists of.
What is the main risk?
Exposing more capability than you meant to. A tool schema is an invitation, and it inherits whatever your authorisation model already allows. Treat the tool list as a security surface, keep consequential actions behind an explicit confirmation by a person, and start with operations that only read.
  1. WebMCP specification, including agent types and security considerations — Web Machine Learning Community Group
  2. WebMCP explainer and use-case examples — webmachinelearning/webmcp, GitHub
  3. WebMCP overview — Chrome for Developers
  4. WebMCP use cases, including navigation and form input — Chrome for Developers

Newsletter

Occasional notes on building systems that hold up

A short email when we publish something worth your time. Architecture, integration, and operational AI in regulated organizations. No cadence promises, no forwarding your address.

explore further

Related reading, capabilities and cases

Related insights

  • Forms an agent can fill: what WebMCP changes

    An agent filling a form today reads the rendered page and infers. WebMCP lets the page declare the same capability as a named tool with a schema. Two attributes on the form, one per field, and no script. The demonstration below runs in this article.

  • Why AI pilots stall before production

    A working demo is not a working system. The difference between AI that ships and AI that stalls is operational integration, not model quality.

Capabilities

  • Systems Architecture

    Designing architectural foundations that allow complex organizations to operate reliably and evolve safely.

  • Operational AI

    AI systems that integrate with existing platforms and workflows, with control, traceability, and operational reliability.