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
… Sam Dallstream from Microsoft
… Pascal Euhus from Reservix GmbH
… Joe Lamyman from TetraLogical Services Ltd.
… Nart Madi from Senro
… Evgenii Arsentev from Arsentiv.ai
… Yunhao Luo from Huawei
… Ruoxi Ran and PLH from W3C
… Arial Smoliar, Basil Ahamed, James Harrison, Karl Bjorn, Neil Sotirakopoulos, Andrei Nicolae Besleaga and Fucai Xie as individual contributors
… welcome all!
Sam: hello everyone, I'm working at Microsoft, implementing agentic WebMCP
… previously worked on Web Speech API
Announcements
E-commerce for Humans and AI Agents workshop
Anssi: workshop delivered, presentations published
… this workshop was well-attended with diverse participants
… many presenters shared real-world experience how they apply or plan to apply WebMCP in various e-commerce scenarios
<Roy_Ruoxi> https://
Anssi: for concrete feedback from existing implementations and deployments, see e.g. OpenAI and Shopify presentations
PLH: GS1 co-hosted, helped articulate e-commerce in terms of products
… questions on how to make sure the agents understand user intent, how to stay within the limits the user set for an action
… long tail of vendors who don't deploy MCP servers but have websites
… Shopify talked about Universal Commerce Protocol and WebMCP and how they interact
… please note, we'll be publishing videos of all the talks in the coming weeks
… key takeaways from W3C's pespective, the web must be usable by both users and agents, WebMCP is part of that picture
… we will organize e-commerce related breakout at upcoming TPAC F2F
WebMCP
Repository: webmachinelearning/webmcp
Wide review
Anssi: in the first phase, we initiated reviews with the TAG, Privacy and Security groups
… as for the TAG and Privacy reviews, these are still work in progress as of now
Anssi: I'm pleased to see we have an active collaboration ongoing with the Security group
… we are currently test driving the Threat Model for the Web document with WebMCP:
https://
Anssi: special thanks to Victor for contributing comments that help improve the Threat Model for the Web doc:
simoneonofri/
<gb> PR 2 Clarify threat distinctions and specification coverage (by simoneonofri)
Anssi: as part of this security collaboration, we have applied the Threat Model for the Web to the WebMCP spec, with the results documented at:
https://
<Julia> I created a doc with our feedback https://
Victor: I've been helping review the threat model and helped explain how WebMCP works
… I'd like to have Dominic and Johann help a bit with cross-origin exposure aspects
… Google folks did work in this space, I could elaborate how that is specified right now, but would call for Google security folks to chime in
… as for other parts, helping clear the threat model so we can see how it informs the WebMCP spec
Julia: Victor wanted us to look at the cross-origin part, I shared the link to the doc on IRC, can also send direct PRs to the threat model doc
… some aspects of the threat model may not apply to the normative parts of the WebMCP spec
Victor: currently we did not have description for exposed tools, calling tools between different origins, S&P considerations talk about carrying state from one to another
… modeled after postMessage, needs to be clarified in the spec
… you can explicitly expose tools to another origin using explicit affordances
… I prefer to work on GH issues for the threat model improvement suggestions
Anssi: anything else on security review?
Anssi: next, we'll advance to the second phase of wide reviews working with web accessibility (a11y) and internationalization (i18n) experts
Anssi: we have received initial contributions from our group to the a11y and i18n checklists, expected pre-work for these reviews
… it is important to note all wide reviews are an ongoing process, not one-offs
… we encourage all participants to actively engage with the wide review groups, even after we've requested initial reviews and received initial responses
… the aim of these collaborations is to connect our group with horizontal group experts and in turn familiarize these experts with WebMCP so they can help improve this important work with their expertise
… new contributors will be joining the a11y review effort soon, thank you Sarah for bringing new folks on board
Anssi: Mahesh Lambe from the group contributed to the initial a11y review checklist staged in issue #272
<gb> Issue 272 WebMCP accessibility review checklist (by anssiko) [Agenda+] [a11y-tracker]
Anssi: per Mahesh, 6 out of 17 top-level a11y checklist items apply to WebMCP:
Anssi: - Accept user input: "Applicable to declarative WebMCP. It reuses HTML forms and controls; their accessibility semantics must survive schema synthesis, agent filling, validation, review, and submission."
… - User interaction features: "Applicable. The explainer defines focus, active states, review, auto-submission, activation, and cancellation. User-agent/agent-frontend UI can also expose tool discovery and execution."
… - Document semantics: "Not a new WebMCP semantics category. Declarative WebMCP extends HTML and should inherit HTML's structure, labels, relationships, order, language, and accessibility mappings rather than define replacements."
… (- Internationalization support: tracked separately in i18n-tracker issues, deferred to i18n review)
… - Accessible alternative features: "Applicable to the extent WebMCP is presented as accessibility-enabling through agents. The agent path and its mediation UI must meet the same accessibility bar; it must not become a less perceivable alternative."
… - API: "Applicable — open. The draft explicitly anticipates user-agent UI, but provides no accessibility requirements for it."
Anssi: comments?
… we'll prepare the group's response focusing on these 5 checklist items, deferring the i18n-related item to the separate i18n review
[no further feedback]
Anssi: I also called the group to look into Accessible Platform Architectures (APA) WG's initial feedback:
<gb> Issue 65 WebMCP accessibility considerations (by anssiko) [a11y-tracker]
Anssi: Chris Harrelson provided a professional and extensive response, thank you for that
… does anyone have further input to the APA WG feedback?
… I'd be supportive of positioning Chris' response as the primary response to this APA WG comment from our group
MarkF: this is more of a process question, there's a related issue that is questionnaire issue #272, Chris' response was for issue #65
<gb> Issue 65 WebMCP accessibility considerations (by anssiko) [a11y-tracker]
<gb> Issue 272 WebMCP accessibility review checklist (by anssiko) [Agenda+] [a11y-tracker]
MarkF: if we need to find someone to complete this work, we can potentially look for some Google folks
Anssi: Mahesh also provided initial input to the i18n checklist staged in issue #273
<gb> Issue 273 WebMCP internationalization review checklist (by anssiko) [Agenda+] [i18n-tracker]
<gb> Issue 273 WebMCP internationalization review checklist (by anssiko) [Agenda+] [i18n-tracker]
Anssi: 4 out of 12 top-level items on the i18n checklist were considered applicable:
… - 1. Contains any natural language text that will be read by a human
… - 6. Captures user input
… - 9. Defines markup
… - 11. Describes a format or data that is likely to need localization
Anssi: the i18n checklist items 1, 6, 9, and 11 were considered applicable
… item 4 was applicable but satisfied per review comments
Anssi: again, per Mahesh first review, our existing i18n-tracker issues capture these considerations so we will bring these issues to the a11y reviewers' attention to satisfy the review pre-work requirements
Anssi: any comments for the i18n pre-work materials?
Anssi: see +1 from MarkF
RESOLUTION: Initiate a11y and i18n wide reviews by our next telcon using the provided checklist responses with an understanding these reviews are an ongoing process, with further updates and refinements expected from new contributors. (issues #272 and #273)
<gb> Issue 273 WebMCP internationalization review checklist (by anssiko) [Agenda+] [i18n-tracker]
Execution progress report
Anssi: issue #196
<gb> Issue 196 WebMCP tool execution progress report (by beaufortfrancois) [Agenda+]
Anssi: this is a proposal to expose progress of tool execution
… Francois reports some tools may be tasked with long-running operations such as repo indexing, complex analysis tasks etc.
… no mechanism to report progress of tool execution, only a promise that resolves when execution is complete, or rejects if execution fails
… use case example, orchestrator agent and sub-agents, where progress reporting mechanism would allow sub-agents that can be long-running to report their progress to the orchestrator agent, which can then report progress to the user
Brandon: I had an open question, do we want a way for long-running executions to tell the agent the tool execution is still happening, which means the tools need a way to send messages to an agent, and for in-page agent they're using executeTool, requires extending this API
… and return ToolExecution object
Dominic: we probably want to do something like this, however this feature is currently lower priority for the Chrome team
Nart: what are actually progress semantics?
… can change on a tool by tool basis
Brandon: I think as it is, it is just a simple API for the tool to send a string message back to the agent
… left to the implementation of the agent what that means
… could be a simple string "still working"
… no strongly defined semantics as currently proposed
<gb> PR 204 Replace requestUserInteraction with requestUserInput (by bwalderman) [Agenda+]
<gb> Issue 165 WebMCP elicitation via requestUserInteraction() (was: Human in the Loop support for non-browser clients) (by MiguelsPizza) [Agenda+]
Tool discovery
Anssi: issue #227
<gb> Issue 227 Tool discovery should not be limited to a single traversable navigable (by domfarolino) [Agenda+]
Anssi: I'd like to discuss the use cases and security properties
… Dominic explains in the opening that currently getTools() retrieves tools from all documents underneath one's traversable navigable
… excludes tools from openers and opened documents
Dominic: the general thing we try to capture in this issue is what is the scope of tool discovery, now only scoped to frame tree
… two things that make us reconsider this design
… we're considering worker integration and per Jake/Moz feedback RPC-style mechanism, where the discovery could be tied to a single window proxy
… ServiceWorker as a proxy could work, want to lean toward getTools() on each window proxy object and worker object
… this would satisfy Mozilla's feedback and address this issue
… second question, we don't want you to have to have strong topology information to get the tools relevant for the page, would make it hard for extensions to know which tools it could access
… an extension can content script the page and not leave out critical tools
… if the document can access all its tools, we can take those tools and almost re-register them, so any called can reach the interesting tools in workers
… action on me to write a concrete proposal, will do that
Johann: a concrete proposal would be nice to review, what is the benefit we'd get by also keeping the old system in place at the same time?
… if we want all these tools be reachable via a single function call?
Dominic: we should give a way for the document, to decide which of the tools is relevant for the page
Johann: for ergonomics, we want a single call to yield a single list
Dominic: informed by what worker tools the page decides to put on that list
Johann: page to grab the handle and populate their getTools exposure?
Dominic: document automatically slurp up all tools, or document call getTools inside shared worker to get the tools
Johann: do we have proof of developer demand?
Dominic: even if we don't do the general RPC-style thing, we need more explicit way to see what tools are exposed to the page
<domfarolino> +1
RESOLUTION: Draft a concrete proposal for review. (issue #227)