On this page · 10 sections
Summary. Google opened the WebMCP origin trial from Chrome 149, which reached stable on 2 June 2026, and last revised the documentation on 7 August 2026. Until a site adopts it, a browser agent completes a task on your checkout the only way it can: by reading the DOM and simulating clicks. Adobe Analytics, covering over 1 trillion visits to US retail sites, recorded AI-sourced traffic up 393% year over year in the first quarter of 2026, converting 42% better than non-AI traffic in March 2026, off a 2025 holiday season that drove a record $257.8 billion in US online spend with AI traffic up 693.4%. Adobe also scored the average US retail product page at 66% machine readability against 75% for homepages. Two facts set the scope of the work: annotating an existing HTML form takes two attributes, and a tool description has a recommended budget of 500 characters. This article sets out what an agent-ready build involves, in what order, and where it stops being an engineering question.
The problem, stated without hype
An AI agent acting on a user's behalf inside a browser has no privileged view of your application. Google's documentation calls the current approach actuation: "the act of an agent simulating manual mouse clicks and text input, as though it were the human user engaging with your website." The agent reads your page, forms a theory about which control does what, and acts on that theory.
That works until it does not. A relabelled button, a new interstitial, a variant in an A/B test, a field that appears only after another field is filled, and the agent's theory breaks. Nothing errors. The task silently completes wrongly or not at all, and you have no telemetry that says so.
WebMCP changes the contract. Your page registers named tools with a JSON Schema, and the agent calls checkout or filter_results rather than guessing. Google's own framing of why this survives a redesign is the commercially important part: WebMCP tools "connect to application logic, not design," so shipping a new front end does not break agent compatibility.
For a business, that is the difference between a capability you build once and a surface that regresses every release.
Is this urgent, or is it 2027 work?
Honest answer: it depends on where your traffic comes from, and the best available measurement is American.
Adobe's data is the strongest public series. AI-sourced traffic to US retail sites grew 393% year over year across January to March 2026 and 269% year over year in March 2026 alone. The conversion picture reversed inside a year: AI traffic converted 38% worse than non-AI traffic in March 2025, and 42% better by March 2026. Engagement ran 12% higher, time on site 48% longer, and pages per visit 13% higher.
"This 2025 holiday season, consumers embraced generative AI more than ever as a shopping assistant in their purchasing decisions," said Vivek Pandya, lead analyst, Adobe Digital Insights, in Adobe's 7 January 2026 season recap.
We do not have an equivalent India-specific series, and we are not going to invent one. What is observable is that agent-sourced sessions are a smaller share of Indian traffic today than Adobe's US figures imply, and that the direction is the same. That produces a specific recommendation rather than a panic: do the cheap part now, defer the expensive part until your own analytics justify it.
| Work | Effort | When to do it |
|---|---|---|
Annotate existing HTML forms with toolname and tooldescription |
Days | Now, during the origin trial |
| Write read-only imperative tools such as order lookup | 1 to 2 sprints | Now, if you have agent traffic to measure |
Audit and remove document.domain usage |
Varies, can be large | Now, because it is a hard blocker |
| Write state-changing tools for cart and account | 2 to 4 sprints | After read-only tools show real agent calls |
| Expose checkout as an auto-submitting tool | Deliberate, with legal review | Only with explicit user confirmation retained |
| Cross-origin tool exposure to partners | Per integration | When a named partner needs it |
The first row is the point. Two HTML attributes on a form you already ship turn it into a callable tool, and the browser derives the JSON Schema from your field names, required attributes and <select> options. That is a genuinely small piece of work with a genuinely asymmetric payoff.
What the build actually involves
An inventory, before any code. List the tasks a user completes on your site, mark which already exist as an HTML form, and mark which an agent would plausibly attempt on a user's behalf. In ecommerce that is usually search, filter, order lookup, support request, returns initiation and account update. Checkout sits in its own category.
A blocker audit. WebMCP runs only in origin-isolated documents. If a page enables document.domain, for example by sending the Origin-Agent-Cluster: ?0 header, the APIs are disabled outright. Older Indian ecommerce stacks with cross-subdomain scripting between a storefront and an account subdomain hit this immediately, and it is not a WebMCP fix, it is a front-end architecture fix. Finding it in week one is much cheaper than finding it in week six.
The declarative pass. Add toolname and tooldescription to existing forms, then verify each derived schema. A <select> with vague option labels produces a vague enum, and the agent's accuracy degrades accordingly. This is where a surprising amount of the value sits, and it is content work as much as engineering.
The imperative pass. Write JavaScript tools for flows with no form: navigation, state changes, data lookups. Every tool carries a name, a description, an input schema and an execute function, plus annotations. readOnlyHint tells an agent the tool does not change state so it can reserve confirmations for the ones that do. untrustedContentHint labels a payload as untrusted, which Google recommends for anything returning user-generated or externally sourced data.
The copy. Google publishes character budgets: 500 characters per tool description, 150 per parameter description, 30 characters each for tool and parameter names, and 1.5K characters per tool output. Writing a tool description that is unambiguous inside 500 characters is the task that decides whether an agent picks your tool or falls back to clicking around. Teams consistently underestimate this and consistently find it is the bottleneck.
The security review. Google's guidance is blunt about the risk: because language models treat text, instructions and user data as one token sequence, they are open to indirect prompt injection, and it is impossible to guarantee safety inside a probabilistic model. Google's own bug hunters have documented repeatable prompt injection attacks against agentic systems. Any tool that returns content you did not author needs the untrusted hint and a hard look at what an attacker could make it do.
Checkout deserves its own paragraph
The declarative API has two submission modes. By default the agent fills the form and the user clicks Submit, which keeps a human in the loop by construction. Adding toolautosubmit makes the model's invocation trigger submission and navigation directly.
Our position for anything that moves money is the conservative one, and we will argue it in a scoping call. Keep the manual submit. It matches how additional factor authentication already works in Indian payment journeys, it keeps the confirmation inside your own interface where the user can see what they are agreeing to, and it costs you nothing in agent compatibility because the agent still completes every step up to the final press.
The SubmitEvent.agentInvoked boolean tells you when an agent triggered a form, which means you can branch behaviour rather than treating agent and human traffic identically. That is the hook for fraud rules, for analytics, and for a different confirmation UI. Most teams discover it late; it belongs in the first design conversation.
The wider standards picture, including how agentic checkout protocols interact with this, is set out in our agentic commerce standards guide for merchants, and the demand-side view is in AI shopping agents and D2C agentic commerce.
The DPDP questions start earlier than teams expect
Any tool that returns order history, saved addresses, loyalty status or payment instruments is processing personal data under the Digital Personal Data Protection Act 2023, and an agent invoking that tool on a user's behalf is a processing context your notice and consent design probably does not describe yet.
Three practical defaults we apply:
Mark those tools readOnlyHint: true so the agent treats them as reads and reserves confirmations for state changes. Never set toolautosubmit on a step that moves money or changes an account credential. And treat cross-origin exposure as a data-sharing decision rather than a configuration flag, because exposedTo is exactly that. Google's own example makes the point: a read-only tool such as getFavoriteProducts reveals information about a user, so expose it only to origins you would share that data with anyway.
One structural advantage is worth knowing. WebMCP tools are ephemeral. They exist only while the page is open, and once the user navigates away or closes the tab, the agent cannot act. There is no persistent agent-facing endpoint sitting on the internet to secure, patch and monitor, which is a materially smaller attack surface than a public MCP server. Where you do need that server-side capability as well, our MCP server development and integration service covers it, and the enterprise control side is in agentic browser enterprise data security controls.
How eCorpIT scopes this work
We run it in three phases, and we will tell you to stop after phase one if the data does not support going further.
Phase one, readiness and quick wins. A blocker audit covering origin isolation and document.domain, a tool inventory across your live journeys, the declarative annotation pass on existing forms, and validation of every derived schema in the Model Context Tool Inspector. This is the phase that fits inside a normal sprint and produces something shippable.
Phase two, read-only imperative tools and measurement. Order lookup, availability, filter and search tools written against your existing APIs, with the annotation hints in place, plus instrumentation that distinguishes agent-invoked traffic from human traffic so you can see whether agents find and call your tools at all. Measurement before write tools is the discipline that keeps the budget honest.
Phase three, state-changing tools and hardening. Cart, account and support-request tools with confirmation flows, the prompt injection review, cross-origin exposure decisions if partners are involved, and the DPDP notice and consent updates that follow. Origin trial tokens are time-limited, so token renewal goes into your deployment checklist rather than into someone's calendar.
On engagement model: this is senior-led delivery from our Gurugram team, working alongside your existing front-end engineers rather than replacing them, because the people who know which button matters are already on your payroll. We work to CMMI Level 5 process discipline and hold ISO 27001:2022, and we design applications aligned with DPDP requirements where personal data is in scope. eCorpIT has been building for product teams since 2021, and our partner relationships include AWS, Microsoft, Google and Shopify, which matters here mainly because Shopify and headless storefront work is where most of the annotation effort lands for D2C brands.
Pricing depends almost entirely on how many distinct journeys you want exposed and on what your blocker audit finds, so we scope it after phase zero rather than quoting a number into a vacuum. A storefront with clean origin isolation and six well-built forms is a fundamentally different engagement from a legacy stack that still relies on document.domain.
The developer-level detail behind all of this, including working code for both APIs and the full permissions model, is in our companion guide to WebMCP in Chrome 149, and the wider platform context sits in our Interop 2026 web platform developer guide.
What we would tell you not to do
Do not rebuild your site for agents. WebMCP is a progressive enhancement by design, and a team proposing a rewrite to support it has misread the problem.
Do not expose write tools before you have evidence that agents are calling your read tools. The volume tells you whether this is a 2026 investment or a 2027 one, and read-only tools carry almost none of the risk.
Do not treat machine readability and WebMCP as the same project. Adobe's readability scores measure what a language model can extract from your page; WebMCP governs what an agent can reliably do on it. A product page can score well on one and still leave an agent unable to add to cart. Both are worth doing. They are not the same budget line.
And do not build against navigator.modelContext. It is deprecated in Chrome 150 in favour of document.modelContext, and code written against the old path will stop working quietly.
How eCorpIT can help
eCorpIT builds agent-ready web surfaces for Indian ecommerce, D2C and SaaS teams, covering the origin-isolation audit, the form annotation pass, imperative tool design, the prompt injection review and the DPDP-aligned consent work that follows. Our senior engineering teams work to CMMI Level 5 process discipline and ISO 27001:2022 controls, and we design applications aligned with DPDP requirements where personal data is in scope. If you want a scoped readiness assessment of which journeys on your site are worth exposing as tools during the origin trial, contact us.
FAQ
References
Last updated: 14 August 2026.
