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: welcome to the new participants to the group:
… Sarah Drasner from Google
… Guru Singh and Cathy Li from Meta
… Chandi Cumaranatunge and Phillip Long from Arizona State University
… Arham Awan, Sean Brunnock, Thomas Jones and Simeon Vincent as individuals
… welcome all to the WebML Community Group!
WebMCP
Repository: webmachinelearning/webmcp
WebMCP early wide review
Anssi: due to strong interest in WebMCP at large, we are planning to do an early wide review of the spec to gather feedback from a broader audience
… this includes W3C's horizontal groups such as Accessibility, Internationalization, Privacy, Security, and the TAG
… input from the broader web community, web developers and users, will be considered by the group as well
… and I ask all participants to help with gathering such feedback through their channels and bring it to the group for consideration, including experimental implementations and prototypes
… we are tracking related issues in the WebMCP repo with the following labels:
https://
https://
https://
https://
https://
Anssi: I encourage the group to help triage issues with these labels, and to bring up any issues that you think should be part of the early wide review
… I will work with the editors on a plan how to reach out to the groups when we are ready to start the reviews
… many of these horizontal groups expect some pre-work, and we will need to prepare for that, e.g. make sure the explainer is up to date, and that we have a clear list of issues that we want to get feedback on
… I will reach out to the chairs of the respective horizontal groups to give a heads up on our plans
… W3C Process does not require CG work to go through a wide review, but I think it's important to get early feedback for this spec, given the potential impact on the web platform and the strong interest from the broader web community
… do folks have a preference with respect to the priority order of the reviews?
… we already have engaged with the TAG, Security IG and i18n WG, so we could start with those groups
Dominic: we had discussion with the TAG, I'd like to get a formal review from them for the spec
… Johann may know about security threat model for WebMCP, that artifact exists in our heads, we can document that and work with the Security IG
Johann: no update yet on formal threat model
Dominic: do we have a draft yet?
Johann: not yet
Dominic: let's coordinate on that
Anssi: Johann would you like to own the threat modeling exercise?
Johann: I understood Simone was interested in working with us
… Victor could also be interested
Victor: I would be interested, I did understand this is a new exercise
Johann: we could move the S&P Considerations markdown that Victor initiated to the spec, it is already pretty solid, we could use it as a starting point for the Security review and threat model
BenjaminV: could help fill in S&P questionnaire
<domfarolino> +1
RESOLUTION: Group starts WebMCP early wide review with the TAG, Security IG/WG, Privacy WG.
Consider making registerTool() return a Promise
Anssi: issue #175
<gb> Issue 175 Consider making `registerTool()` return a Promise (by domfarolino) [Agenda+]
Anssi: Dominic proposed that registerTool() should return a Promise due to cross-origin iframe integration, already asynchronous by nature
… most importantly, this would help with forward compatibility, enable reporting on failure cases ergonomically
… alternative proposed design would be to signal failures through the ontoolchange attribute
… yet per issue discussion everything points to the Promise-based design as the more ergonomic and forward-compatible approach
Dominic: I think myself and Francois are aligned, we want to hide sync failures behind a microtask, ontoolchange is not at odds with this proposal
<Victor> Is the S&P questionnaire needed for TAG review?
<domfarolino> +1
<Victor> +1
RESOLUTION: Make registerTool() return a Promise for forward compatibility and improved ergonomics. (issue #175)
Hint for reversible or consequential actions
Anssi: issue #176
<gb> Issue 176 Hint for reversible or consequential actions (by johannhof) [Agenda+]
Anssi: currently read v write actions are differentiated with readOnlyHint only
… Johann points out this does not align too well with the Human in the Loop principles
… per HCI guidelines, humans like to undo things when they explore user interfaces, the agents should be able to do the same
Johann: I'd like to hear from Ben and Victor on their thoughts
… we seem to agree reversible is the correct signal
… destructive isn't too far off was another comment
Victor: I think destructive, per historical discussion, it came from a bucket of things, we just made it happen
… CRUD construct motivated that design
… on the front of whether reversible is the right thing for this API, consequential could be too loosely applied
… reversible is a bigger set, consequential is a subset
Johann: nuances in each of these hints, example for each that won't perfectly fit
… example use case: drafting an email is reversible, while sending is not
… what is creating a calendar invite that goes to other people?
… a ton of nuances on these examples
reversible seems the best match, could also argue we want to go with what MCP spec uses
Victor: calendar use case could be both consequential and destructive
… combined together
… I think MCP has openWorldHint, does not make sense for the web that is always open world
… maybe we bring in destructive and add a similar semantic such as "open world"
Johann: make it something like action is "noticeable by other people"
… not sure if there's enough use cases for destructive in the narrowest sense
Dominic: we want to reduce actions the agent can do
… maybe there's a use case for all the actions, semantics or hints are hard to get to apply to all use cases
… lifting the user interaction action from the tool's implementation to the registration seems clearer to me
Johann: I think the idea is user agents may make some rules based on security state, having that available at runtime so the website could decide if it should confirm with the user
Victor: pushing people to use requestUserInteraction seems wrong
… "I have made my decision with the agent"
… pushing people to do user interaction, you force developers to a specific UX
Dominic: makes sense, maybe this is covered by tool description, "this calendar event may be booked with someone important that cannot be taken away"
… embed hint to description, agent would get more context this way filling the user's intent
BenjaminV: I want to push back on the idea everything is open world, for example, adding to the shopping cart
… question is do you try to mimic the regular MCP trying to get some level of synergy there
… I like Dominic's alternative of readOnlyHint imply "no user interaction"
… lifting the context out and making it explicit what it does makes more sense to me, unless you want to stick to the regular MCP interface
Victor: either boolean or enum
… you could filter all tools and do only readOnlyHint research
… you can deterministically do that, boolean or something that can be iterated on
Johann: pushing back on free text to the agent, this is not meant for the model
… we are in an environment were we trust the model less, not show you the tool that do certain actions
BenjaminV: we should try to have a property that requestUserInteraction inside a call means the user will always going to see it
… abusive site could be hammering away
Victor: I should narrow down on the set we want to add
Johann: there will be agents with no capacity of big tech first, we want to allow also simpler agents to be compliant
<domfarolino> +1
<Victor> +1
<AlexN> +1
RESOLUTION: Identify use cases for hints. (issue #176)
Support cross-frame tool enumeration and composability while handling name collisions
Anssi: issue #160
<gb> Issue 160 Support cross-frame tool enumeration and composability while handling name collisions (by markafoltz) [Agenda+]
Anssi: this is how to allow enumeration of tools across frames without name collisions
… MarkF did the initial investigation and proposed three possible solutions
… in follow-ups I see Dominic suggesting a postMessage() inspired security model
Dominic: "getTools() returns a flat list of tool objects, each containing at least the WindowProxy or origin of the source that registered the tool."
MarkF: tool enumeration steps should address this issue
Dominic: I will update the spec and explainer accordingly
Reilly: does not matter for in-browser agents, but for in-page agents, do we want to include that tool enumeration has explicit opt-in for cross-origin tools?
… so that need to opt-in to possible malicious cross-origin tools?
Dominic: we try to match postMessage semantics, similar security model applies
… no need to specialize for this, filter inside getTools(), I think
Reilly: I agree
Dominic: we mirror the target origin, and give information who registered the tool
<reillyg> +1
<domfarolino> +1
RESOLUTION: Adopt a postMessage() inspired security model for cross-frame tool enumeration, getTools() returns a flat list of tool objects with their source information. (issue #160)
<brwalder> +1
Human in the Loop support for non-browser clients
Anssi: issue #165
<gb> Issue 165 Human in the Loop support for non-browser clients (by MiguelsPizza) [Agenda+]
Anssi: Alex raised a question about how non-browser clients can support Human in the Loop interactions
… where HITL is interpreted as "the agent lives in the context of the browser", the agent could be browser's agent, extension agent, iframe agent
… the initial design is focused on HITL and as a consequence not on automation use cases
… we're seeing emerging interest in automation use cases, including new implementation experience
… Cloudflare for example experimentally supports WebMCP in their headless Chrome product aka "Browser Run"
https://
Anssi: Alex also presented a proposal how a 1P integration between WebMCP and a non-browser-native client such as Claude Desktop, Gemini CLI etc. might look like
… in this scenario, quoting Alex:
… "The user might be present but driving from outside the browser, so does this fall into our Human-in-the-Loop domain?"
Alex: thanks Anssi, we see more and more browser automation use cases happen with browser harnesses, E2E testing, a use case worth looking
… it is difficult to do, if you want to be roped in at some point and get the user's input, not clear how to do that
… I've seen some deployments of this
… Cloudflare implementation provides an iframe that allows the user to interact
… would be great to have a programmatic solution to this
Anssi: BrandonW asks "what the requestUserInteraction primitive would look like in the remote scenario?"
BrandonW: an open question, seems to me the reasonable starting point would be similar to MCP elicitation API
… we have a similar arrangement, MCP Server does not have UI directly accessible to the user, and that's where elicitation comes in
Dominic: is requestUserInteraction adequate for this if harnesses hook into e.g. Discord
BrandonW: the way requestUserInteraction is spec'd, it is up to the page to present UI and collect that input in local input and do something with that information
… to make it useful in this scenario, requestUserInteraction would need to carry more information to the agent, know what UI to pop up
Dominic: directly reaching out to the agent would be one possible path
BrandonW: requestUserInteraction is handled within the page, and agent does not need to know that interaction happened, interplay between the page and agent, could use the same code path
Dominic: requestUserInteraction does not go back to the agent, is that the problem here?
BrandonW: yes, to give an example, imagine having a single tool, order a product, go to checkout process, form gets presented to the user in the middle
… agent just gets the final result
… from the agent's point of view it is just a tool call with user intervention
Dominic: if user interaction is required, the tool tells the agent what it needs
BrandonW: Kushal shared, a page asking user attention too often can be used by malicious page, a more structure mechanism would help address this malicious use
<domfarolino> +1
<brwalder> +1
<AlexN> +1
RESOLUTION: Form a concrete design for user interaction to satisfy non-browser client Human-in-the-Loop use cases.
Prompt API
Repository: webmachinelearning/prompt-api
Anssi: I wanted the group to pay attention to the TAG review issues with recent activity
… and focus on issues that are both actionable and have a possible interoperability impact
… let's look at tag-tracker issues with activity in the last 60 days:
Anssi: all issues:
https://
MikeW: thanks for bringing these topics for group discussion, I hope we can have more discussion in upcoming meeting on this API
… we have made most progress on parameters
… finding categories to allow clients to find creative behaviours and allow implementers to align on implementations that fit that category with topK etc.
… developers are interested in tuning parameters, so we took to heart TAG feedback on this design point
… we're done basic design and invited developer feedback to explore this categorical preset approach
Anssi: this was issue #170
<gb> Issue 170 [Tag Review] - Interoperable model parameters (by etiennenoel) [tag-tracker]
BenjaminV: we had Jake in the room who wrote standards position for this API, the concerns around model tuning and parameter tuning, people designing for one particular model
Anssi: I'd invite feedback to be provided in the spec repo
https://
<anssik> s/we've done/we've done
<anssik> s/… we're/… we've