– DRAFT –
WebML CG Teleconference – 3 September 2026

Anssi: as a reminder, we'll use IRC-based queue management in this meeting:

https://www.w3.org/guide/meetings/zakim.html#speakerqueue

Anssi: to suggest agenda topics, use Agenda+ label, e.g.:

Agenda+

Anssi: please welcome our latest new participants
… Josh Inch from Meta
… Naveen Chatlapalli from Ashling
… Chamara Somaratne from Sovereign Stack Global
… Nadia Eldeib from CodeYam
… Prashastha Mudannayake, Hitesh Parmar, James Yang, Wei Herr Teng, Channy Yun, Mahesh Lambe and Arnab Mandal Arnab as individual contributors
… welcome all!

Announcements

Awesome Built-in AI APIs and WebMCP

Anssi: our community has launched two curated directories of awesome things for built-in AI APIs and WebMCP
… special thanks to Kenji for contributing the first stab for the Built-in AI directory!

Awesome Built-in AI

Awesome WebMCP

Anssi: to contribute to these repos, please see the Contribution Guidelines
… contributions are welcome from group participants as well as from the broader community and public at large

WebMCP ecosystem growth update

Anssi: strong growth in the WebMCP ecosystem has been observed recently
… first, new implementation experience includes ChatGPT Desktop and Brave

https://github.com/webmachinelearning/webmcp/blob/main/implementation-status.md

Anssi: these new implementations complement the existing Chrome and Edge implementations currently in Origin Trials

Anssi: second, I'm pleased to signal boost The WebMCP Challenge for developers

https://openai.com/webmcp-challenge/

Anssi: this challenge is still open for 5 hours, after which the judges including Sarah, Ilya and Alex from this Community Group will evaluate all submissions
… top 10 will receive prizes from OpenAI and hackathon supporters
… the innovative apps built during the challenge will showcase the potential of WebMCP in real-world scenarios and will inform the WebMCP spec development

WebMCP polyfill

Repository: webmachinelearning/webmcp

Anssi: issue #252

<gb> Issue 252 Hosting official polyfill for WebMCP (by beaufortfrancois)

Anssi: in our last meeting we resolved to adopt and host an official polyfill for WebMCP in the webmachinelearning GitHub organization
… feedback has been highly positive
… to that end, I've created a new repository for the official WebMCP polyfill:

webmachinelearning/webmcp-polyfill

Anssi: interested contributors should reach out to me

Translator and Language Detector APIs

Repository: webmachinelearning/translation-api

Batched translation

Anssi: issue #85

<gb> Issue 85 Support for batched translation (by sushraja-msft) [Agenda+]

Anssi: this issue proposes an enhancement to allow process multiple inputs in a single batch for translation
… a concrete example is to translate multiple unrelated comments with independent context
… the proposed API shape change is to overload translate() and translateStreaming()'s input argument to accept a sequence of DOMStrings
… currently input is a single DOMString
… there's an issue #60 discussing HTML as input, this is a separate issue from the batched translation enhancement, to be discussed separately at a later date

<gb> Issue 60 Input formats for translation and language detection (by tomayac)

Anssi: batching increases throughput and allows separating context for each input in the batch

Sushant: well covered, Edge is prototyping this feature using an on-device model, we find different elements running in parallel is required for good performance, improving UX significantly
… if a developer calls this API multiple times and does not wait for the promise, we could batch the calls on the server side, but this brings this feature to the client-side API
… time to first translation slightly slower when batched, but total runtime significantly reduced with multiple inputs
… looking for other supporters for this feature

Reilly: I think I'm generally supportive
… a question whether this exactly is the style batching should work is the long term?
… wondering if there are other APIs where we could add similar batching feature

MikeW: I generally agree with Reilly, there's an obvious performance benefit to this, assuming API shape is reasonable, algorithm keeps entries in order
… PR is a good next step

Mikhail: no concerns, one thing to consider, maybe instead of explicit, alternative to allow implementations to do smart batching, push to queue and allow implementation to run them batched internally, pros and cons consideration

Sushant: we've prototyped what Mikhail proposed, did not see the full 2x performance improvement
… API would be cleaner but also introduces complexity, we're evaluating
… another topic to raise, HTML as input for translation, issue #60

<gb> Issue 60 Input formats for translation and language detection (by tomayac)

Sushant: maybe we need to submit pieces of content, e.g. some bolds bolded, how to translate that, if preserving the bold tag, the result would be incorrect translation currently
… how does this interact with batching feature is something I've thought about

MikeW: in the past we discussed having markers in the stream of content and try to preserve those, perhaps worth exploring that approach
… either location in the text, or ranges of text, look for prior cases in text processing libraries tackling the same issues

<msw> +1

<reillyg> +1

RESOLUTION: Draft spec change for batched translation feature. (issue #85)

Prompt API

Repository: webmachinelearning/prompt-api

Extended thinking, tool calling, multi-turn execution

Anssi: issue #209

<gb> Issue 209 Extend the Message format to support tool calling, extended thinking, and multimodality (by nico-martin) [Agenda+]

Anssi: I want to continue the discussion on this issue, and zoom in to the subset of features on which the plans seem to mostly align between Chrome and Transformers.js/ORT implementation
… Jingyun from Chrome team summarized this intersect of plans in a comment:

webmachinelearning/prompt-api#209 (comment)

<gb> Issue 209 Extend the Message format to support tool calling, extended thinking, and multimodality (by nico-martin) [Agenda+]

MikeW: brief update from Chrome
… we're able to enable dev trial prototype for tool calling using Gemma 4
… behind a flag, using an open-loop pattern
… next stage to do validation and constrain decoding

<msw> https://chrome.dev/web-ai-demos/prompt-api-tool-use/

MikeW: we published demo ^

MikeW: this demo asks the model to generate call, and invokes those calls, closes the loop
… the demo is functional, I can do quick live demo at a later stage
… excited to hear Nico's comments and thoughts
… on the spec side want to resolve constraints issues, multi-modal needs some baking in

Nico: quick background, our Transformers.js implementation has so many tasks, so that's why we don't have LLM specific API, so I created an Agent SDK to align with a standard API, thus adopted Prompt API
… ran into tool calling issue
… where are you using constrained decoding in tool calling?

MikeW: in generation, ensuring the model can generate an input schema that validates the JSON schema

Nico: could generate just text, or schema that it uses for tool calling
… we support so many models and tokenizers, each have different signatures etc.
… I want to bake in some sort of mapping, and parse all into one structure that can be used with the API

MikeW: in our case we've used JSON to describe, align with imperative tool declarations
… would like to see how that aligns with multi-modal inputs
… any feedback on that?

Nico: not yet, output would be something that returns to the conversation loop?
… if the messages support multi-modal input, the model should not care if it's coming from the user or the tool
… fetching an image, passing to another tool, haven't thought about this much

MikeW: about thinking modes, using LiteRT for implementation, no specific proposal at this stage

Nico: we have to parse thinking and the rest is response

MikeW: would that correspond to a different role, or be another tagged response?

Nico: I think it'd be an object with one property and content is another property

Nico: the message coming back, role content thinking and then tool calls

MikeW: SGTM

Sushant: how would you manage streaming in that case?

Nico: when text comes back, would parse and return always the same structure
… the return would be the whole object, thinking text, the next chunk comes in, the same object but with one token more

Sushant: API for streaming return ReadableStream and you can iterate chunk objects in the stream?
… first object would be a thinking object?
… implementer has to swallow the thinking marker

Nico: would always return everything generated up until now, always return the full response so it is easy to parse by developers, no need to get the chunks and parse the response

<sushraja> https://developer.chrome.com/docs/ai/prompt-api#streamed_output

Sushant: that is different from how the Web API is today

Reilly: question, do we return thinking token at all, do developers care, should we allow to not return that optionally
… want to be least confusing

MikeW: a second ReadableStream dedicated for thinking?

Reilly: similar to open-loop vs closed-loop tool calling question
… can be confusing, we want one stream, I think

Nico: how do you handle streaming with tool calling?

Reilly: for tool calling, not sure

Sushant: accummulates and return a different object on the stream, I think

<msw> https://crsrc.org/c/third_party/blink/renderer/modules/ai/language_model_create_options.idl;drc=c715d8755be0931dc48f3ff1fcbceb111bf97d19;l=15

Nico: for each iteration of the stream, if the text gets longer, can use the latest iteration, returning the same object for each iteration seemed easier to work with

<msw> https://isaacahouma.github.io/prompt-api-sampling-presets/

MikeW: we've adjusted the Prompt API based on feedback, the demo showcases this ^

WebMCP

Repository: webmachinelearning/webmcp

Wide review

Anssi: first, I'd like to discuss actionable feedback from the ongoing TAG, Privacy and Security reviews

<sushraja> jFYI - The explainer needs to be implemented for how tool call works webmachinelearning/prompt-api#tool-use. It does not describe the current open loop design.

Anssi: the TAG and Privacy reviews are work in progress

Anssi: Security group has delivered a Threat Model for WebMCP document for your review:

https://simoneonofri.github.io/threat-model-webmcp/

Anssi: review comments are welcome via the GH repo:

https://github.com/simoneonofri/threat-model-webmcp/issues

Anssi: please note this is an "Unofficial Proposal Draft", so rough around the edges
… thanks to the Security Group's Simone, Zahra, Amir and Giovanni for their contributions
… and thank you to Victor for stepping in to review this document

Victor: I had a chance to read the document, it is a good starting point for a security analysis of WebMCP
… going forward I'll open GH issues on the threat model repo

Julia: I have reviewed security aspects of the spec

Anssi: in our last meeting we resolved to initiate wide review of WebMCP with the i18n and a11y groups
… in this second phase of WebMCP wide review we expand to the web internationalization (i18n) and web accessibility (a11y) experts
… there's careful pre-work for both

Anssi: a11y review expects two pre-work items to go along the review request
… 1) completed a11y review checklist, staged in issue #272

<gb> Issue 272 WebMCP accessibility review checklist (by anssiko) [Agenda+] [a11y-tracker]

Anssi: I've included instructions in the issue itself, and welcome contributions from the group participants via issue comments there
… 2) respond to the a11y group's initial comment:

webmachinelearning/webmcp#65 (comment)

<gb> Issue 65 WebMCP accessibility considerations (by anssiko) [a11y-tracker]

Anssi: feel free to ask questions from the a11y group, we want this to be a collaborative exercise that strengthens the WebMCP accessibility story even further

Anssi: questions, comments?

<Victor> i18n will be very interesting for WebMCP :) Not an expert here, but kind of implied that the model has to handle different kind of metadata inputs? and what if the model properties are different for different languages? there has been demonstrations where for example prompt injections happen in one language on a model, but not the other.

Sarah: I talked to folks interested in a11y
… will loop them in

Anssi: i18n reviewers expect us to work with the checklist staged in issue #273

<gb> Issue 273 WebMCP internationalization review checklist (by anssiko) [Agenda+] [i18n-tracker]

Anssi: for any item on this checklist that has open questions, open a new i18n-tracker issue so i18n experts are notified and can help address the issue
… we have identified the following i18n issues so far:

i18n-tracker

Anssi: please review the i18n checklist, the existing i18n-tracker issues, and open new i18n-tracker issues for any open questions you encounter
… I look forward to initiating both the a11y and i18n review processes with the group as we prepare WebMCP for wide-scale global adoption

Tool collections

Anssi: issue #255

<gb> Issue 255 Tool collections: coarse-grained grouping with progressive disclosure (by sdras) [Agenda+]

Dominic: explicit group primitive may be too early, based off of the MCP precedent, would like to hear how these tools are used and how harnesses use these
… would like to seek more feedback from MCP folks working in this problem space

Sarah: that makes sense, I suggest we don't get just agent perspective but also site developer perspective

Dominic: it is delicate balance, the question is what small information we can offer to help agents, or handle this on the platform side

Sarah: simplicity of WebMCP is important
… we want to keep those benefits in mind, mental model of keeping skills, autonomy issue with a very large app, initially the user does not have access to the entire toolset

Alex: this space evolves so quickly, MCP has been going back and forth on the design, we should listen to developer feedback, too early to develop a solution

Dominic: does MCP help harness guide its search?

Alex: very much undecided

<domfarolino> +1

<Alex9> +1

RESOLUTION: Seek explicit model harness creator feedback and defer the tool collections feature. (issue #255)