Meeting minutes
Anssi: as you hopefully noticed, this Community Group meeting takes place 1 hour later than earlier
… we will use this new meeting time until further notice
… the Working Group (WG) meeting schedule will not change, so if you're attending both please note this
Anssi: to start, we will welcome our latest new participants:
… Joe Lamyman and Grace Snow from TetraLogical Services Ltd.
… Vasilii Trofimchuk from Block Inc.
… Ben Greenstein from Google
… welcome all to the WebML Community Group!
WebMCP
Repository: webmachinelearning/webmcp
Spec draft established
WebMCP - Draft Community Group Report
Anssi: I've appointed Brandon, Khushal and Dominic as initial editors
… thank you for your commitment to this role
Anssi: the WebMCP spec baseline landed in PR #64
<gb> MERGED Pull Request 64 Add initial spec draft and set up CI/CD (by anssiko)
Anssi: Brandon drafted initial WebIDL in PR #75, thank you for initiating this work
<gb> Pull Request 75 Add WebIDL and descriptions to spec draft (by bwalderman)
Anssi: review from group participants welcome, thanks to Dominic and Francois for review comments
Brandon: Chromium implementation informed the WebIDL draft, so should be in a rather good shape
Dominic: we're defining internal infra that browsers are expected to provide
… Anssi: participants interested in helping with spec drafting via PRs, PR reviews, may find the following resources helpful:
Introduction to Writing Specifications with Bikeshed
Writing Procedural Specs for the Web Platform using Bikeshed
… as discussed last time, we have now set up a CI/CD system to automate build, validation, checks, and publishing steps, and this automation seems to work now
Anssi: while editors are primarily responsible for translating group's resolutions into PRs and proposing changes for review, all group participants are also able to contribute via PRs, in addition to issue discussion
… we've deployed a PR Preview tool that helps review specs via visual HTML diffs, complementary to source-level diffs
… there's two options to create local test builds, install bikeshed or use remote API via HTTP:
https://
https://
Brandon: when I submitted the PR, it flagged some errors in Bikeshed
… my local Bikeshed did not report those errors
Reilly: last time I looked at Bikeshed config it used a different version
Dominic: make sure to run bikeshed update locally to have all the data files up to date
… if your local bikeshed reports warnings, note our workflow is set to fail on warnings too, not just errors
Brandon: mine did not report as much
Anssi: we've used label-based triage in this group:
https://
Anssi: we have Agenda+ to propose topics for these telcons, I will take these into considerations and encourage editors to actively label (and unlabel) issues accordingly
… I will empower the editors to add topic-specific labels that they feel help them be more productive, so we're lax about this
Dominic: I added a new label for "declarative" issues
… ad-hoc makes sense
Anssi: I propose we adopt a mechanism to signal priority "to be worked on soon" and "to be worked on later"
… some would use implicit "v1" and explicit "v2" to signal this
… issues labeled "v2" are "to be worked on later" while other issues are "to be worked on soon"
… the intent of this is to have a shared understanding among all participants where to focus attention to right now
Mark: some other specs have used milestones, that's one option
Dominic: I don't feel too strongly how to organize work, it will organically evolve, I feel strongly we don't reflect versions and milestones in the spec
Anssi: "v2" is not a version in a traditional software versioning sense, could be "next"
Declarative proposal
Anssi: the group resolved that the declarative proposal complements the imperative WebMCP API, the latest proposal is discussed in issue #22 and PR #26
<gb> Issue 22 Declarative API Equivalent (by EisenbergEffect) [declarative]
<gb> Pull Request 26 Declarative proposal to expose tools via HTML (by MiguelsPizza)
Dominic: we've built on top of PR #26, I submitted PR #76 with additional feedback
<gb> Issue 79 not found
Anssi: the latest PR documents what Chromium prototype implements?
Dominic: right, we documented the GH issue feedback provided in #22 in declarative-api-explainer.md
Anssi: there's a bunch of issues, so perhaps we focus on the meta-issue #22
… does PR #76 address some of the "declarative" labeled issues?
<gb> Pull Request 76 Declarative API Explainer (by domfarolino)
Dominic: I will reference them from the explainer PR #76
Anssi: I believe the Chromium prototype is currently focused on the "write" tools using <form> elements
Anssi: for "read-only" tools, Brandon suggest the group to consider the <context> element over the <a> element proposed in the explainer, the benefit is <context> is not user-visible
… the <context> element was prototyped by VOIX, a web-native framework, and discussed in a paper contributed by Technical University of Darmstadt researchers:
https://
Anssi: the benefit of a <context> element over <script>
… is the ability to be included in accessibility trees
Brandon: we're looking for an element that is not visible to the user, ideally available to accessibility tools too
… a new element with these semantics, no current element fits
Johann: from a security perspective, the more we go in a direction of specific purpose fields, ideally specific enum values, the more we go to that direction the better
Johann: adding arbitrary context "write anything here" is harder to secure
Brandon: <context> element complements an agent that uses context that web developer requires, allow developers build agents that can use DOM, screenshots, provides malicious sites broader attack surface
Johann: <context> element with arbitrary document, a difficult tradeoff wrt security
Brandon: agent responsible whether to be compliant if <context> used only, or if fallback to other means is allowed
Johann: need to take security into consideration when designing this
Anssi: did the VOIX folks discuss security?
Brandon: they discussed the privacy benefit
Kryspin: is there any idea about website authors including private elements assuming the browser agent wouldn't use the DOM?
… if you use tooling for performance management, you do not track, do we add language to instruct some element to be private and not part of the context
Johann: would there be adversaries where sites are just unfriendly
Kryspin: example, credit card numbers in the DOM should fall into "do not track" regime
Dominic: what is in scope of WebMCP, is what page agents run on the providers web site
Kryspin: is that in scope?
Dominic: we have a separate issue #57 for that
<gb> Issue 57 Allow iframes to declare tools (by khushalsagar)
Kryspin: from a best practices standpoint it wouldn't hurt if it'd be part of the proposal
Allow iframes to declare tools
Anssi: issue #57
… the latest proposal currently restrict only the top-level browsing context to declare tools, this was discussed at TPAC 2025:
https://
Anssi: the group's most recent thinking is to use permission policy as a mechanism to allow the top-level delegate tool registration to a cross-origin iframe
… there's interest in the MCP-land to use WebMCP for Agent/Host -> MCP App communication:
modelcontextprotocol/
<gb> Issue 35 Adopt WebMCP for Agent -> UI communication (by MiguelsPizza) [enhancement]
Anssi: MCP Apps are contained in <iframe> elements, so this is an important consideration
… Dominic chimed in on the MCP Apps spec PR:
modelcontextprotocol/
<gb> Pull Request 72 spec: Add tool registration for Apps, to be called by Host (WebMCP-style!) (by ochafik) [v2]
Dominic: if we want to have good communication with MCP Apps and possibly use WebMCP as the backing to expose tools through the agent host we need a path to support this in iframes
… there needs to be a way for MCP Apps to do this
… document policy needs opt-in, the right primitive, probably more investigation needed
… are there security issues in allowing this, Johann?
… top-level page that can register tools should be able to delegate that capability
… it'd be nice outcome to see these things converge
Johann: I haven't looked at tool registration, will look into this, this is same-origin consideration, should make these powerful features available when both sides agree
Kryspin: in that scenario, the agent is not the browser agent, it is the chat element they're connected to
… agent refers to the MCP agent
Dominic: JS enumerate tools registered by the site, inner x-origin iframe, would WebMCP see that tool and associate it with MCP App and tell the model about this tool, and forward the tool to the MCP App
… requires an agent host script to enumerate the tools
Kryspin: subagents concept might help in terms of security
Dominic: we're discussing the enumerate tools feature in a GH issue
Should output also have a schema?
Anssi: issue #9
<gb> Issue 9 Should output also have a schema? (by bokand) [Agenda+]
Anssi: the issue from David asks should we include an outputSchema (as in MCP)?
MCP outputSchema motivation and context
<gb> CLOSED Pull Request 356 RFC: add tool `outputSchema` and `DataContent` type to support structured content (by lukaswelinder)
Anssi: motivation to provide better context to the LLMs calling the tools
… this issue was opened August and Brandon +1'd, recently Khushal commented declarative WebMCP needs this too
… are we ready to resolve to add outputSchema to both imperative and declarative surfaces?
Dominic: I think it is a good idea, biggest thing is how to associate this with declarative surface
<Mark_Foltz> Feel free to @ me on an issue if you want me to take a look
RESOLUTION: Add outputSchema to the imperative API and investigate how to associate outputSchema with declarative WebMCP (issue #9)
Accessibility considerations
Anssi: issue #65
<gb> Issue 65 WebMCP accessibility considerations (by anssiko)
Anssi: one of the goals of WebMCP is to improve accessibility
… I have invited a11y expert Leonie and her colleagues Joe and Grace from TetraLogical Services Ltd to help the group with accessibility considerations and related issues
… in #65 I documented a few areas that would benefit from a11y experts' contributions:
… - Review WebMCP use cases through the lens of accessibility.
… - Enhance existing and/or contribute new use cases that surface a11y requirements.
… - Initiate work on accessibility considerations for the emerging WebMCP draft spec.
Leonie: I'm Leonie, working on the web since 90s and a11y 00s, a11y brought me to the web community, Grace and Joe are working with our customers at intersection of a11y and agentic AI
Anssi: does Microsoft have a11y folks who might want to collaborate with Leonie and team on this topic?
Brandon: I will reach out
Leonie: we want to remove uncertainty around how screen readers access accessibility trees, CV is also useful to certain extend for accessibility tools, WebMCP would benefit both the cases if we get external access to that information
Translator and Language Detector APIs
Repository: webmachinelearning/translation-api
https://
Input formats for translation and language detection
Anssi: issue #60
<gb> Issue 60 Input formats for translation and language detection (by tomayac)
Anssi: "While the spec doesn't seem to say anything about supported formats, in practice, inputting HTML seems to work just fine (and surprisingly fine even) for translations"
… Mozilla standards position discussion surfaced some concerns
mozilla/
<gb> CLOSED Issue 1015 Web Translation API (by domenic) [position: negative]
Anssi: it is not spec'd what input formats are supported, text, HTML, JSON, markdown etc.
… per Mozilla's feedback this is both an interop and security issue
… after long discussion in Mozilla standards position, it seems like one proposed solution is to "add a mimeType parameter to the options bag that would allow the API to enter into a safe mode where it sanitizes when the input is HTML"
… I see Mozilla's position remains negative
… is there a solution that would work for Mozilla?
Reilly: security concern is untrustworthy markup, primitives to XSS style attacks, API shape is almost correct to translate HTML, I can just pass innerHTML and it works
… to a certain degree, the developer has made security errors when they've implemented their site in a way this is possible
… my hope is, there are systems that can translate markup, translate page as it is displayed to you, understand tag names should not be translated
… to do that safe translation, to enhance the API, having a version of this API that uses either mimeType or takes a DOM element
… slight preference to DOM element solution
Ehsan: this is something I've been thinking recently, echo Reilly's point
… I feel this is a rabbit hole, whatever fix we present will make it less complicated but will be bypassed later
… other concern is these APIs could be used for obfuscation, could be obfuscation bypass, I will research this more and discuss with Reilly
Prompt API
Repository: webmachinelearning/prompt-api
TAG review
Anssi: TAG review for the Prompt API was on the TPAC 2025 agenda
… but since we received the review response from the TAG only minutes before the F2F started, we deferred the response for later
https://
Anssi: at our last telcon, we heard from Chrome folks the Prompt API is one of our biggest focus areas for 2026
https://
Anssi: to help digest and respond to TAG review, we have split the feedback into topic-specific issues
https://
Anssi: I'd like to use the remaining time to triage TAG review issues and assign owners
… this is an opportunity for all interested group participants to contribute to the Prompt API
Reilly: we have triaged these issues internally
Kryspin: WebMCP is registering tools, Prompt API can create chat functionality, we're dealing with in-page agents, I'm suggesting Prompt API would include parameter "connect to the browser agent"
Reilly: the current Prompt API explainer allows an option to be implemented by remote model as opposed to a local model
… the context provided to Prompt API is solely decided by the site, these two things together create an important security boundary
…
Reilly: Prompt API has explicit non-goal to allow the site to prompt an agent that has additional user context outside the prompt
… that would be a security issue
Kryspin: an ability to subclass the chat window, the browser agent, the user of the browser is in control what the user is doing from WebMCP perspective