Meeting minutes
Anssi: first, please welcome Markus Tavenrath from NVIDIA to the WebML Community Group!
Markus: I'm curious how Web and ML is evolving, NVIDIA is interested in all things going on in this space, decided to join both the groups WG and CG
… the web is a great place to deploy ML, somewhat limited to fully exploit modern hardware, but want to help unlock the full potential
… Joon: Joon from Target Corp, engineering director, we want to provide input how consumers would be using technology developed in this group
… worked with the Chrome team, testing new APIs e.g. Built-in AI APIs
Joon: WebMCP API is of interest to our senior leaders
Anssi: this is the new meeting time for the WebML Community Group to better support the AMER geo during the WebMCP ramp-up phase
… this meeting is interleaved with the Working Group meeting at this familiar time slot.
… we're using IRC for this CG meeting to make use of custom IRC bots, recording resolutions etc.
… I consulted W3C staff on the use of AI-powered tools to transcribe, summarize, and record meetings
… it is allowed if permissions from all participants is granted
… in our earlier experimentation, the transcript had errors due to domain specificity, while the summary was more useful
… we can continue test AI-powered meeting tools but won't share output publicly to avoid misinterpretation
WebML CG Charter update
Repository: webmachinelearning/charter
Anssi: we initiated the review of the WebML CG Charter update a month ago to make WebMCP API a new WebML CG deliverable
… thank you for your review and support
… for the record, we received 10 support votes on the PR by 2025-09-18 via +1s and no objections
… this charter update passes with unanimous support, the updated charter is operational on on 25 September 2025
… during the review period we received two new explainers that supplement the main explainer:
WebMCP for Service Workers (merged)
<gb> Pull Request 26 add explainer for the declarative api (by MiguelsPizza)
Anssi: I consider both the explainers to fall within the scope of the WebMCP API incorporated in the revised charter with a provision these extensions comply with the following statements in the Scope of Work:
… - "designed for human-in-the-loop workflows where the user maintains visibility and remains in control"
… - "Each specification should detail all known security and privacy implications for implementers, Web authors, and end users"
… questions or comments?
<Zakim> anssik, you wanted to ask a question
WebMCP API
Repository: webmachinelearning/webmcp
Use cases
Anssi: issue #27
<gb> Issue 27 Use-cases targeted by WebMCP (by khushalsagar)
Anssi: broadly speaking, for WebMCP there could be two broad use case categories:
… 1) Automation, non-human in the loop
… 2) User and Agent sharing the UI, aka the human in the loop
… it seems we have an agreement to focus on the latter use cases where human is in the loop
… this is also aligned with our charter scope of work
… any other comments?
<anssik> +1 from Jason
Khushal: I assume there was general consensus we focus on human in the loop use cases
Alex: I agree, MCP-B is human in the loop app first, there's a lot of products that are doing browser automation via OCR-style approach and clicking
… when we figure out security story we can revisit this later
RESOLUTION: WebMCP focuses on human in the loop use cases initially.
Core design principles
Anssi: issue #25
<gb> Issue 25 Core design principles for WebMCP (by khushalsagar)
Anssi: MCP defines 2 layers for how server-client communication is setup
… data layer - request/response definition for initialization
… transport layer - how messages are exchanged
… proposal for WebMCP to use the "SDK option":
… data layer - browser translate MCP client <-> WebMCP server
Khushal: wanted to ensure Msft's and Google's initial proposals align on this topic
… primitives are the basic data objects e.g. tools, WebMCP reuses primitives, not data layer
… I propose we should go with the "SDK option"
Brandon: if I got the proposal correct, we're supportive of "SDK option"
Andrew: it seems important for WebMCP to be able to work without an official MCP server
… these could be generic actions that open new possibilities for the API
Anssi: "SDK option" pros:
… - decoupling WebMCP from MCP version
… - allows for different interaction patterns between WebMCP and MCP (see #21)
<gb> Issue 21 Elicitation (by bwalderman)
Anssi: - API ergonomics improvement, allow img and video element output
… - declarative API easier
Jason +1
Brandon +1
Alex +1
RESOLUTION: WebMCP to provide a layer of abstraction between the browser and MCP client aka "SDK option".
Bikeshedding the global name
Anssi: issue #24
<gb> Issue 24 Bikeshedding the global name (by bwalderman)
Anssi: window.mcp is gaining support
Thomas: wanted to bring a point that Apple brought up feedback that web is something that will be here for tens of years to come and we should strive for neutral names for globals that stand the test of time
Khushal: I hear you, MCP is parallel to GL in terms of naming, we don't know how long this primitive lives
Reilly: adding to window object makes it part of global
… has a decent likelyhood to collide with JS obfuscators
… mediating between the agent and user, putting this on navigator would be preferred
Jason: wanted to mention that as Reilly mentioned, agent registry or a collective object skirts the issue for window.agent where you may have multiple agents down the road
Anssi: does this issue block some experimental implementation?
Khushal: there's an experimental implementation currently that depends on our naming discussion
Khushal: is there consensus to put this on navigator object?
Brandon: we got internal feedback that navigator is associated with the entire browser, not specific window or page, thus going with window initially
Reilly: document object would make more sense than window
Jason: parallels to permissions interface?
Reilly: exactly
Anssi: proposal to drive consensus via GH issue discussion in the issue #24 to converge on naming and where to hang it off of: window, document, navigator
<gb> Issue 24 Bikeshedding the global name (by bwalderman)
API design
Anssi: issue #15
<gb> Issue 15 API design (by bwalderman)
Anssi: Brandon outlines two API design approaches:
… 1) An object with registerTool(options) and unregisterTool(name) methods
… 2) A single provideContext method which takes a collection of tools in a single call.
… Alex's implementation and Google's Script Tools API proposal used (1), while the current WebMCP proposal uses (2)
… Jason asked about multi page web apps and persistence, his implementation persists tools to local storage, there seems to be agreement Service Workers could solve this
Jason: I'm not advocating for local storage for the spec, it is an implementation detail
Khushal: we have a set of tools, the question is can I addFoo and removeFoo or do it via an entire list
Anssi: do we have consensus on this issue to stay with the current proposal (2)?
Anssi: what are the obstacles in supporting both (1) and (2) and do we need more experience to understand the developer ergonomics improvement better?
Alex: for dynamic web sites, React-based (1) is beneficial, I will try to polyfill to provide implementation experience
Khushal: we could have both (1) and (2)
Brandon: in Chromium our plan is to implement both (1) and (2) and allow developers to experiment and gather feedback
… I actually pitched (2) with React in mind, with some state you can compute what is available and batch send them
Khushal +1
Brandon +1
Alex +1
RESOLUTION: Continue use with the provideContext design and explore adding support for registerTool(options) and unregisterTool(name) to complement the API informed by implementation experience.
Declarative API
Anssi: issue #22 and PR #26 for the explainer
<gb> Issue 22 Declarative API Equivalent (by EisenbergEffect)
<gb> Pull Request 26 add explainer for the declarative api (by MiguelsPizza)
Anssi: a proposal to enable web pages to expose tools via HTML custom tool-* attributes
<form action="/todos" method="post" tool-name="add-todo" tool-description="Add a new todo item to the list"> <input type="text" name="description" required tool-prop-description="The text of the todo item"> <button type="submit">Add Todo</button> </form>
Anssi: this proposal broadens the scope of the API to content creators
… declarative has a significantly broader reach than imperative API among developers, expands to content authors
… learnings from Web Components suggest an imperative-only API without a declarative is problematic
Thomas: I'm wondering what's implementers' expectation for JS-rendered apps?
… do you expect people to harvest declarative instructions to execute as JS, or should there be a separate way, e.g. <noscript> style?
Alex: what do you mean by expectations, Thomas?
Thomas: what will happen in the ecosystem, e.g. open graph instruction, people can deliver them via JS, you have to have them in HTML delivered from the server
… would the same be true for declarative instructions for this API
Alex: declarative is complementary to <form>s
… for React usage, JS API provides the needed flexibility
… my demo was not expensive to implement
… couple of issues noted in the issue, how to handle elicitation
… not sure how people want to handle it
… another is expectation for the web server, WebMCP currently is JSON-RPC protocol and web apps that only serve HTML, do we have them add a new route for JSON?
Thomas: one alternative way to deliver would be via .well-known URL with declarative tools the page support?
Khushal: we don't know all the use cases for tools, some might be tied to HTML elements, I wonder if we see agent specific tools that make no sense to have UI associated
… I like the direction of this issue, wanted to identify edge cases
… good to drill down into details of declarative to be able to ship it
Alex: PR welcomes review and comments
To triage or not to triage
Anssi: issue #18
<gb> MERGED Pull Request 18 Convert SVG to PNG for easier reading in light/dark modes (by bwalderman)
Anssi: I wanted to solicit feedback on the group's preference for WebMCP API spec issue triage practices
… thanks Khushal for sharing your CSSWG experience
… I'm supportive of documenting resolutions in the minutes now that the work has ramped up
… for labels, please provide your suggestions in the issue
… I adopted "Agenda+", how has CSSWG set up its triage GH permissions?
Anssi: do all the CSSWG apply Agenda+ to issues?
Khushal: I think everyone in the group
Anssi: we can be liberal and allow all members to add labels
Khushal: CSSWG has IRC-GH integration