Meeting minutes
Anssi: as a reminder, we'll use IRC-based queue management in this meeting:
https://
Anssi: to suggest agenda topics, use Agenda+ label, e.g.:
Anssi: please welcome our latest new participants
… Erik Nordin from Mozilla
… Juan Fernandez from Shopware
Announcements
TPAC 2026 schedule
Anssi: TPAC 2026 is in Dublin, Ireland on 26-30 October 2026
… the WebML WG is planning to meet on Mon 26 October 2026 and the WebML CG on Tue 27 October 2026
… given the two groups have good overlap in both participation and expertise, we make this a joint F2F meeting 26-27 October 2026 similarly to TPAC 2025
… Monday primarily for WebNN API topics, and Tuesday for WebMCP, Prompt API and other built-in AI APIs
… I have opened a F2F GH issue to solicit ideas for the F2F agenda:
webmachinelearning/
<gb> Issue 39 WebML WG/CG F2F Agenda - TPAC 2026 (Dublin, Ireland) (by anssiko)
Anssi: as is practical, the detailed agenda will be worked out closer to the meeting, but I wanted to give everyone a heads-up and an opportunity to provide input early
… any questions or suggestions?
Prompt API
Repository: webmachinelearning/prompt-api
Sampling parameters
Anssi: issue #203
<gb> Issue 203 Proposal: Introduce Categorical Sampling Modes for the Prompt API (by isaacahouma) [enhancement] [interop] [Agenda+]
Anssi: we have early developer feedback results on how developers are interacting with sampling parameters
… e.g. temperature and topK
Anssi: Kenji shares "45% of respondents stated they are actively tuning sampling parameters in their workflows."
Reilly: we found out there's a reasonably large group that can migrate to the pre-defined sampling parameters
MikeWa: we are collecting feedback from developers and want specific examples to understand the gaps
MikeWa: to close the gaps we have for behaviors, we know the developers want a mode that has lower predictability
… summarization or information extraction use cases considered, adjusting parameters of the 5 modes we have and seek further input and concrete examples from developers
… we may want to add 1-2 additional modes
… happy to report when we get additional information and data
Anssi: we'll await further data from developers and will revisit this issue
WebMCP
Repository: webmachinelearning/webmcp
Wide review
Anssi: we are ready to initiate the review process with the TAG, Privacy WG and Security IG
… thank you all for your work in preparing the review materials, now approved by the group:
Anssi: I should note the Security IG already discussed WebMCP in their 9 June 2026 meeting and they are supportive of the review process, awaiting the formal review request from the CG, thanks Johann for joining that meeting
Security IG 2026-06-09 minutes
Anssi: as a reminder, here are the templates for the review requests for the TAG, Privacy WG and Security IG:
TAG review request ("Early design/incubation review")
Privacy review request template ("Request review for another type of spec")
Security review request template ("Request review for another type of spec")
<domfarolino> +1
RESOLUTION: Initiate wide review of WebMCP with the TAG, Privacy WG and Security IG.
<Victor> +1
WG transition
Anssi: we are in process of transitioning WebMCP from the CG to the WG
… I discussed this matter with the WebML WG last week and shared the charter change proposal with the group:
<Victor> I will ask Brandon if he wants to participate in the review as well
https://
Anssi: we are expected to seek review from the TAG, Security IG, Privacy WG, a11y/ARIA WG to inform this transition
… by initiating the wide review process, we're already taking the right steps toward this transition
… it is a normal and a healthy part of the process to see an active discussion when work is transitioning to a WG
… this lively discussion emphasizes the importance of the work
… each W3C Member has one vote to ensure the entire W3C membership is represented in the decision-making process
Dominic: when we filed the standards position with Apple, the early feedback was to move away from the current group structure
Saron: I haven't been part of this discussion, we see the problem as an HTML specific problem
Dominic: would be great to talk to Apple folks about their feedback
BenV: Mozilla doesn't have a strong opinion, it makes sense to advance from the CG stage
Laszlo: we have a similar opinion, we want to see this advance to a WG
Framework considerations
Anssi: issue #199
<gb> Issue 199 Frameworks and WebMCP Meta Issue (by sdras) [Agenda+]
Anssi: Sarah opened a meta issue for framework considerations for WebMCP, thank you for helping the group understand the framework landscape better
… let's first build understanding of what are typical frameworks in this context, how frameworks interact with WebMCP, and what the implications are for WebMCP design
… after this stage setting, let's discuss the specific framework considerations in separate topics I scheduled for this meeting
Dominic: in broad strokes, there are ways how WebMCP can play nicer with frameworks
… Sarah is doing the work to identify opportunities how that can happen
… we're thinking how the first sub-issue would work, we could have tools with closure that become stale
… we're trying to understand what is the concrete issue with stale closures, so we could derive a WebMCP solution
… also want to understand if this can be solved in the userland
for "A pending/unavailable tool state" consideration and "Persistence across routes/views/pages" we want to have site be able to register what tools are available to a page before the script has executed and registered the tools
… we're exploring declarative mechanisms for this
… when we talk about tool persistence, navigation requires registration trashing in model context, possibly
… tool execution persistence, same origin navigations, two angles or persistence
… what the concrete issues for the agent here are, "A pending/unavailable tool state" is more relevant for clients I think
BenV: I think the couple of versions of persistence are interesting, thinking of multi-page web pages, context manager would grow when you navigate the site, dropping tool definitions would not be good
… I'm trying to keep that design in mind
Dominic: two things, framework specific state management shared by React and Vue
… secondly, persistence considerations that are also important outside framework considerations
Juan: we use Vue and try integrate it with WebMCP, I can share my feedback in the meta issue #199
<gb> Issue 199 Frameworks and WebMCP Meta Issue (by sdras) [Agenda+]
<domfarolino> +1
<bvandersloot> +1
RESOLUTION: Investigate state management and persistence requirements for frameworks (issue #199)
Dynamic tool definitions
Anssi: issue #167
<gb> Issue 167 Proposal: Dynamic Tool Definitions in WebMCP (by AlpineJosh) [Agenda+]
Anssi: a proposal to let tool definitions respond to state
… per this issue author, registerTool() assumes inputSchema and callability to be fixed at registration time
… proposal is to lazily resolve at enumeration time
… and add a disabled flag via updateTool() to indicate that a tool is not callable at the moment
… example: a music app's removeFromQueue tool is meaningless when queue is empty, should be enabled only when queue is non-empty
Anssi: Dominic responded unregister and re-register the tool yields the same effect
… unregistering happens via an AbortController signal, maybe the ergonomics of that is not great
… and could be improved with updateTool()?
Dominic: my opinion is we can add updateTool(), but I'd like to hear more from model providers
… does this solve a problem that unregister and register wouldn't solve
… some trashing is involved when unregister and register happens
… Victor, do you have any insights whether trashing happens between each call?
Dominic: with Genimi Chrome experience, I don't see this as a problem
Victor: about updateTool() I'm curious how this affects the model side
… I see this as developer ergonomics consideration
… the model should be a consideration when we're mid-flight
… allowing a base condition, might add more complications how the tool calling happens
Dominic: changing the tool while execution happens, I don't think we want to support that
… I consider this an ergonomics issue, also want to understand if this is an agent ergonomics improvement
Victor: if you can update it, you can add a diff and no need to recreate the model context
… it feels this would help the model developer, but we should focus on the ergonomics improvement
… I don't think there's a big issue here
Kushal: this issue is about keeping the tool name the same but updating the schema, some parts of the tool definition that are model exposed
… I think from that case, the integration in Gemini Chrome, the model is given a task, I want to see what the current state of the tool looks like
… after the tool has executed we'll pull the current state, updating the inputSchema could happen lazily, but not sure how that could happen
… at every turn of the planning loop, all tools are sent to the model
Kushal: even with always-on LLM looking at all available tools, I don't see how an API that let's update tool description is making this any easier
Victor: because you update a small section of tool definition, you can add the diff to the context, no need to overwrite the entire cache
… possible context optimization case, whole context helps, previous cache not invalidated, you get to keep the caching benefits
Dominic: speculative
s/very very speculative
Khushal: do KV cache experience apply to function calling case?
Reilly: want developers to cache, not gotten to function calling aspect of the API to tell if tool state changing between queries is the most efficient way
BenV: use case with only callback changing would be nice in a way context not altered
… that structure would be a strong case for an updateTool() method
Khushal: the previous issue for this was about that
… I support that idea
Dominic: we should sketch a proposal for that and table the rest
<domfarolino> proposed RESOLUTION: sketch out an API that allows updating non-model-exposed tool parts; table the rest until WebMCP consumers demonstrate a problem that demands updating model-exposed tool parts.
<kush> +1
RESOLUTION: Sketch out an API that allows updating non-model-exposed tool parts; table the rest until WebMCP consumers demonstrate a problem that demands updating model-exposed tool parts. (issue #167)
<gb> Issue 167 Proposal: Dynamic Tool Definitions in WebMCP (by AlpineJosh) [Agenda+]