Meeting minutes
<bvandersloot> who's here
Anssi: welcome back to our telcons
Anssi: first, I'd like to welcome our latest new participants:
… Léonie Watson from TetraLogical Services Ltd.
… Dominic Farolino and Francois Beaufort from Google
… individual contributors Hao Wang, Teja Sunku and Paola Di Maio
… welcome all to the WebML Community Group!
WebMCP API
Repository: webmachinelearning/webmcp
WebMCP API explainer-to-spec transition
<gb> Issue 56 Is this a proposal or a group of proposals? (by 43081j)
<gb> Pull Request 64 Add initial spec draft and set up CI/CD (by anssiko)
Anssi: today, we will execute the resolution to transition from the WebMCP explainer to a Community Group spec draft stage
Anssi: we will also discuss practicalities and expectations for the Community Group spec draft stage
… in PR #64 I have established the spec draft baseline and set up a CI/CD system to automate build, validation, checks, and publishing steps
… this automation will make the lives of editors and contributors easier and ensure all spec builds are of consistent quality
… spec contributors only need to edit the source file, index.bs, and upon successful merge, the built spec is deployed automatically
Dominic: I'd be willing to edit the spec, working with Khus
Brandon: I will be interested in editing
Victor: I will be contributing
… Anssi: I will appoint additional editors as appropriate
… contributions to the WebMCP spec happen via PRs and issues are welcome from all group participants
… editors and contributors are expected to familiarize themselves with the spec-authoring tool Bikeshed we will use for this spec, it is a powerful and versatile tool with some quirks
… I'll share some materials below that may be helpful on this journey:
Introduction to Writing Specifications with Bikeshed
Writing Procedural Specs for the Web Platform using Bikeshed
Anssi: folks who have been involved with W3C spec editing in other groups are likely familiar with Bikeshed and associated tooling
… the WebMCP spec will be called a "Draft Community Group Report" in W3C's parlance
Types of documents W3C publishes
Anssi: a partial patent policy applies to this type of specs to allow for an easy way innovate that is inclusive of all, including all individual contributors that join the group
… formal wide reviews are not expected for Draft Community Group Reports
… however, W3C TAG conducts and encourages early TAG design reviews, called "Early design/incubation review" to ensure cohesion within the whole at this earlier stage pre-standards track
… my expectation is we will seek early review from the TAG when our early spec draft takes shape
https://
Agentic AI Foundation coordination
Repository: webmachinelearning/charter
Anssi: issue #14
<gb> Issue 14 Agentic AI Foundation coordination (by anssiko)
Anssi: as discussed earlier, we're actively looking to formalizing our coordination with the newly founded Agentic AI Foundation for WebMCP to ensure cohesive development
… I've worked with Vasilii from Block Inc., AAIF co-founder, on a coordination proposal
… Vasilii shared the proposal in a GH comment in this issue, I'll summarize the key points
… the goal is it keep this lightweight, flexible, let the two specs grow and develop
… three key points of the proposal:
… - scope - WebMCP to enumerate what MCP spec sections apply
… - intent - document the intent is to keep WebMCP aligned with MCP where applicable
… - engagement - agree on communication channels (GitHub, Discord, MCP Working Group meetings ...)
… once we're settled, we will codify these expectations in the WebML CG's Charter that will be submitted for review
Vasilii: thanks for the overview, I'm thinking the engagement model can change with time, now starting with lightweight model
… MCP moving fast, good to keep track of changes
Dominic: do we expect AAIF folks to join?
Vasilii: I will invite AAIF folks to join the W3C WebML CG
Declarative proposal to expose tools via HTML
Repository: webmachinelearning/webmcp
<gb> Issue 22 Declarative API Equivalent (by EisenbergEffect) [Agenda+]
<gb> Pull Request 26 Declarative proposal to expose tools via HTML (by MiguelsPizza) [Agenda+]
Chromium Declarative WebMCP prototype
Anssi: the declarative proposal to expose tools via HTML has been identified as an important complementary feature to the imperative WebMCP API by the group
… we've received new feedback from various folks since our last discussion, to be discussed today
… the feedback is split into the issue discussion and in the PR
… we'll look at the recent comments in issue #22 first
webmachinelearning/
<gb> Issue 22 Declarative API Equivalent (by EisenbergEffect) [Agenda+]
Anssi: Khushal clarified the two goals for the declarative proposal:
… 1) Support for cross-document navigations, this can’t be done with the current imperative API
… 2) Developer ergonomics, make it trivial to expose existing actions without necessitating client-side scripting
Dominic: semantic HTML elements to register themselves as tools, slap attributes on form elements
… the first take of this is in PR #26
… Ben of Mozilla has comments on PR that the agent might actuate the form itself
… PR #26 is the baseline for the Chromium prototype
… our goal is to resolve the group wants to work on the declarative proposal
Dominic: Khushal's comment notes form submission has two cases: cross-document and same document interaction
… cross-document schedules page navigation, this is the more complex case
… we will prototype to find answers to the open design issues
BenV: declarative approach may better address some issues from Mozilla's side re WebMCP
Brandon: on our side, form submission is an important consideration, support declarative approach in addition to imperative API
… I support mapping the forms, but the way of retrieving information still needs some work
… the proposal is to ask link elements to do things the link elements don't normally do e.g. respond with JSON objects
… it encourages different patterns than I think we want
… the premise is to augment existing pages for humans to be useful for agent
… humans look at pages, but for agents, we need to add a link to the page that is not useful for humans
… I support form submission approach
Dominic: from Chrome side we are not considering links yet in our design
<jason_mcghee> (hello - apologies for tardiness / conflicting meetings)
RESOLUTION: Pursue declarative approach that complements imperative WebMCP API
Anssi: looking forward to further implementation experience
Define the API for in-page Agents to use a site's declared tools
Anssi: issue #51
<gb> Issue 51 Define the API for in-page Agents to use a site's declared tools (by khushalsagar) [Agenda+]
Anssi: at TPAC we had a good discussion but we did not reach consensus so I wanted to revisit this topic with new information
… since TPAC Khushal contributed an API sketch to make the ModelContextClient API proposal more concrete:
webmachinelearning/
<gb> Issue 51 Define the API for in-page Agents to use a site's declared tools (by khushalsagar) [Agenda+]
Anssi: I'd like us to review and discuss the proposed ModelContextClient interface
… this extensible API allows listing current tools and executing them
… key motivation is to avoid concurrency issues with multiple agents
Dominic: overall this is a good idea, I think it is the right direction, currently trying to avoid scope expansion so lower priority right now
Victor: my thoughts, not sure if there's strong demand from 3rd party agents for this feature
… there must be interest from 3P sites to use this feature, need confirmed demand
Anssi: James shared a Salesforce UI use case and expectations wrt API in a comment
webmachinelearning/
Dominic: I can take an action to respond on this issue
<Victor> +1 on some form of labelling to triage
Dominic: we could label issues e.g. v1 or v2
Add a callback to inform the site when tool invocation should be aborted
Anssi: issue #48
<gb> Issue 48 Add a callback to inform the site when tool invocation should be aborted (by khushalsagar) [Agenda+]
Anssi: this issue is about how to inform the site if the user cancels the tool invocation that is in flight
… it seems we're converging to use AbortSignal for the job
Brandon: precedent for AbortSignal is Fetch API
Dominic: should resolve this to use AbortSignal
<domfarolino> +1
RESOLUTION: Use AbortSignal to signal cancellation (issue #48)
Should concurrent tool execution be allowed?
Anssi: issue #47
<gb> Issue 47 Should concurrent tool execution be allowed? (by khushalsagar) [Agenda+]
Anssi: Khushal notes tool execution is async, multiple tools can be invoked in parallel
… James shared concurrent execution is important, and managing concurrency should be always left to userland code
… promise-returning API ensures the tool author can choose to await for a tool call to finish before invoking a new tool call
Brandon: I think this is dependent on how we handle multiple clients, ref issue #51
<gb> Issue 51 Define the API for in-page Agents to use a site's declared tools (by khushalsagar) [Agenda+]
Brandon: first need to resolve issue #51 prior to resolving #47
Anssi: should we punt this for later?
[agreement heard]
Built-in AI APIs
Anssi: we have four built-in AI APIs in scope of the group:
https://
https://
https://
Anssi: first, I want to welcome new editors on board and then discuss 2026 priorities
… Translator and Language Detector APIs was the last API in the group's scope without active editors
… I'm pleased to appoint Reilly Grant from Google and Ehsan Toreini from Samsung as the editors of this spec
… Reilly is an experienced web spec author and browser engineer and Ehsan is a research engineer with privacy, cryptography and security focus, a great pair to work on this spec
… thank you both for volunteering to take on this role
Ehsan: thank you Anssi and hello everyone, I work at Samsung based in London UK, worked on trustworthiness of ML, privacy and security, HW security
… nice to be part of the group!
Anssi: to help the group participants focus their attention across these API specs, I'd ask the editors to label high priority issues with "Agenda+" labels
… we will give Agenda+ issues higher priority and more agenda time
… also, if implementers have certain APIs and/or features higher priority for this year, it'd be good to know to ensure the group gives such specs appropriate attention
… questions, comments?
Mike: I can offer insight on Chrome plans for 2026, Prompt API is one of our biggest focus areas, for issue priorities, on Prompt API repo a bunch of issues was filed representing feedback received from the TAG
… these issues benefit from input from this group
Meeting scheduling fine-tuning
Anssi: I want to solicit feedback for the proposal to shift this CG call forward by one hour
… this timeslot we have chosen is a compromize we've used to allow US West Coast, Europe and China and sometimes even Japan join
… do we currently have active participants from China, Japan, or from APAC?
<jason_mcghee> to 6am PST?
<Mark_Foltz> No conflicts
<brwalder> no conflicts
Mike: Kenji might join on occasion from Google Tokyo
<vasilii> jason_mcghee, I believe 8am PST
<Victor> no conflicts
<jason_mcghee> vasilii - thanks anssi immediately answered :)
<vasilii> +1
RESOLUTION: Shift the WebML CG call forward by one hour and re-evaluate schedule from time to time considering active participants' timezones
<jason_mcghee> thanks anssi
<anssik> s/… I will/Anssi: I will