What I Learned Building Multi-Origin WebMCP Execution

In one sentence: A WebMCP tool may be local to one page, but a useful user task often is not. Once execution crosses origins, the consumer becomes responsible for continuity, timing, evidence, and clear action boundaries.

Most WebMCP examples begin with the clean case: a user opens a site, an agent discovers a structured tool, and that tool executes on the same page. That is the right place to learn the API. It is not where the architecture becomes difficult.

I wanted to know what happened when one user request could not be completed by one provider. So I built a browser consumer that could move through four independently hosted provider surfaces, discover tools in each live page, carry state across navigation, and execute a mixture of information-gathering and state-changing actions. I also built a separate flow in which design conformance itself was exposed as an executable WebMCP tool.

The demonstrations worked. More valuable than the demos, though, were the assumptions they forced me to discard.

A narrow definition of multi-origin

I use multi-origin here in a deliberately narrow, practical sense: one browser consumer navigated among four different provider origins and interacted with tools exposed by each provider through the same WebMCP interface. The providers kept their own pages, sessions, application logic, and tool implementations. The consumer kept the user's compound task and the cross-site journey state.

That is not a claim of universal compatibility. It is a working interoperability demonstration across a controlled set of provider surfaces. The distinction matters, especially while WebMCP remains an evolving Draft Community Group Report rather than a W3C Standard.

What the four-provider flow actually did

The consumer accepted a compound request by text or voice, translated it into an ordered itinerary, navigated to each provider, waited for the relevant surface to become available, discovered the tools registered on that page, matched the next itinerary step to an available tool, and returned structured results to the journey state before moving on.

Some tools only read or transformed information. Others represented actions that could change application state or create a commitment. Treating those as one undifferentiated category produced an architecture that looked simpler on paper and was less honest in operation.

A compound request moving through four live WebMCP provider surfaces while the browser consumer preserves the itinerary.

Lesson 1Discovery is local

The first important constraint was also one of the easiest to overlook: a browser consumer does not begin with a universal catalog of every tool on the web. It knows what a provider exposes after it reaches the relevant page and that page registers its tools.

This changes the role of an itinerary. A cross-site plan cannot simply say "use Provider A." It needs a resolvable destination at which the required capability can actually be discovered. The provider's landing page and its tool-bearing route may not be the same thing.

In my test environment, pointing the journey at the wrong route produced a perfectly reachable page with no useful tools. Nothing was technically "down." The consumer was simply standing in the wrong room.

Lesson 2The URL is part of the capability contract

Developers tend to describe a capability by tool name and schema. Multi-origin execution taught me to include location and lifecycle in that mental model. A capability is not only what a tool does. It is also where the consumer can discover it, when it becomes available, and how long it remains callable.

That means provider integration records need more than a homepage. At minimum, they need the tool-bearing route, the expected origin, and enough readiness information for the consumer to determine whether discovery has actually completed.

Lesson 3Trial and permissions configuration must be true at the provider

In the origin-trial environment used for this build, a correctly configured consumer could not compensate for a provider origin that was not eligible or configured to expose the tools. The capability lived with the provider surface. Each participating origin had to meet the browser's requirements on its own terms.

This sounds obvious after the fact. It was not obvious while debugging a multi-site chain, because a failure several steps into the itinerary can look like consumer state loss, route drift, delayed registration, or model confusion. Configuration failures need to be distinguishable from discovery and execution failures.

Lesson 4Navigation destroys assumptions

WebMCP tools are tied to a live browsing context. Navigation changes that context. The tool set available on one page should not be treated as a durable global inventory, and references captured before navigation should not be assumed valid afterward.

The reliable pattern was simple: preserve the journey outside the provider page, navigate, wait, rediscover, then execute against the current surface. The consumer owns continuity; the provider owns the local capability.

This separation became one of the clearest architectural boundaries in the project. Without it, every hop risks becoming a fresh conversation with no trustworthy connection to the request that started the journey.

Lesson 5Page readiness is part of execution

A page can be visually present before its tools are registered. It can also register tools before the application state required by those tools is fully ready. In a one-page demo, a short delay can hide this. Across several origins, timing errors accumulate and become intermittent failures.

A consumer therefore needs an explicit readiness strategy rather than a generous sleep timer. It should know whether it is waiting for navigation, tool registration, application state, authentication, or a provider response. Those are different conditions and should produce different diagnostics.

Lesson 6Structured schemas do not eliminate semantic variation

JSON Schema gives tools a common structural language, which is enormously useful. It does not make independently designed providers use the same names, units, defaults, or result shapes.

One provider may use date; another may use appointment_time. One may return a clean identifier; another may return a human-readable sentence. Required fields can mean different things. Currency and quantity may be explicit on one surface and implied on another.

The consumer still needs disciplined normalization and error handling. A schema can tell you that an input is a string. It cannot, by itself, tell you that two providers mean the same thing by that string.

Lesson 7Read actions and state-changing actions need different treatment

Looking up availability is not the same kind of event as booking an appointment. Inspecting a design is not the same as applying a change. A useful consumer should know which operations gather information, which prepare a possible action, and which actually change provider state.

That distinction affects user communication, retry behavior, error recovery, and evidence. A read can often be repeated safely. A state-changing action may create a duplicate, incur a cost, reserve scarce inventory, or trigger an external workflow.

Lesson 8Tool selection is not user authorization

An agent choosing the correct tool does not establish that the user approved the action the tool will take. Discovery answers "what can this page do?" Tool selection answers "which capability appears relevant?" Neither question, by itself, answers "did the user authorize these material terms?"

Even before choosing a specific control design, keeping those concepts separate makes a system easier to reason about. It also prevents a polished itinerary from being mistaken for consent.

Lesson 9Completion needs provider evidence

Model narration is useful for the interface, but it is not authoritative evidence that an action occurred. Preserve a structured provider response, confirmation identifier, updated state, or explicit error so intention, an attempted call, and provider completion remain distinct.

Lesson 10WebMCP tools are broader than commerce

The second public walkthrough exposes design conformance as an executable WebMCP capability. A browser consumer sends the current design state to check_design_drift, receives structured findings, and uses the result inside the live workflow.

That experiment was useful because it moved the conversation away from shopping and booking. A WebMCP tool can expose governance, validation, inspection, accessibility checks, policy evaluation, or any other capability that belongs in the page's live application context.

Design conformance exposed as check_design_drift, an executable WebMCP tool inside the browser workflow.

A practical multi-origin test checklist

• Navigate to the exact route that registers the required tool, not merely the provider homepage.
• Verify that every participating origin satisfies the current browser, isolation, trial, and permissions requirements.
• Treat tools as page-bound and rediscover them after every navigation.
• Distinguish page load, tool registration, application readiness, authentication, and execution readiness.
• Validate required inputs, units, defaults, and result shapes for each provider rather than assuming schema names are semantically equivalent.
• Keep the compound request and itinerary state outside any single provider page.
• Classify tools by consequence: read, prepare, reversible change, or commitment-producing action.
• Do not treat tool selection as proof of user authorization.
• Record structured provider evidence for each completed, blocked, or failed step.
• Test negative paths: missing tools, wrong routes, delayed registration, invalid inputs, navigation failure, rejection, and ambiguous provider responses.
• Run the same itinerary across more than one model or adapter if the consumer depends on model-generated tool arguments.
• State the limits of the demonstration. A successful controlled hop is evidence of a working path, not universal interoperability.

What still needs work

The four-provider build made the remaining questions more concrete. How should consumers learn which route on an origin exposes a capability? Should providers publish lifecycle or readiness hints? How should cross-origin journeys describe recoverable versus commitment-producing actions? What evidence should a provider return so a consumer can distinguish preparation, execution, and completion? Which conventions belong in the standard, and which belong in consumer policy?

There is also a broader interoperability question. A common API is necessary, but real composition depends on conventions around naming, semantics, state, permissions, errors, and evidence. Those conventions will emerge only when developers push beyond isolated demos and report where independently built surfaces stop fitting together.

The larger lesson

WebMCP's promise is not simply that an agent can call a function on a webpage. It is that the web can remain the place where providers own their interfaces, sessions, permissions, and application logic while agents interact through capabilities the providers deliberately expose.

Multi-origin execution makes that promise more demanding and more interesting. The consumer is no longer just a tool caller. It becomes an orchestrator responsible for continuity across temporary local capabilities. The provider is no longer just a destination. It becomes an active participant that declares what can be done in the current browser context and returns evidence of what actually happened.

The four-provider hop worked. The harder and more useful result was learning exactly what had to be true for the hop to mean anything.

References

• WebMCP — Chrome for Developers. Official overview, implementation constraints, security, and permissions guidance.
• WebMCP Draft Community Group Report. Current specification and status.
• When to use WebMCP and MCP. Chrome's comparison of browser-local WebMCP and backend MCP.

About the author

Kristina Baldovino is the founder of Ziola LLC, where she builds browser-based agent tooling, WebMCP consumers and providers, and design-governance infrastructure. Her work focuses on making agent actions inspectable, interoperable, and grounded in the live web context.