WebMCP is available for early preview
Google’s proposed WebMCP standard would let websites expose structured “tools” that browser-based AI agents can call, promising smoother automation for tasks like booking flights or shopping directly through the page. Commenters are split: some see it as a practical way to make the web more machine-usable and reduce brittle scraping, while many fear it will deepen Google’s control over the web, sidestep existing API and accessibility standards, enable dark patterns, and repeat the mistakes of AMP and the failed Semantic Web. Overall, skepticism centers on incentives—whether major sites will actually adopt WebMCP, and whether doing so ultimately benefits users, site owners, or primarily the AI platform vendors.
What WebMCP Is Supposed to Do
- Expose site-defined “tools” that AI agents in the browser can call to perform actions (e.g., search flights, submit forms, shop) instead of scraping or DOM-driving.
- Framed as a way to make websites more “agent-friendly” and reduce brittle browser automation.
- Requires a visible browsing context; no fully headless calls.
APIs, Semantic Web, and Existing Standards
- Many argue this is reinventing what REST/OpenAPI/HATEOAS/semantic web already tried to do: machine-readable actions and data.
- Some say a simple standardized API spec (e.g.,
.well-known/openapi.yaml) would suffice. - Others see WebMCP as distinct: closer integration with the actual page/session, blending UI and programmatic control.
- Comparisons drawn to the failed promise of the semantic web and to XML/XHTML on the web.
Business Incentives, Control, and Google’s Role
- Strong concern that this is another Google-driven “standard” like AMP: nudging sites to adopt it, then using ranking/visibility as leverage.
- Fear that agents mediated by big vendors will gate which sites are visible or actionable, further centralizing power.
- Ad- and walled-garden–based sites are seen as unlikely to expose real tools that bypass ads or make price comparisons trivial.
Automation, Scraping, and Abuse
- Confusion over why sites fight Selenium/scrapers yet would adopt WebMCP; answer from some: it’s about authorized vs unauthorized automation.
- Worries that tools can be abused for fraud, high load, or scraping; others think offering official machine endpoints might reduce shady scraping.
- Some propose deceptive tools (fake signup, fake success) to block bots, but others note this quickly becomes an arms race.
Security, Trust, and Threat Models
- Concern that malicious sites could define tools that exfiltrate context or mislead agents (e.g., bogus “add_to_cart”).
- Counterpoint: agents that already have “web fetch” are already exposed to untrusted sites; the main boundary remains what private data the agent holds.
Accessibility and User Experience
- Several argue effort should go into proper accessibility (semantic HTML, a11y APIs) rather than a new agent-only channel.
- Others see WebMCP-level tooling as potentially the “optimal” accessibility layer if combined with conversational agents, though not aligned with current legal a11y frameworks.
Adoption Prospects and Developer Sentiment
- Opinions split: some see this as inevitable and “Web 2.0 for agents”; others predict limited uptake or quick abandonment like AMP.
- Complaints that official docs and examples are thin, marketing-heavy, and not developer-friendly.
- Overall tone: intrigued but heavily skeptical of incentives, centralization risk, and real-world usefulness of the proposed use cases.