Thanks Yash, I suppose there could be an argument that ModelContextGetTools counts and it's at 0.01% today. So, there is still quite a lot of headroom before reaching 0.5%. I would personally even be fine to exclude calls to GetTools which return an empty sequence (since no information is being conveyed) - so likely a lot more headroom there if you end up needing it.
Cheers, Rick On Mon, Nov 2, 2026 at 3:54 PM Yashaswini Kumar <[email protected]> wrote: > Hi Rick, > > We have: ModelContextExecuteTool > <https://chromestatus.com/metrics/feature/timeline/popularity/5943>, > ModelContextExecuteDeclarativeTool > <https://chromestatus.com/metrics/feature/timeline/popularity/5800>, > ModelContextExecuteImperativeTool > <https://chromestatus.com/metrics/feature/timeline/popularity/5799> and > ModelContextGetTools > <https://chromestatus.com/metrics/feature/timeline/popularity/5904> > > Thanks, > Yash > > On Mon, Nov 2, 2026 at 11:04 AM Rick Byers <[email protected]> wrote: > >> LGTM2. Seems like a metrics bug to me, I'd be happy to use actual tool >> invocation as the metric that matters here (that's where the burn-in risk >> would come from). Is there a public UseCounter for that already? >> >> Rick >> >> On Wed, Oct 28, 2026 at 11:59 AM Mike Taylor <[email protected]> >> wrote: >> >>> LGTM1, given the "actual invocation" info below. Thanks. >>> On 10/28/26 2:55 p.m., 'Yashaswini Kumar' via blink-dev wrote: >>> >>> Hi blink-dev and API Owners, >>> >>> We would like to request an Origin Trial usage limit exception for the >>> WebMCP experiment to allow page load usage to exceed the 0.5% warning >>> threshold up to a maximum of 2.0%. >>> >>> ### Context >>> >>> WebMCP's Origin Trial registration usage has recently crossed the >>> warning threshold, currently sitting at approximately 0.51% of all Chrome >>> page loads. Under typical Origin Trial guidance, reaching 0.5% warrants >>> either asking partners to throttle usage or requesting an exception from >>> API owners before approaching the 1.0% trial limit. >>> >>> ### Justification & Burn-in Risk Assessment >>> >>> We believe extending the threshold to 2.0% carries negligible web >>> burn-in risk for the following reasons: >>> >>> 1. Token Registrations vs. Actual Invocation: >>> >>> The ~0.51% metric reflects pages where WebMCP tools are registered >>> via token. However, actual runtime invocation and execution of WebMCP tools >>> by AI agents is orders of magnitude lower than the page registration rate. >>> Site users do not actively execute tool calls on every visit. >>> >>> 2. Plateaued Growth: >>> >>> Partner registrations have largely stabilized and plateaued over the >>> past several months, indicating steady experimentation rather than runaway >>> exponential growth across the broader web. >>> >>> 3. Continued Operational Monitoring: >>> >>> The WebMCP team actively monitors partner usage and retains tight >>> operational controls, ensuring we can intervene well before usage >>> approaches 2.0%. >>> >>> ### Request >>> >>> We request 3 LGTMs from the Blink API Owners to grant an exception >>> allowing WebMCP Origin Trial usage up to 2.0% of Chrome page loads. >>> >>> Thanks, >>> >>> Yash on behalf of the Chrome WebMCP team >>> >>> >>> On Tuesday, September 29, 2026 at 2:47:43 PM UTC-4 [email protected] >>> wrote: >>> >>>> 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/f5a0e368-dc5c-40ae-b1f6-ffb3808262c7n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f5a0e368-dc5c-40ae-b1f6-ffb3808262c7n%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> 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/d22099ab-5743-43ca-9a4e-6906cd926ec1%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d22099ab-5743-43ca-9a4e-6906cd926ec1%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> > > -- > [image: Google Logo] > Yashaswini Kumar > TPgM, Chrome Rendering & WebMCP > [email protected] > -- 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/CAFUtAY_boC7bN_thnY4Pmp8d4bAscGf%2BWnmVkHUN4y%3Db%3DZ7TvA%40mail.gmail.com.
