Repository navigation
Persistent tools via workers #212
Description
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 webmachinelearning/translation-api#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 struggle1 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?
Footnotes
-
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. ↩
Activity
khushalsagar commentedon Jun 26, 2026
For "Persistent tool execution", it seems like those are 2 separate problems?
A WebMCP tool call could involve a cross-document navigation to fetch the result even when no local AI execution needing a worker is involved. The declarative variant of the API where the default form action is executed does this by-design. We need to provide authors a way to let a tool call start on a Document and provide the result on another same-origin Document committed from a navigation. Details on how long this tool call can persist (definitely yes for server or client-side same-origin redirects, not after a cross-origin navigation has committed, unsure what to do if there's a cross-origin server-side redirect). This use-case shouldn't require using a worker.
A WebMCP tool call might require multiple cross-document navigations such that some state has to be persisted after each navigation, this could be done in session storage. Or it could involve compute intensive client-side work (potentially using an on-device model) that the author should be able to offload to a worker that persists across navigations. But that seems like an internal detail of the tool execution, the tool itself can still be tied to a Document.
For "Persistent tool registration", the fundamental issue is that WebMCP API is designed to be a thin layer on top of existing functionality in Web applications. You can annotate existing functions in your application with tool schemas or add a few attributes to DOM elements. But this existing functionality is tied to application state which changes based on the route/view/page loaded in the browser. And the model doesn't have a way to know which page to load/navigate to for accessing some functionality.
Ideally we'd have a global registry of tools available across all route/view/pages on the site (the way MCP servers work by design). If we could have such a registry then the simplest way to express it would be
.well-knownfile that tells the browser which page to navigate to for accessing a tool. So when a model invokes a tool the browser navigates to that page and runs the tool. Having the author register all tools in a worker feels like a more complicated way of doing this in user-land.But whether you do this with a declarative manifest or a worker, the hard part is helping authors build this registry such that it can stay in sync with the actual functionality that's spread across the web application. This idea is in tension with the goal of "this API is just a few annotations over existing functionality", especially in the context of the declarative API. I don't really have a good answer here...
For "headless" tools, your analysis aligns with my thinking: "the agent wouldn't need to physically open tabs and render site UI to accomplish this task" would be the core use-case for enabling tools in service workers.
beaufortfrancois commentedon Jun 30, 2026
FWIW, I have started exploring worker support for WebMCP with GoogleChromeLabs/webmcp-tools#224. It "works" by using a SharedWorker to manage the AI agent's state and message history thanks to
extendedLifetime: true.You can play with it in https://googlechromelabs.github.io/webmcp-tools/demos/french-bistro/?crossdocument&toolautosubmit&sharedworker
Idan-Levin commentedon Jul 6, 2026
Agree with @khushalsagar that these are really separate problems.
1a is the urgent one. Any tool that ends in a redirect like checkout or booking confirmation just loses its result today. That breaks real flows right now and doesn't need workers at all, just some way for the next document to hand the result back. Would love to see that split into its own issue.
bwalderman commentedon Jul 9, 2026
+1. Persistent tool registration (e.g. through workers) seems to be a separate problem from persistent tool execution (cross-document).
Persistent tools registered in service/shared workers are naturally able to survive navigations, but this doesn't solve the issue for document-registered tools that needs to navigate. @domfarolino's idea of "re-connecting" to pending tool calls and resolving them makes sense here. It would be nice if there were an imperative API to do this that meshes nicely with declarative tools, but I'm not sure what that would look like.