Persistent tools via workers

Start with this issue’s linked WebMCP Permissions Policy documentation and the related discussions in issues #199 and #167. Map persistent execution, registration, and headless service-worker tools against the permission and navigation constraints described. Done means the scope is agreed and a concrete worker-based API design answers how pending tool calls survive document navigation and reconnect to an agent.

This has been raised a few times in side discussions, but the notion of running tools in workers to support tool execution that survives document navigations deserves its own dedicated issue.

I think WebMCP + workers means a few things, and solves a few different problems, so I'll try and enumerate all of the motivations below so we can see what's in scope and what's not.

1. Persistent tool execution

WebMCP tool execution is tied to a document, so if a tool does a bunch of work but the page navigates away (could be the agent, could be the tool itself), execution is basically lost and has to start over on the next page. By then, it might not be able to give a response back to the agent, since the new document is kind of "starting over", and doesn't know about the pending execution that just died.

In https://github.com/webmachinelearning/translation-api/issues/18, other folks in the agentic space lay out a partial motivation that also applies to WebMCP:

The Motivation: The "Navigation Tax" on MPAs

AI tasks tend to be uniquely heavy, expensive, and long-running. In an MPA, every link click is a "hard reset" that destroys the current document context, and everything that goes with it, AI tasks included...

If we don't provide a way to maintain an active task across a same-site navigation, MPA developers are forced into a corner: either waste compute by restarting tasks on every page load and hoping it finishes in time, or force a shift to Single-Page Application (SPA) architectures just to make AI UX more viable. Finding a platform-level solution to keep these tasks alive safely seems critical for web-wide adoption of AI.

For WebMCP, we basically substitute "AI tasks" with "Tool execution invoked by AI". You can easily move the meat of "heavy" tools over to workers by making your WebMCP tool a thin wrapper around code that just postMessage()s a worker. But the real problem is when the document hosting the actual tool navigates and the next document connects with the worker to pick up its "tool result", the new document has no way of sending this back to the agent, to "resume" now-dead tool call.

We can solve this by creating some API that lets new documents "re-connect" to pending agent tool calls, and provide responses to them. Or we can solve this by allowing workers to run tools that execute beyond a document's lifetime.

Note that the Writing Assistance APIs have avoided this so far. Since Permissions Policy isn't spec'd for workers, APIs that rely on it basically don't work there, and WebMCP is one of these APIs along with Writing Assistance. So to support tool execution in interesting contexts like shared and service workers, we need some solution to this. I've discussed potential designs for this with @zcorpan and others, but we need to hash something concrete out.

/cc @kenjibaheux and @michaelwasserman

2. Persistent tool registration

In addition to tool execution beyond a document's lifetime, worker integration provides tool registration beyond a document's lifetime. This has been discussed in point (4) of #199 (and to a lesser extent #167, which is also aimed at reducing tool registration thrashing).

Built-in agents see a whole tab, and struggle[^1] to understand why tools would go in and out of context so much while moving through a site. By allowing workers to register tools, we let tool declarations survive beyond a document's lifetime, which reduces tool churn. However, as discussed in https://www.w3.org/2026/06/25-webmachinelearning-minutes.html#10003 it's not clear how bad the "tool churn" problem really is. From our experience, built-in agents have a "pull" relationship with tools, not a "push" one, so we probably need to hear more from built-in agent developers (or even framework experts like @sdras, who raised this in #199) about how bad this problem is and how much persistent registration would buy us.

/cc @khushalsagar for any insight about Gemini-in-Chrome, and @bwalderman and @victorhuangwq for Copilot-in-Edge.

3. "Headless" tools

Related to the above: if we supported service worker tools, this unlocks use cases where a built-in agent can run tools on sites with service workers in a "headless" fashion. Example: you ask your built-in browser agent to go to your calendar and find tomorrow's meeting, and send the zoom link to Bob. If calendar.google.com and gmail.com had service workers with get_event_details() and send_email() tools respectively, the agent wouldn't need to physically open tabs and render site UI to accomplish this task.

This is really straddling the line between the fully headless MCP world, and the very not-headless co-browsing UI case that WebMCP was designed for. It's in the middle because it's headless-but-still-web, and not server-side MCP. It's unclear what the market appetite is. For example, sites might ask "why would I implement headless service worker tools when I already have an MCP server that the agent can reach out to??"

With all of that said, how do people feel about the motivations/problem enumeration above, and the value that worker integration provides?

[^1]: I only have Google-internal evidence to cite, where we had to be extra careful when prompting the model to help it understand that tools are dynamic, and can disappear for any reason. Further, we told it that tools are not "site-global" but rather "page-bound", which contributes to how often they leave and come back into view.