Chrome WebMCP Continuation Tokens for Multi-Page Flows

If you've tried exposing a checkout as a tool in Chrome WebMCP, you've probably hit the same wall everyone does: the moment your tool navigates to the next page, the call ends. The agent gets no result, no confirmation and no idea whether step two worked. On October 2, the WebMCP community group merged an explainer for continuation tokens that's meant to fix exactly that.

Ten days later, WebMCP creator Alex Nahas published an essay on what comes next: continuations, human handoffs and agent identity. None of it has shipped yet. But if your site has any flow that spans more than one page, it's worth understanding now, because it changes how you should structure tools today.

TL;DR

Today, a Chrome WebMCP tool call lives and dies inside one document. If it triggers a navigation, the agent gets null back instead of a result.
The continuations proposal adds requestToken() and resumeTool() so one tool call can carry on across same-origin pages, such as shipping, billing and confirmation.
You don't need to wait for it. Clean tool boundaries, preventDefault() on agent submits and honest safety hints work now and make adopting continuations easy later.

What changed in Chrome WebMCP this month

WebMCP lets a site "expose JavaScript functions and HTML forms as structured tools for agents to discover and call," as Nahas puts it. Google opened an origin trial in Chrome 149 after announcing it at I/O in May, so sites can turn it on for real users with a token instead of asking them to flip a flag (PPC Land).

The gap was always multi-page work. The imperative API docs say it plainly: executeTool() returns the result, or null when a navigation is triggered. The continuations explainer describes the same limit from the other side: each call runs in a single document with a single Promise, and if the tool navigates, "the original tool request is ended."

The fix landed as PR #327, merged on October 2, 2026. Related work is moving in Google's tooling repos too: a PR integrating tool execution tokens into webmcp-tools is merged, and continuation support in the inspector extension is still a draft. That's a clear signal of direction, not a shipped feature.

Why multi-page flows break agents

Think about how most checkouts are built. Cart, shipping, payment and review often live on separate URLs. To a person it's one task. To a WebMCP agent today, it's four separate tool calls, and the agent has to rediscover tools on each page, guess which one comes next and hope the state carried over.

That's fragile in ways you'll feel in practice:

Silent failures. The agent can't tell a successful navigation from a broken one, because both return nothing.
Re-planning on every page. Each new document means a fresh getTools() call and another round of model reasoning, which is slower and gives the agent more chances to pick the wrong tool.
Lost context. Anything the first tool knew (the chosen shipping method, a coupon) has to be stashed somewhere the next page can find it.

The explainer uses a clothing store as its example: a multi-page checkout plus a same-origin iframe for virtual try-on. Both need a single tool call to keep going in a different document.

How continuation tokens work

Here's the proposed shape, quoted from the explainer. The execute callback gets an invocation object, and ModelContext gains a way to resume:

interface ModelContextToolInvocation {
  Promise<DOMString> requestToken();
}

partial interface ModelContext {
  Promise<undefined> resumeTool(DOMString token, ToolExecuteCallback callback);
};

The flow has three steps:

Request. Before navigating, the tool calls requestToken(). That tells the agent the tool isn't finished yet.
Transfer. Your code passes the token to the next page, for example as a query parameter.
Redeem. The next page calls resumeTool(token, callback). The browser runs the callback again with the original input. It can request another token and keep going.

In practice it might look like this. Treat it as a sketch, since names can change before anything ships:

// shipping page
execute: async (input, { invocation }) => {
  const token = await invocation.requestToken();
  location.href = `/checkout/payment?ct=${encodeURIComponent(token)}`;
}

// payment page
const ct = new URLSearchParams(location.search).get('ct');
if (ct) document.modelContext.resumeTool(ct, payStep);

The trade-offs to know

The guardrails are tight, which is good. Tokens are single use, bound to the origin and the same browsing context, and revoked if the agent abandons the task or the user gives new instructions. The explainer suggests a lifetime of about 60 seconds at first. It also warns that the token carries the tool's input, which can include private data, so don't log it. Open questions remain, such as whether a token survives a cross-origin hop to a payment provider.

Elicitation and agent identity: the other half

Continuations solve plumbing. Nahas's essay points at two harder problems.

Handing off to a human

Sometimes a flow needs the person: a sign-in, a clarifying question, an approval. An elicitation proposal explores how a site can request that input in local and remote browsing. Nahas is firm that approval has to reflect a real human decision, and that an agent clicking your page's own Approve button doesn't count.

Knowing which agent is acting

"A login tells the site which user is there," he writes, not which agent is acting or what it's allowed to do. Trusting one assistant shouldn't mean trusting every agent in that browser. Persisting per-agent permissions is still being discussed, so there's no mechanism to build against yet.

Here's how the three pieces compare right now:

Proposal	Problem it solves	Status (mid October 2026)
Continuation tokens	One tool call across same-origin pages	Explainer merged; tooling in progress
Elicitation	Asking the human to answer, sign in or approve	Open proposal
Per-agent permissions	Telling agents apart under one login	Discussion stage

How to prepare your site now

You can't ship continuations yet, but you can get ready for them:

Map your multi-page flows. List every task that crosses a navigation: checkout, booking, signup, quote request. These are your future continuation candidates.
Keep tools on one page where you can. If a form can return a result without navigating, do that. In the declarative API, check e.agentInvoked, call preventDefault() and return a result with e.respondWith().
Mark irreversible actions. Set consequentialHint: true in a tool's annotations for anything that books, pays or deletes, so agents can ask the user to confirm.
Design state you can hand over. Make sure step two can rebuild its context from the URL or server state, because that's exactly where a token will travel.
Watch tool changes. Listen for toolchange on document.modelContext so your own tests catch tools that vanish between steps.
Test with the inspector. Google's Model Context Tool Inspector lets you call tools by hand and validate their JSON Schema.

Before you change anything, it helps to know where you stand. A free AgentReady scan checks the Browser Readiness pillar, including whether your forms expose WebMCP tools and whether those tools are discoverable, so you'll see which flows agents can't use yet.

Here's what a single-page declarative tool looks like:

<form toolname="get_shipping_quote"
      tooldescription="Returns shipping options and prices for a postcode."
      action="/shipping/quote" method="post">
  <input name="postcode" required
         toolparamdescription="Destination postal code">
  <button type="submit">Get quote</button>
</form>

Check your own site

This topic sits in Browser Readiness, which is 40% of the Agent Readiness Score. That pillar looks at WebMCP form tools, tool discoverability, ARIA and landmarks, and heading structure. A low score there usually means agents are left to click through your forms visually, which is exactly where multi-page flows fall apart. Our WebMCP implementation checklist for React and Next.js covers the setup, and a single-page scan is free and takes about a minute. Scan your site free.

Key takeaways

A Chrome WebMCP tool call currently ends when the page navigates, and the agent gets null instead of a result.
The continuations explainer, merged October 2, proposes requestToken() and resumeTool() for same-origin, multi-page tasks.
Tokens are single use, origin bound and short lived, but they carry the tool's input, so keep them out of logs.
Elicitation and per-agent permissions are still open proposals, so don't build on them yet.
Single-page tools, honest consequentialHint flags and portable step state are the best prep you can do today.

FAQ

Does Chrome WebMCP support multi-step checkout yet?

Not as a single tool call. Today each WebMCP tool runs inside one document, and if it triggers a navigation the agent receives null rather than a result. Continuation tokens are a proposal, with an explainer merged on October 2, 2026, to let one call continue across same-origin pages. Until that ships, agents chain separate tools page by page.

What is a WebMCP continuation token?

It's a one-time string a tool requests before navigating. The site passes it to the next same-origin page, which redeems it with resumeTool() so the original tool call keeps running there. Requesting a token tells the agent the task isn't finished. Tokens are origin bound, expire quickly and are revoked if the agent abandons the task.

Is WebMCP available to real users in Chrome?

Yes, through an origin trial that started in Chrome 149. You register your site for a trial token, which turns on the API for visitors without them changing browser flags. For local testing, developers can still enable the WebMCP testing flag.

Should I wait for continuations before adding WebMCP tools?

No. Single-page tools work now, and the groundwork you lay makes continuations easy to add later. Start with forms that can return results without navigating, flag consequential actions, and make each checkout step able to rebuild its state from the URL. That's the same structure a continuation token will rely on.

Pick your one longest multi-page flow this week, sketch where each tool boundary should sit, and check whether its forms are visible to agents today. Run a free AgentReady scan.

Chrome WebMCP Continuations: Fix Multi-Page Checkout for Agents