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), intothe page
hosting a a tool. We're tracking this in
https://github.com/webmachinelearning/webmcp/issues/62
<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
<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.
