Hey Alex, yeah, we’re hoping to move to I2S within the extension window.

So far we’ve learned a lot:

The imperative API is a lot more popular than the declarative one, so we're 
investing more into it in response to user needs.

   1. 
   
   We received excellent feedback from Mozilla 
   <https://github.com/webmachinelearning/webmcp/issues/236> about API 
   changes we can make to benefit non-AI use cases, as a generic cross-realm 
   function-calling primitive.
   2. 
   
   We've heard from partners with tools whose entrypoint is on one page, 
   while the result is on another (after a navigation). So we're prototyping a 
   continuation API 
   
<https://github.com/webmachinelearning/webmcp/blob/cont-explainer/continuations-explainer.md>
 
   that we'd like to get into the hands of developers.
   3. 
   
   We and popular frameworks anticipate gaps between async tool 
   registration and when an agent collects a "snapshot" of a page's tools 
   (driven by its page loading heuristics). So we're prototyping a tool 
   stability API <https://github.com/webmachinelearning/webmcp/issues/328> 
   to let developers inform agent heuristics when an appropriate observation 
   time might be. We're discussing this with major model vendors and want to 
   understand how this impacts performance in the real world.
   4. 
   
   Some developers expressed a desire to pass user activation from an 
   in-page agent (on a top-level document), into the page hosting a a tool. 
   We're tracking this in 
   https://github.com/webmachinelearning/webmcp/issues/62, but before 
   pursuing a proposal like capability delegation 
   <https://github.com/WICG/capability-delegation>, we'd like more 
   experimentation to help us understand how much this comes up in practice.
   5. 
   
   We're exploring what it might look like to enforce size/character limits 
   on tools <https://github.com/webmachinelearning/webmcp/issues/219>, and 
   we'd benefit from more time to experiment after discussing what a 
   reasonable limit might look like with other browsers and major model 
   vendors.
   

Those are a few things we've learned so far, and in particular, how we'd 
benefit from an extended experiment to understand how our proposed changes 
play with real-world sites and agents.
On Monday, September 28, 2026 at 7:57:08 PM UTC-4 Alex Russell wrote:

> LGTM1 conditional on some summary of developer feedback from the first OT. 
> What did we learn? Are we making API shape changes in response? And why 
> aren't we moving to I2S yet (or is that anticipated in this extension 
> window)?
>
> Best,
>
> Alex
>
> On Monday, September 28, 2026 at 4:13:33 PM UTC-7 Chromestatus wrote:
>
>> *Contact emails*
>> [email protected], [email protected], [email protected], 
>> [email protected], [email protected], [email protected], 
>> [email protected]
>>
>> *Explainer*
>> https://github.com/webmachinelearning/webmcp
>>
>> *Specification*
>> https://webmachinelearning.github.io/webmcp 
>>
>> *Design docs*
>>
>>
>> https://docs.google.com/document/d/1ZaQvuj4YnUnoqOfEhbfgFynpDRKk2zZZHavTNJ151gM/edit?tab=t.0#heading=h.ggi78l861caa
>>
>> https://docs.google.com/document/d/1ycdzuXA-VE8lRDFSArh0Um3PChHV0Hq6Om1MSMG8qPE/edit?tab=t.0#heading=h.edohi3f5z12h
>>
>> *Summary*
>> WebMCP is a proposal for a web API that enables web pages to provide 
>> agent-specific paths in their UI. With WebMCP, agent-service interaction 
>> takes place via app-controlled UI, providing a shared context available to 
>> app, agent, and user. 
>>
>> *Blink component*
>> Blink>Agentic Platform>WebMCP 
>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EAgentic%20Platform%3EWebMCP%22>
>>
>> *Web Feature ID*
>> document-modelcontext 
>> <https://webstatus.dev/features/document-modelcontext> 
>>
>> *Search tags*
>> WebMCP <http:///features#tags:WebMCP>
>>
>> *TAG review*
>> Spec is being incubated. We will request TAG review before shipping. 
>>
>> *TAG review status*
>> Pending
>>
>> *Origin Trial Name*
>> WebMCP
>>
>> *Goals for experimentation*
>> For the experiment we are focused on understanding the API ergonomics for 
>> agentic workflows across various verticals such as web commerce and 
>> productivity. We expect the site owners to implement WebMCP tools in their 
>> sites to automate high-value workflows for them and will seek feedback on 
>> the functionality of WebMCP. We also plan to gather metrics for tool usage 
>> and latency, and assess opportunities for improvements. 
>>
>> *Chromium Trial Name*
>> WebMCP
>>
>> *Origin Trial documentation link*
>>
>> https://docs.google.com/document/d/1ZaQvuj4YnUnoqOfEhbfgFynpDRKk2zZZHavTNJ151gM/edit?tab=t.0#heading=h.ggi78l861caa
>>
>> *WebFeature UseCounter name*
>> kModelContextRegisterTool 
>>
>> *Risks*
>>
>>
>> *Interoperability and Compatibility*
>> Given this is a new space and new API - there's no compatibility risk. 
>> Usual risk related to other browser vendors not adopting the API apply. 
>> This API is meant to augment capabilities provided by browser add-ons and 
>> so non-adoption in other engines would have limited user-impact and thus we 
>> consider the risk to be low. 
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals Web Framework developers: Have shown a 
>> great deal of interest during the developer trial, as evidenced here: 
>> https://www.star-history.com/?repos=webmachinelearning%2Fwebmcp&type=date&legend=bottom-right
>>  
>> Chrome web store features about 9 different extensions with WebMCP on their 
>> title and 4* or more ratings. 
>> https://chromewebstore.google.com/search/WebMCP?minimalRating=4 
>>
>> *Other signals*:
>>
>> *Ergonomics*
>> There is a risk that site authors that wish to incorporate WebMCP tools 
>> into their sites will need to duplicate functionality that currently exists 
>> to drive the user interface. We're hoping that most imperative WebMCP tools 
>> are just thin wrappers around existing code that drives actions on the 
>> site, but we are working with framework developers like React to ensure 
>> that WebMCP tools can be added without rearchitecting the site logic. We 
>> are also offering a declarative version that requires only adding 
>> attributes to existing form elements, which is much lighter weight to 
>> deploy and does not require any refactoring of existing site functionality. 
>>
>> *Activation*
>> There are no activation requirements to register WebMCP tools. To execute 
>> WebMCP tools does require an agent, either provided by the browser or site 
>> author, to formulate and orchestrate tool calls. There are several Chrome 
>> extensions already available that allow cloud-LLM-based agents to discover 
>> and call WebMCP tools. It is also possible to use the Prompt API to call 
>> WebMCP tools using on-device models.
>>
>> *Security*
>> Sites may consume and expose sensitive information when their WebMCP 
>> tools are called by agents. Agents should implement safeguards to ensure 
>> that sensitive information is passed to sites and between origins only 
>> under the consent of the user that is supervising them. LLM-based agents 
>> are susceptible to attacks such as indirect prompt injection, which can 
>> cause an exploited agent to exfiltrate sensitive information in its context 
>> to an attacker. Agents should implement safeguards against prompt injection 
>> and related attacks. 
>>
>> *WebView application risks*
>>
>> Does this intent deprecate or change behavior of existing APIs, such that 
>> it has potentially high risk for Android WebView-based applications? 
>> *No information provided* 
>>
>>
>> *Reason this experiment is being extended*
>> OT feedback has suggested improvements to the API, which we are 
>> implementing. The OT extension would enable us to get data on those 
>> improvements as well as to continue getting data on the rest of the feature.
>>
>> *Ongoing technical constraints*
>> No technical constraints for the experiments. 
>>
>> *Debuggability*
>> Explicit debugging support through a new WebMCP Chrome DevTools Protocol 
>> domain. The domain supports listing registered tools, invoking tools, and 
>> logging all calls by agents. Registration issues for declarative tools 
>> (e.g., missing names or descriptions) are reported through the Audits 
>> domain. 
>>
>> *Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, ChromeOS, Android, and Android WebView)?*
>> Yes
>>
>> *Is this feature fully tested by web-platform-tests 
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
>> No 
>> The IDL and basic usage is tested via WPTs. Since the API provides the 
>> user agent with the ability to call certain tools, we might need to extend 
>> the WPT harness to support this.
>>
>> *DevTrial instructions*
>>
>> https://docs.google.com/document/d/1rtU1fRPS0bMqd9abMG_hc6K9OAI6soUy3Kh00toAgyk/edit?tab=t.0
>>
>> *Flag name on about://flags*
>> Experimental Web Platform features 
>>
>> *Finch feature name*
>> WebMCP 
>>
>> *Requires code in //chrome?*
>> True
>>
>> *Tracking bug*
>> https://crbug.com/445637567
>>
>> *Launch bug*
>> https://launch.corp.google.com/launch/4460611
>>
>> *Estimated milestones*
>> Origin trial desktop first 149 
>> Origin trial desktop last 156 
>> Origin trial extension 1 end milestone 162 
>> DevTrial on desktop 146 
>> Origin trial Android first 149 
>> Origin trial Android last 156 
>> DevTrial on Android 146 
>> Origin trial WebView first 149 
>> Origin trial WebView last 156 
>>
>> *Link to entry on the Chrome Platform Status*
>> https://chromestatus.com/feature/5117755740913664?gate=5151396285513728
>>
>> *Links to previous Intent discussions*
>> Intent to Prototype: 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMmsAtRdyRw1WtO5va0K%3D_adYH-FRh01xvw5%2BosSd_DAq%3D%3DUQ%40mail.gmail.com
>> Ready for Trial: 
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/bhhOmTGzD5Y/m/PGdM8lF6AQAJ
>> Intent to Experiment: 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a076b26.050a0220.3377b4.05fa.GAE%40google.com
>>
>>
>> This intent message was generated by Chrome Platform Status 
>> <https://chromestatus.com>. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a50aef4-3b8d-4aab-9f42-c307119df535n%40chromium.org.

Reply via email to