WebExtensions API to enumerate and invoke tools

As a specific case of #23 the authors of this specification should consider collaborating with the WebExtensions CG (and future WebExtensions WG) on an API exposed to browser extensions that allows them to enumerate and invoke tools defined with WebMCP.

Chrome and the spec are currently missing an execute function/method on the context to allow agents (in browser or not) to call tools.

Once that exists, is a WebExtensions specific API still needed? since an extension can just call the API already available on the window.

e.g. an extension can execute JS in the page like modelContext.executeTool(name, args)

Ideally an extension could invoke a tool without injecting a content script into the page at all.

Also, at least in Chromium Javascript objects created by the main page aren't accessible to content scripts, only the DOM. However I think this also extends to the navigator.modelContext object so if there were enumeration and execution methods added to that interface it would probably work.

This would be much needed - there is already many browser automation focused extensions out there (including one by Claude) that also relies on scraping the dom and/or using screenshots.

Having the webmcp tools available for extensions will help with the problems that comes along with it.

once the web API is complete (i.e. has execute and list capabilities), extensions could call that just like all other types of agent.

Browser implementors could expose some sugar around this to avoid extension authors having to write evaluation calls each time (e.g. expose some extensions API which internally just calls the web API like everything else).

curious if people think the latter fits into the spec though, or if it is a separate proposal to add this higher level interface to extension APIs

EDIT:

after the last call - i understand this a lot better now. its possible for an extension to get the right context to call the regular executeTool API in the target window, but its a pain and a lot of wiring up. A web extensions API could handle all that for the extension author in a better way, and ultimately call the same logic under the hood as the normal API.

I'm supportive of this idea. It'd be good for the broader ecosystem to let web extensions have access to these capabilities without having to do the message passing song and dance themselves.

Simeon here form the WebExtensions Community Group (WECG). I wanted to say thanks for creating this issue. Next week the WECG is holding a face to face meeting in London and this is one of the topics we'll be discussing as part of broader conversations around extension participation in ML/AI/agentic capabilities.

I'm not deeply familiar with how extensions can or should interact here. As I understand it, the basic model for WebMCP is that sites expose their capabilities to the user agent through these APIs, which in turn allows the user agent to invoke functionality on the site. It sounds like the original issue description is suggesting that we should also expose the WebMPC interfaces declared by a site to extensions. It's not clear to me at the moment, though, what other roles extensions should play here.

Should extensions also be able to expose their own WebMCP capabilities to the browser?
Should extensions also be able to expose their own WebMCP capabilities to websites?

For the former, I assume extensions would use the same API as websites to expose these capabilities. For the latter, I assume we'd want to build on the ideas being discussed in #57 for iframes.

For me there are still a lot of unknown unknowns here. Are there any other usage patterns we should consider? I'd appreciate any perspective you all can share.

@dotproto

@dotproto thanks for the heads up. I'll put this on the group's agenda.

@dotproto

@dotproto we discussed this issue today in our meeting. Since we did not have anyone from WECG in the attendance we thought it would be good to have a joint discussion with WECG in the near future.

WebMCP contributors interested in extensions, please see the WECG F2F meeting notes for WebMCP relevant discussion, search with "ML/AI" to find the topic head.

@domfarolino will discuss with Google extension folks later today and reports back.

@anssiko

@anssiko, thanks for the update. I agree that it would be good to have a joint discussion soon. It looks like our groups both have meetings on Thursdays at 15:00-16:00 UTC, so we may need to schedule something outside our normal schedule. I'll reach out directly to discuss.

FYI It is now possible in Chromium to use the chrome.debugger extension API to access the WebMCP CDP domain to let developers experiment with WebMCP directly from extensions without requiring injecting content script and using the modelContextTesting Web API.

For reference purposes, you can check https://github.com/beaufortfrancois/sandbox/blob/gh-pages/webmcp/debugger-extension/README.md to see how an extension could use this:

// sidepanel.js

chrome.debugger.onEvent.addListener((source, method, params) => {
  pre.append(JSON.stringify({source, method, params}, '', ' '));
  pre.append(document.createElement('hr'));
});

const [tab] = await chrome.tabs.query({ active: true, currentWindow: true });
const debuggee = { tabId: tab.id };
await chrome.debugger.attach(debuggee, '1.3');
await chrome.debugger.sendCommand(debuggee, 'WebMCP.enable');

(We're still working on the Web Extensions CG joint meeting scheduling, haven't forgotten this important work. Stay tuned.)

@dotproto

@dotproto I'm proposing we'll have a TPAC discussion around Web Extensions + WebMCP, it could be broader than this specific issue. WDYT?

@anssiko

@anssiko, apologies for losing track of the email thread where we were discussing setting up a joint meeting. I agree that we should a join session or breakout at TPAC to discuss exposing WebMCP tools to WebExtensions (cc @xeenon). Do you have a preference between the two?

We could do both to capture the widest audience. Feel free to propose a breakout, I’ve put a placeholder for the WebML CG’s TPAC F2F Tue, 27 Oct. Looking forward to the discussions.

For anyone landing here from the TPAC breakout (w3c/tpac2026-breakouts#84): I wrote down what we need as an extension that already consumes WebMCP tools, in w3c/tpac2026-breakouts#84 (comment).

The short version is that today we have to inject a script into the page's own world to reach document.modelContext, which any page script can see and interfere with. A dedicated extension API would let us list, observe and call a tab's tools without that, with tab, frame and document identity on every tool and call, and with a change notification that reaches the extension. It would also help if an extension could register tools for a site without running code in the page's world.

The points that aren't about extensions I've put in the spec repo, for example #196 (progress and call ids) and #348 (the Tool handle and whether it can be passed between extension contexts).

Navigation Menu

Repository navigation

WebExtensions API to enumerate and invoke tools #74

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

WebExtensions API to enumerate and invoke tools #74

Description

Activity

43081j commented on Feb 10, 2026

reillyeon commented on Feb 10, 2026

victorhuangwq commented on Feb 13, 2026

43081j commented on Feb 13, 2026

bvandersloot-mozilla commented on Feb 20, 2026

dotproto commented on Apr 3, 2026

anssiko commented on Apr 7, 2026

anssiko commented on Apr 16, 2026

dotproto commented on Apr 16, 2026

beaufortfrancois commented on Apr 20, 2026

anssiko commented on May 11, 2026

anssiko commented on Sep 14, 2026

dotproto commented on Sep 15, 2026

anssiko commented on Sep 16, 2026

kenchris commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions