Meeting minutes
as a reminder, we'll use IRC-based queue management in this meeting:
https://
Anssi: to suggest agenda topics, use Agenda+ label
WebMCP
Agentic AI Foundation coordination
Repository: webmachinelearning/charter
Anssi: issue #14
<gb> Issue 14 Agentic AI Foundation coordination (by anssiko) [Agenda+]
Anssi: I had a discussion with W3C Legal counsel on how to formalize this coordination
… a summary is provided in the issue comment
… two key points:
… 1) technical alignment in the spec
… for technical alignment purposes, based on my discussion with W3C Legal, this Community Group can include things from the MCP spec into the WebMCP spec with attribution
… I will discuss with W3C Legal what is the most appropriate way to attribute MCP spec considering its ongoing license transition from the MIT License to Apache-2.0 License:
https://
Anssi: currently WebMCP spec references the MCP spec in its introduction section
… I believe the group wants to also reference the MCP spec in context of the WebMCP tool definition and explain the intent and expected scope of the tool definition reuse across the two
Anssi: any questions about referencing the MCP spec from within the WebMCP spec?
Dominic: what are we trying to get out of this coordination?
webmachinelearning/
<gb> Issue 14 Agentic AI Foundation coordination (by anssiko) [Agenda+]
Anssi: 2) charter-level coordination
Anssi: beyond spec-level technical alignment, I propose we codify high-level expectations for the W3C-AAIF coordination in the group's charter
… including scope, intent and engagement mechanisms
… I will work with W3C's Dom and AAIF's Vasilii on this update that is considered non-blocking for the current spec work
https://
Dominic: I think how WHATWG coordinates with other orgs could be reused here, we loop external orgs in as non-blocking parties in the WHATWG context
Tool unregistration design
Repository: webmachinelearning/webmcp
Anssi: issue #130 and PR #147 for the first option
<gb> Pull Request 147 Spec `unregisterTool(ModelContextTool)` (by domfarolino)
<gb> Issue 130 Tool unregistration design (by domfarolino) [Agenda+]
Anssi: a follow-up to #101 where we agreed an actor should not be able to unregister a tool that it did not register itself
<gb> CLOSED Issue 101 `navigator.modelContext.provideContext` allows overwriting of previously registered tools in the same environment (by beaufortfrancois)
Anssi: Dominic, please introduce the issue and the three design options considered
Dominic: I summarized three options in the issue,
… 1. unregisterTool(ModelContextTool)
… simplest, symmetry with addEventListener() and removeEventListener()
… 2. registerTool(interface Tool) / unregisterTool(interface Tool)
… as above but pass in a Tool
… a Tool is an EventTarget and can fire the toolactivated and toolcanceled events directly on the tool
… 3. registerTool() returns an unregistration token
… registerTool() returns a Tool that has an unregister() method
… with my web platform hat on the first option is the most webby, Chrome supports it and we have implementation experience for that option
… please take a look at the options and the PR
Reilly: appreciate the simplicity of the first option, ModelContextTool is complex, are we using deep comparison?
Dominic: they way dictionaries work is you don't get a reference back, so cannot rely on that, we use per member equality matching
… I can imagine a world where we could introduce a Tool interface
… want to understand whether there are any footguns, not found any with the first option
Reilly: the nice thing about Tool interface is to have an interface to return, that an extension could use to enumerate tools?
Dominic: API could exist either way
Reilly: gets us part of the ModelContextTool dictionary?
Dominic: testing tool gives you a bag of attributes and access to the callback
Reilly: not convinced 2nd option is better after this discussion
Brandon: despite simplicity, ergonomics issues may arise when expecting string names, having to pass objects with the same execute callback forces developers to maintain a reference to the callback
… it is common to pass tool definition without naming it as a variable
… in that pattern you cannot hold the reference to pass it to the unregisterTool later
Dominic: how often people need to unregister tool?
… most people put it inline and lose it, that's OK
Brandon: I guess the difference is, not unregistering event handlers could cause memory leaks
… it won't break your app, if the element you're listening to goes away
… event handlers would be cleaned up anyway
… with tools, they are unregistered explicitly though
… e.g. React components when they are unmounted should allow unregistering tools
Dominic: my only pushback would be you still need to keep track of the tools
Dominic: Tool interface does not solve this problem, only the 3rd option would solve that
… only concern is no existing Web APIs use such a pattern currently
Alex: agree with Brandon's concerns, but this could be handled by a library abstraction
… whether to use an object or an interface, running into a tool name, would be great to throw those errors e.g. call new Tool() and it rejects if the name does not match
Dominic: ergonomics thing that would be nice
… that makes sense, I don't know how valuable it is, I will think about it a bit more
Victor: unregistration pattern will be more common in SPAs in particular, e.g. shopping flow
… unregistration will be commonly used
… the previous approach was to (un)register with a name, are we overcomplicating the design?
Dominic: I'd like to resolve we do either option 1 or option 2 to narrow down on the solution space
… Victor, any concerns to provide the entire Tool to pass as a reference?
Victor: you'd have to keep track of the exact tool you created, but for name you can just store it somewhere, makes for better developer ergonomics
… what if the tool definition grows bigger in the future?
Dominic: growth concern pushes us toward the Tool interface
… should consider how subclassing would look
Dominic: any objections to start with option 1 and if issues arise move to option 2?
<AlexN> +1
<brwalder> +1
<victor> +1
<victor> As long as we are open to changing direction we are fine
<gb> Issue 130 Tool unregistration design (by domfarolino) [Agenda+]
<reillyg> +1
<domfarolino> +1
<victor> +1
RESOLUTION: Adopt unregisterTool(ModelContextTool), if issues arise in developer trials move to (un)registerTool(interface Tool) design. (issue #130)
Declarative integration with form-associated custom elements
Anssi: issue #94
<gb> Issue 94 Define Declarative WebMCP integration with form-associated custom elements (by beaufortfrancois) [Agenda+] [declarative]
Anssi: I want to give a heads-up there's early Chromium implementation experience for declarative integration with form-associated custom elements
Anders: two biggest issues we discovered, the names, not sure about them
… "what do you mean by tool"
… more difficult issue is how to fill in the custom element
… when you execute, if we return a failure, we don't want the form state to be modified at all
… not clear we can return a failure with the existing patterns how CE work, CE is all async
… cannot check "does this data look good to you" from a custom element
Dominic: in what ways it could fail?
… only when the data does not match the schema?
Anders: if the author provides an input schema, as long as the schema is matched, it is not allowed to fail?
Dominic: any other cases?
… in general for form-associated custom elements, do we have any failure paths?
Anders: are the elements going to be more strict than what we can express in JSON schema?
Dominic: no I guess, want to understand if there are any other ways to fail?
… are there any other ways to express form filling failure for native elements?
… apart from JSON schema validation, any other failure paths
Anders: base step and step in ranges do not map to anything in JSON schema
Anssi: I'd like to see some group discussion in the issue before resolution to ensure we carefully consider all viewpoints
Allow iframes to declare tools
Anssi: issue #57
<gb> Issue 57 Allow iframes to declare tools (by khushalsagar) [Agenda+]
Anssi: we discussed this at TPAC 2025 and most recently a month ago on our telcon:
https://
Anssi: good issue discussion recently, thanks!
Anssi: I believe we need to agree on the use cases first
… when we understand the use cases, we're better positioned to design a solution, be it Document Policy, Permission Policy (prior Feature Policy) or something else
https://
https://
Anssi: Victor documented the following two use cases for allowing iframes to declare tools:
Victor: two use cases:
… 1. To allow iframes to declare tools for browser/extension agents to operate
… There are many sites where the main content is inside an iframe, so we want to make sure that the main contents of these sites are able to expose tools as well.
… 2. To allow some form of cross frame calling of tools
… - This seems like an emerging use case
webmachinelearning/
<gb> Issue 57 Allow iframes to declare tools (by khushalsagar) [Agenda+]
Anssi: any additional use cases?
… are these two the only use cases we want to design the solution for?
Victor: if the only concern is the first use case, the parent frame does not need to see the child frame
… in some sense there's less risk, browser mediating
Johann: I think I disagree with iframe able to register tools
… think you're an advertiser, you could register a tool "this is the real checkout tool"
Dominic: parent should opt-in to this, is the parent page OK for the child to operate the first-party page
… is this as simple as Permissions Policy, or is it too granular?
Johann: Permissions Policy is not bi-directional is an issue
… it is risky to steal these tools from the child frame, say a bank might have use case to have their site framed, you could make an agent to use these tools
Dominic: 3P Document Policy opt in
… we don't require the parent to have access to the tools and the child would agree to that, that'd be a higher bar
… bi-directional negotiation is important
Johann: does not need to be Document Policy, we could bake this into the API directly
Dominic: Document Policy might be good for this, its header negotiation provides a mitigation, to not expose sensitive tools
Victor: we can talk to Ian about Document Policy evolution
Mark: there's a second issue that was not resolved fully, the name collision
… if frames register tools with the same name for parent and child
… name collisions become a responsibility of the browser to provide context they're different tools with different impacts depending on the context
… if you register two tools they are different origin
… from quality perspective, not allowing name collisions would be good
Victor: goes back to use case consideration
… it is an implementation details how to handle the collision
Johann: recommend to bake in a serialization algorithm for the names into the spec for interop benefit
… to allow deduplicating the tools
Dominic: if the serialization is exposed to the platform it would be relevant then?
<domfarolino> +1
<victor> +1
RESOLUTION: Explore Document Policy as a bi-directional opt-in mechanism without a wildcard mechanism that addresses the two use cases, figure out a solution for name collisions. (issue #57)
<gb> Issue 57 Allow iframes to declare tools (by khushalsagar) [Agenda+]
Anssi: FTR, at the beginning of the meeting, we welcomed the following new participants to the group:
… Jaewon Lee from Google
… Benjamin VanderSloot from Mozilla
… Saron Yitbarek from Apple
… Shubham Gupta from Huawei
… Christoph Bordeck, Matthew Zaute, Chris Phillips, Richard MacManus, Umar Iqbal and Aaron Schneider as unaffiliated individual contributors