15:54:42 <RRSAgent> RRSAgent has joined #webmachinelearning
15:54:46 <RRSAgent> logging to https://www.w3.org/2026/02/05-webmachinelearning-irc
15:54:46 <Zakim> RRSAgent, make logs Public
15:54:47 <Zakim> please title this meeting ("meeting: ..."), anssik
15:54:53 <anssik> Meeting: WebML CG Teleconference – 5 February 2026
15:54:58 <anssik> Chair: Anssi
15:55:06 <anssik> Agenda: https://github.com/webmachinelearning/meetings/blob/main/telcons/2026-02-05-cg-agenda.md
15:55:10 <anssik> Scribe: Anssi
15:55:14 <anssik> scribeNick: anssik
15:55:22 <anssik> Present+ Anssi_Kostiainen
15:55:41 <anssik> RRSAgent, draft minutes
15:55:43 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/05-webmachinelearning-minutes.html anssik
15:55:51 <brwalder> brwalder has joined #webmachinelearning
15:57:18 <anssik> Present+ Brandon_Walderman
15:59:35 <anssik> Present+ Leonie_Watson
16:01:24 <anssik> Present+ Kryspin_Ziemski
16:01:46 <anssik> Present+ Dominic_Farolino
16:02:02 <anssik> Present+ Joe_Lamyman
16:02:08 <anssik> Present+ Ben_Greenstein
16:02:15 <Melissa> Melissa has joined #webmachinelearning
16:02:20 <anssik> Present+ Christian_Liebel
16:02:24 <qcomp> qcomp has joined #webmachinelearning
16:02:29 <anssik> Present+ Melissa_Mitchell
16:02:32 <JoeLamyman> JoeLamyman has joined #webmachinelearning
16:02:43 <anssik> Present+ Fabio_Bernardon
16:02:45 <Fabio> Fabio has joined #webmachinelearning
16:02:49 <anssik> Present+ Reilly_Grant
16:03:01 <anssik> Present+ Vasilii_Trofimchuk
16:03:06 <domfarolino> domfarolino has joined #webmachinelearning
16:03:11 <anssik> Present+ Mark_Foltz
16:03:13 <BenGreenstein> BenGreenstein has joined #webmachinelearning
16:03:15 <anssik> RRSAgent, draft minutes
16:03:16 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/05-webmachinelearning-minutes.html anssik
16:03:27 <anssik> Present+ Ehsan_Toreini
16:03:45 <anssik> RRSAgent, draft minutes
16:03:46 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/05-webmachinelearning-minutes.html anssik
16:03:54 <anssik> Anssi: as you hopefully noticed, this Community Group meeting takes place 1 hour later than earlier
16:03:58 <JoeLamyman> present+
16:04:00 <anssik> ... we will use this new meeting time until further notice
16:04:11 <anssik> ... the Working Group (WG) meeting schedule will not change, so if you're attending both please note this
16:04:31 <anssik> Anssi: to start, we will welcome our latest new participants:
16:04:39 <anssik> ... Joe Lamyman and Grace Snow from TetraLogical Services Ltd.
16:05:22 <anssik> Present+ Johann_Hofmann
16:05:29 <anssik> ... Vasilii Trofimchuk from Block Inc.
16:05:47 <anssik> ... Ben Greenstein from Google
16:05:54 <anssik> ... welcome all to the WebML Community Group!
16:06:06 <anssik> Topic: WebMCP
16:06:16 <anssik> gb, this is webmachinelearning/webmcp
16:06:16 <gb> anssik, OK.
16:06:33 <anssik> Subtopic: Spec draft established
16:06:39 <anssik> -> WebMCP - Draft Community Group Report https://webmachinelearning.github.io/webmcp/
16:06:53 <anssik> Anssi: I've appointed Brandon, Khushal and Dominic as initial editors
16:06:55 <Mark_Foltz> Mark_Foltz has joined #webmachinelearning
16:07:02 <anssik> ... thank you for your commitment to this role
16:07:11 <Mark_Foltz> Mark_Foltz has joined #webmachinelearning
16:07:13 <anssik> Anssi: the WebMCP spec baseline landed in PR #64
16:07:15 <gb> https://github.com/webmachinelearning/webmcp/pull/64 -> MERGED Pull Request 64 Add initial spec draft and set up CI/CD (by anssiko)
16:07:28 <anssik> ... Brandon drafted initial WebIDL in PR #75, thank you for initiating this work
16:07:29 <gb> https://github.com/webmachinelearning/webmcp/pull/75 -> Pull Request 75 Add WebIDL and descriptions to spec draft (by bwalderman)
16:07:40 <anssik> ... review from group participants welcome, thanks to Dominic and Francois for review comments
16:08:58 <anssik> Brandon: Chromium implementation informed the WebIDL draft, so should be in a rather good shape
16:09:18 <anssik> Dominic: we're define internal infra that browsers are expected to provide
16:10:17 <Grace> Grace has joined #webmachinelearning
16:10:25 <anssik> ... participants interested in helping with spec drafting via PRs, PR reviews, may find the following resources helpful:
16:10:29 <anssik> -> Bikeshed Documentation https://speced.github.io/bikeshed/
16:10:33 <anssik> -> Introduction to Writing Specifications with Bikeshed https://dlaliberte.github.io/bikeshed-intro/
16:10:37 <anssik> -> Writing Procedural Specs for the Web Platform using Bikeshed https://garykac.github.io/procspec/
16:11:20 <anssik> ... 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
16:11:48 <anssik> 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
16:12:06 <anssik> ... we've deployed a PR Preview tool that helps review specs via visual HTML diffs, complementary to source-level diffs
16:12:44 <anssik> ... there's two options to create local test builds, install bikeshed or use remote API via HTTP:
16:12:50 <anssik> -> https://speced.github.io/bikeshed/#installing
16:12:55 <anssik> -> https://speced.github.io/bikeshed/#remote
16:14:09 <anssik> Brandon: when I submitted the PR, it flagged some errors in Bikeshed
16:14:19 <anssik> ... my local Bikeshed did not report those errors
16:15:09 <anssik> Reilly: last time I looked at Bikeshed config it used a different
16:15:45 <anssik> Dominic: make sure to run bikeshed update locally to have all the data files up to date
16:16:07 <anssik> ... if your local bikeshed reports warnings, our workflow is set to fail on warnings too, not just errors
16:16:21 <anssik> Brandon: mine did not report as much
16:17:06 <anssik> Anssi: we've used label-based triage in this group:
16:17:11 <anssik> -> https://github.com/webmachinelearning/webmcp/labels
16:17:28 <anssik> 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
16:17:42 <anssik> ... I will empower the editors to add topic-specific labels that they feel help them be more productive, so we're lax about this
16:18:23 <anssik> Dominic: I added a new label for "declarative" issues
16:18:29 <anssik> ... ad-hoc makes sense
16:19:20 <anssik> Anssi: I propose we adopt a mechanism to signal priority "to be worked on soon" and "to be worked on later"
16:19:25 <anssik> ... some would use implicit "v1" and explicit "v2" to signal this
16:19:45 <anssik> ... issues labeled "v2" are "to be worked on later" while other issues are "to be worked on soon"
16:19:53 <anssik> ... the intent of this is to have a shared understanding among all participants where to focus attention to right now
16:20:10 <anssik> Mark: some other specs have used milestones, that's one option
16:20:11 <anssik> q?
16:21:45 <anssik> 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
16:22:17 <anssik> Anssi: "v2" is not a version in a traditional, could be "next"
16:23:14 <anssik> q?
16:23:47 <anssik> Subtopic: Declarative proposal
16:24:09 <anssik> Anssi: the group resolved that the declarative proposal complements the imperative WebMCP API, the latest proposal is discussed in issue #22 and PR #26
16:24:10 <gb> https://github.com/webmachinelearning/webmcp/issues/22 -> Issue 22 Declarative API Equivalent (by EisenbergEffect) [declarative]
16:24:10 <gb> https://github.com/webmachinelearning/webmcp/pull/26 -> Pull Request 26 Declarative proposal to expose tools via HTML (by MiguelsPizza)
16:24:55 <anssik> Dominic: we've built on top of PR #26, I submitted PR #79 with additional feedback
16:24:56 <gb> Issue 79 not found
16:25:29 <anssik> s/PR #79/PR #76
16:26:14 <johannhof> johannhof has joined #webmachinelearning
16:26:57 <anssik> Anssi: the latest PR documents what Chromium prototype implements?
16:27:35 <anssik> Dominic: right, we documented the GH issues feedback provided in #22 into this ‎declarative-api-explainer.md
16:28:23 <anssik> q?
16:28:43 <anssik> Anssi: there's a bunch of issues, so perhaps we focus on the meta-issue #22
16:29:36 <anssik> ... does PR #76 address some of the "declarative" labeled issues?
16:29:37 <gb> https://github.com/webmachinelearning/webmcp/pull/76 -> Pull Request 76 Declarative API Explainer (by domfarolino)
16:29:50 <anssik> Dominic: I will reference them from the explainer PR #76
16:29:51 <anssik> q?
16:30:28 <anssik> Anssi: I believe the Chromium prototype is currently focused on the "write" tools using <form> elements
16:30:58 <anssik> 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
16:31:04 <anssik> ... the <context> element was prototyped by VOIX, a web-native framework, and discussed in a paper contributed by Technical University of Darmstadt researchers:
16:31:07 <anssik> -> https://arxiv.org/abs/2511.11287
16:31:13 <anssik> Anssi: the benefit of a <context> element over <script>
16:31:21 <anssik> ... is the ability to be included in accessibility trees
16:31:46 <anssik> Brandon: we're looking for an element that is not visible to the user, ideally available to accessibility tools too
16:32:02 <johannhof> q+
16:32:09 <anssik> ... a new element with these semantics, no current element fits
16:32:14 <anssik> ack johannhof
16:33:00 <anssik> Johann: from a security perspective, the more go in a direction of specific purpose fields, ideally specific enum values, the more we go to that direction the better
16:33:01 <anssik> q?
16:33:33 <anssik> Johann: adding arbitrary context "write anything here" is harder to secure
16:34:44 <anssik> 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
16:35:09 <anssik> Johann: <context> element with arbitrary document, a difficult tradeoff wrt security
16:35:40 <anssik> Brandon: agent responsible whether to be compliant if <context> used only, or if fallback to other means is allowed
16:36:15 <anssik> Johann: need to take security into consideration when designing this
16:36:30 <anssik> Anssi: did the VOIX folks discuss security?
16:36:42 <anssik> Brandon: they discussed the privacy benefit
16:37:37 <anssik> Kryspin: is there any idea about website authors including private elements assuming the browser agent wouldn't use the DOM?
16:38:21 <anssik> ... 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
16:38:50 <anssik> Johann: would there be adversaries where sites are just unfriendly
16:39:18 <anssik> Kryspin: example, creditcard numbers in the DOM should fall into "do not track" regime
16:39:42 <anssik> Dominic: what is in scope of WebMCP, is what page agents run on the providers web site
16:40:09 <anssik> Kryspin: is that in scope?
16:40:36 <anssik> Dominic: we have a separate issue #57 for that
16:40:36 <gb> https://github.com/webmachinelearning/webmcp/issues/57 -> Issue 57 Allow iframes to declare tools (by khushalsagar)
16:41:07 <anssik> Kryspin: from a best practices standpoint it wouldn't hurt if it'd be part of the proposal
16:41:09 <anssik> q?
16:42:09 <anssik> q?
16:42:19 <anssik> Subtopic: Allow iframes to declare tools
16:42:24 <anssik> Anssi: issue #57
16:42:42 <anssik> ... the latest proposal currently restrict only the top-level browsing context to declare tools, this was discussed at TPAC 2025:
16:42:47 <anssik> -> https://www.w3.org/2025/11/11-webmachinelearning-minutes.html#39d8
16:43:04 <anssik> 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
16:43:21 <anssik> ... there's interest in the MCP-land to use WebMCP for Agent/Host -> MCP App communication:
16:43:26 <anssik> -> https://github.com/modelcontextprotocol/ext-apps/issues/35
16:43:27 <gb> https://github.com/modelcontextprotocol/ext-apps/issues/35 -> Issue 35 Adopt WebMCP for Agent -> UI communication (by MiguelsPizza) [enhancement]
16:43:44 <anssik> Anssi: MCP Apps are contained in <iframe> elements, so this is an important consideration
16:43:50 <anssik> ... Dominic chimed in on the MCP Apps spec PR:
16:43:53 <anssik> -> https://github.com/modelcontextprotocol/ext-apps/pull/72
16:43:54 <gb> https://github.com/modelcontextprotocol/ext-apps/pull/72 -> Pull Request 72 spec: Add tool registration for Apps, to be called by Host (WebMCP-style!) (by ochafik) [v2]
16:44:38 <anssik> 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
16:44:56 <anssik> ... there needs to be a way for MCP Apps to do this
16:45:22 <anssik> ... document policy needs opt-in, the right primitive, probably more investigation needed
16:45:35 <anssik> ... are there security issues is allowing this, Johann?
16:45:55 <anssik> ... top-level page that can register tools should be able to delegate that capability
16:46:08 <anssik> ... it'd be nice outcome to see these things converge
16:46:13 <anssik> q?
16:46:37 <anssik> q?
16:47:19 <anssik> 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
16:47:19 <anssik> q?
16:48:18 <anssik> Kryspin: in that scenario, the agent is not the browser agent, it is the chat element they're connected to
16:48:58 <anssik> ... agent refers to the MCP agent
16:49:45 <anssik> Dominic: from JS enumerate tools registered by the site, inner x-origin iframe, would register WebMCP tool, WebMCP would see that tool and associate it with MCP App and tell the model about this tool, and forward the tool to  the MCP App
16:49:54 <qcomp> qcomp has joined #webmachinelearning
16:49:56 <anssik> ... requires an agent host script to enumerate the tools
16:50:16 <anssik> Kryspin: subagents concept might help in terms of security
16:52:00 <anssik> Dominic: we're discussing the enumerate tools feature in a GH issue
16:52:01 <anssik> q?
16:52:42 <anssik> q?
16:52:49 <anssik> Subtopic: Should output also have a schema?
16:52:54 <anssik> Anssi: issue #9
16:52:54 <gb> https://github.com/webmachinelearning/webmcp/issues/9 -> Issue 9 Should output also have a schema? (by bokand) [Agenda+]
16:53:05 <anssik> ... the issue from David asks should we include an outputSchema (as in MCP)?
16:53:10 <anssik> -> MCP outputSchema spec https://modelcontextprotocol.io/specification/2025-06-18/server/tools#tool
16:53:15 <anssik> -> MCP outputSchema motivation and context https://github.com/modelcontextprotocol/modelcontextprotocol/pull/356
16:53:16 <gb> https://github.com/modelcontextprotocol/modelcontextprotocol/pull/356 -> CLOSED Pull Request 356 RFC: add tool `outputSchema` and `DataContent` type to support structured content (by lukaswelinder)
16:53:25 <anssik> Anssi: motivation to provide better context to the LLMs calling the tools
16:53:39 <anssik> ... this issue was opened August and Brandon +1'd, recently Khushal commented declarative WebMCP needs this too
16:53:52 <anssik> ... are we ready to resolve to add outputSchema to both imperative and declarative surfaces?
16:53:54 <anssik> q?
16:54:36 <anssik> Dominic: I think it is a good idea, biggest thing is how to associate this with declarative surface
16:56:58 <Mark_Foltz> Feel free to @ me on an issue if you want me to take a look
16:57:19 <anssik> RESOLUTION: Add outputSchema to the imperative API and investigate how to associate outputSchema with declarative WebMCP (issue #9)
16:57:26 <anssik> Subtopic: Accessibility considerations
16:57:30 <anssik> Anssi: issue #65
16:57:31 <gb> https://github.com/webmachinelearning/webmcp/issues/65 -> Issue 65 WebMCP accessibility considerations (by anssiko)
16:57:39 <anssik> ... one of the goals of WebMCP is to improve accessibility
16:57:56 <anssik> ... 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
16:58:10 <anssik> ... in #65 I documented a few areas that would benefit from a11y experts' contributions:
16:58:18 <anssik> ... - Review WebMCP use cases through the lens of accessibility.
16:58:18 <anssik> ... - Enhance existing and/or contribute new use cases that surface a11y requirements.
16:58:18 <anssik> ... - Initiate work on accessibility considerations for the emerging WebMCP draft spec.
17:00:08 <anssik> Leonie: I'm Leonie, working on web since 90s and a11y 00s, brought me to web community, Grace and Joe are working with our customers at intersection of a11y and agentic AI
17:01:21 <anssik> Anssi: does Microsoft have a11y folks who might want to collaborate with Leonie and team on this topic?
17:01:31 <anssik> Brandon: I will reach out
17:02:22 <anssik> 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
17:02:23 <anssik> q?
17:03:00 <anssik> Topic: Translator and Language Detector APIs
17:03:05 <anssik> gb, this is webmachinelearning/translation-api
17:03:05 <gb> anssik, OK.
17:03:09 <anssik> -> https://webmachinelearning.github.io/translation-api/
17:03:14 <anssik> Subtopic: Input formats for translation and language detection
17:03:17 <anssik> Anssi: issue #60
17:03:18 <gb> https://github.com/webmachinelearning/translation-api/issues/60 -> Issue 60 Input formats for translation and language detection (by tomayac)
17:03:40 <anssik> 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"
17:03:45 <reillyg> q+
17:03:45 <anssik> ... Mozilla standards position discussion surfaced some concerns
17:03:50 <anssik> -> https://github.com/mozilla/standards-positions/issues/1015#issuecomment-3800425641
17:03:51 <gb> https://github.com/mozilla/standards-positions/issues/1015 -> CLOSED Issue 1015 Web Translation API (by domenic) [position: negative]
17:04:00 <anssik> Anssi: it is not spec'd what input formats are supported, text, HTML, JSON, markdown etc.
17:04:16 <anssik> ... per Mozilla's feedback this is both an interop and security issue
17:04:37 <anssik> ... 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"
17:04:43 <anssik> ... I see Mozilla's position remains negative
17:04:47 <anssik> ... is there a solution that would work for Mozilla?
17:04:49 <anssik> q?
17:04:56 <anssik> q?
17:04:59 <anssik> ack reillyg
17:06:31 <anssik> 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
17:06:58 <anssik> ... to a certain degree, the developer has made security errors when they've implemented their site in a way this is possible
17:07:28 <anssik> ... 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
17:07:59 <anssik> ... to do that safe translation, to enhance the API, having a version of this API that uses either mimeType or takes a DOM element
17:08:17 <anssik> ... slight preference to DOM element solution
17:08:19 <anssik> q?
17:08:31 <anssik> RRSAgent, draft minutes
17:08:32 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/05-webmachinelearning-minutes.html anssik
17:08:46 <anssik> q?
17:09:00 <anssik> Ehsan: this is something I've been thinking recently, echo Reilly's point
17:09:19 <anssik> ... I feel this is a rabbit hole, whatever fix we present will make it less complicated but will be bypassed later
17:09:47 <anssik> ... other concern is these APIs could be used for obfuscation, could be obfuscation bypass, I will research this more and discuss with Reilly
17:09:56 <anssik> q?
17:10:01 <anssik> RRSAgent, draft minutes
17:10:02 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/05-webmachinelearning-minutes.html anssik
17:10:57 <anssik> Topic: Prompt API
17:11:02 <anssik> gb, this is webmachinelearning/prompt-api
17:11:02 <gb> anssik, OK.
17:11:05 <anssik> -> https://github.com/webmachinelearning/prompt-api
17:11:08 <anssik> Subtopic: TAG review
17:11:13 <anssik> Anssi: TAG review for the Prompt API was on the TPAC 2025 agenda
17:11:16 <anssik> ... but since we received the review response from the TAG only minutes before the F2F started, we deferred the response for later
17:11:20 <anssik> -> https://www.w3.org/2025/11/11-webmachinelearning-minutes.html#6f52
17:11:23 <anssik> Anssi: at our last telcon, we heard from Chrome folks the Prompt API is one of our biggest focus areas for 2026
17:11:27 <anssik> -> https://www.w3.org/2026/01/22-webmachinelearning-minutes.html#1af5
17:11:31 <anssik> Anssi: to help digest and respond to TAG review, we have split the feedback into topic-specific issues
17:11:34 <anssik> -> https://github.com/webmachinelearning/prompt-api/labels/tag-tracker
17:11:38 <anssik> Anssi: I'd like to use the remaining time to triage TAG review issues and assign owners
17:11:41 <anssik> ... this is an opportunity for all interested group participants to contribute to the Prompt API
17:12:08 <anssik> Reilly: we have triaged these issues internally
17:13:27 <anssik> 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"
17:13:48 <anssik> Reilly: the current Prompt API explainer allows an option to be implemented by remote model as opposed to a local model
17:14:16 <anssik> ... the context provided to Prompt API is solely decided by the site, these two things together create an important security boundary
17:14:20 <anssik> ... conceptulally
17:14:27 <anssik> s/conceptulally//
17:15:00 <anssik> Reilly: Prompt API has explicit non-goal to allow the site to prompt an agent that has additional user context outside the prompt
17:15:22 <anssik> ... that would be a security issue
17:16:20 <anssik> 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
17:16:42 <anssik> RRSAgent, draft minutes
17:16:43 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/05-webmachinelearning-minutes.html anssik
17:17:15 <anssik> q?
17:17:58 <anssik> RRSAgent, draft minutes
17:18:00 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/05-webmachinelearning-minutes.html anssik
17:18:56 <anssik> s/define internal/defining internal
17:19:25 <anssik> s/participants interested/Anssi: participants interested
17:20:07 <anssik> s/a different/a different version
17:20:28 <anssik> s/our workflow/note our workflow
17:21:30 <anssik> s/a traditional/a traditional software versioning sense
17:22:20 <anssik> s/GH issues feedback/GH issue feedback
17:22:37 <anssik> s/into this ‎declarative-api-explainer.md/in ‎declarative-api-explainer.md
17:23:37 <anssik> s/more go/more we go
17:25:11 <anssik> s/creditcard/credit card
17:26:38 <anssik> s/issues is/issues in
17:28:23 <anssik> s/from JS/JS
17:28:54 <anssik> s/register WebMCP tool, WebMCP would/WebMCP
17:30:12 <anssik> s/on web/on the web
17:30:31 <anssik> s/brought/a11y brought
17:30:42 <anssik> s/to web community/to the web community
17:33:23 <anssik> RRSAgent, draft minutes
17:33:24 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/05-webmachinelearning-minutes.html anssik
19:26:48 <Zakim> Zakim has left #webmachinelearning