Field report · · AgentConn Team
Agents Now Have Three Ways Into Your App
WebMCP, ChatGPT Chrome, and CLI-Anything represent three competing visions for how agents drive the web. Here is what to build for.
Agents Now Have Three Ways Into Your App
In a single week of October 2026, three events collided that reveal an uncomfortable truth about the agentic web: nobody agrees on how agents should talk to your application.
On October 19, Chrome for Developers published a new video answering questions about WebMCP — the W3C-incubated standard that lets websites expose structured, callable tools to browser agents through navigator.modelContext. Four days earlier, OpenAI upgraded its ChatGPT Chrome extension to a full browser agent that reads, clicks, and types across your open tabs in Work mode — no structured protocol required. And on GitHub Trending, CLI-Anything from HKUDS continues its tear at 55,400 stars and +607 stars per day, wrapping desktop software in agent-native CLIs that bypass the browser entirely.
Three approaches. Three philosophies. One question: who owns the interface layer between agents and the web?
This matters because the interface layer is where value accrues. Whoever controls how agents discover and invoke your application’s capabilities controls the economics of the agentic web — from attribution to billing to security. And right now, three incompatible answers are racing to become the default.
The Three Contenders
1. WebMCP: The Structured Protocol Path
WebMCP is the closest thing the industry has to a diplomatic solution. Co-developed by engineers from Google and Microsoft under the W3C Web Machine Learning Community Group, it proposes that websites declare their capabilities as typed, callable tools — complete with JSON Schema input definitions, output contracts, and permission gates.
The technical surface is clean. Sites can use a Declarative API to annotate existing HTML forms as agent-callable tools, or an Imperative API to register JavaScript functions via navigator.modelContext.registerTool(). Both approaches are gated by the tools Permissions Policy, defaulting to same-origin contexts. The browser mediates everything: discovery, invocation, confirmation for sensitive actions.
View Chrome WebMCP documentation →
The appeal is obvious. Instead of agents guessing what a page does by parsing its DOM tree or taking screenshots, the page tells them directly. Google’s origin trial in Chrome 149 is now open to developers, and early adopters include Shopify storefronts, Expedia, Instacart, and Redfin. OpenAI has already added WebMCP support to ChatGPT’s desktop browser, calling them “site tools.”
But WebMCP carries a fundamental limitation that its proponents understate: it requires site owners to opt in. A site must actively register its tools before any agent can call them. That is a feature for security — and a bug for coverage. The millions of sites that will never ship a WebMCP manifest still exist, still contain useful data, and still need to be automated.
2. ChatGPT Chrome: The Brute-Force DOM Path
While Google polishes a standard, OpenAI shipped the pragmatic alternative. The October 15 update to the ChatGPT Chrome extension turned it into a genuine browser agent — one that operates inside your authenticated sessions, across your open tabs, using the same DOM-parsing and click-simulation techniques that computer-use agents have used for months.
Work mode can fill forms, send messages, download files, compare content across tabs, and group tabs for organization. The Chrome Web Store listing shows 7 million users. The agent works inside logged-in sessions on Gmail, Salesforce, and every other SaaS product — no special integration required from the site owner.
This is the scrape-the-DOM philosophy taken to its logical conclusion: the agent does not ask permission from the site. It asks permission from the user.
The trade-off is real. DOM scraping is fragile — a website redesign breaks the agent. It is token-heavy — parsing a full page’s accessibility tree can burn thousands of tokens before the agent even decides what to do. And it raises genuine security questions that multiple analysts have flagged: agents operating in authenticated browser sessions can be tricked by deceptive page content that was designed for humans, not for machine consumption.
OpenAI’s bet is clear: agents should be able to interact with any website, not just the ones that opted into a protocol. That is a power move wrapped in a convenience feature.
3. CLI-Anything: The Browser-Bypass Path
The third contender sidesteps the browser debate entirely. CLI-Anything from Hong Kong University’s Data Science lab takes a position so radical it loops back to simplicity: if the browser is the bottleneck, skip the browser.
The project uses a fully automated 7-phase pipeline to wrap desktop applications — Blender, GIMP, LibreOffice, Audacity, QGIS, OBS Studio, and dozens more — in structured command-line interfaces. These CLIs drive the real application backends, not toy reimplementations. Each one ships with --json output for structured data, a REPL for stateful sessions, undo/redo support, and a SKILL.md that agents auto-discover.
At 55,400 stars and +607 per day on GitHub Trending, it is one of the fastest-growing agent tools of 2026. The CLI-Hub registry already supports installation from pip, npm, and brew, with full integrations for Claude Code, Cursor, Codex, and GitHub Copilot CLI.
The philosophy is pragmatic to the point of being contrarian: most real-world software is not a web app. Blender does not have a WebMCP manifest. Photoshop does not expose tools to browser agents. But both have internal APIs that a well-structured CLI can surface. CLI-Anything’s tagline captures it: “Today’s software serves humans. Tomorrow’s users will be agents.”
The Real Question: Who Owns the Interface Layer?
These three approaches are not just engineering choices. They are bids for control of the agent-web interface layer — and each one shifts power differently.
| Approach | Who Controls Access | Who Benefits Most | What Breaks |
|---|---|---|---|
| WebMCP | Site owners (opt-in) | SaaS platforms, e-commerce | Coverage — unadopted sites are invisible to agents |
| ChatGPT Chrome | Agent platform (OpenAI) | OpenAI, end users | Site owners lose control — agents act without site consent |
| CLI-Anything | Open-source community | Developers, agent builders | Web-based workflows — CLIs cannot handle browser sessions |
WebMCP gives site owners a structured voice. ChatGPT Chrome gives agent platforms unilateral access. CLI-Anything gives the open-source community a parallel path that makes the browser debate irrelevant for desktop software.
The historical pattern here is instructive. The web went through this exact cycle with APIs:
- Phase 1: Screen scraping (brittle, unauthorized)
- Phase 2: Structured APIs (RESTful, OAuth-gated)
- Phase 3: Both coexist indefinitely — APIs for partners, scraping for everyone else
We are in Phase 1 of the agentic web. WebMCP is the Phase 2 bid. But if history holds, Phase 3 is the equilibrium: structured protocols for partners, brute-force scraping for everything else, and CLI wrappers for the software the browser cannot reach.
Security: Three Threat Models
Each approach carries distinct security implications that practitioners need to understand.
WebMCP’s threat model centers on malicious tool definitions. A compromised site could register a tool called “Add to Cart” that actually initiates a wire transfer. The spec addresses this with confirmation prompts for sensitive actions and same-origin policy enforcement, but security practitioners have raised unresolved questions about trust models, rate limiting, and credential management for agent sessions.
ChatGPT Chrome’s threat model is the inverse: the agent acts inside authenticated sessions the user already controls. OpenAI’s safety documentation requires per-site permission grants and user review before submissions, but the agent can still read everything on every open tab. Commentary correctly advises keeping banking and sensitive tabs closed before activating Work mode.
CLI-Anything’s threat model is supply-chain risk. A compromised CLI harness that wraps Blender or LibreOffice could execute arbitrary commands with the user’s permissions. The project mitigates this with a 7-phase pipeline that includes automated test generation (2,461 tests, 100% pass rate), but the trust boundary is the pip/npm package registry — the same surface that has been exploited repeatedly in other ecosystems.
What the Community Is Saying
The developer community is split — and productively so.
When Google first announced the WebMCP early preview in February 2026, the Hacker News thread drew 360 points and 216 comments — with reactions ranging from “this is the USB-C moment for AI agents” to deep skepticism about adoption.
Even before the Chrome implementation, the WebMCP Proposal thread gathered 153 points and 81 comments, with practitioners debating whether the standard would fragment or unify the agent-web interface.
A May 2026 reality check from Studio Meyer observed that “none of the mainstream AI agents call navigator.modelContext tools directly on websites — they still rely on DOM scraping or computer use.” Five months later, that assessment has shifted: OpenAI’s ChatGPT browser now supports WebMCP site tools, and Chrome 149’s origin trial is live. But adoption on the site-owner side remains thin.
Apify’s analysis — written from the perspective of the leading web scraping platform — argues that WebMCP “fundamentally alters the economics of web data extraction” but concedes that a clean WebMCP tool “does nothing for the millions of sites that will never ship one.” That tension — between the elegance of structured protocols and the reality of an unstructured web — is the central fault line.
The AI Engineer conference talk by Apify CEO Jan Curn, titled “Why AI Agents Still Won’t Pay for Anything,” went further: the economic model for agent-web interaction is broken regardless of the protocol layer. Agents consume server resources without generating ad revenue or converting to purchases in trackable ways. WebMCP does not solve that problem — it just makes the consumption more efficient.
Meanwhile, CLI-Anything’s growth on GitHub Trending — tracked at 55,071 stars on October 19 with 607 new stars that day — suggests a significant developer constituency has decided the browser debate is someone else’s problem. They want agent access to Blender, GIMP, and QGIS, and they want it now.
What This Means for Builders
If you are building agent-facing products in 2026, here is the practical stack:
1. Instrument WebMCP today. It is cheap insurance. Add the origin trial flag, register your core workflows as tools with JSON Schema definitions, and you are ahead of 99% of sites. Even if WebMCP does not become the dominant standard, any structured tool declaration is better than forcing agents to scrape your DOM.
2. Do not rip out DOM-scraping fallbacks. Your agent harness should try WebMCP first and fall back to accessibility-tree parsing. Most of the web will not have WebMCP tools for years. The hybrid approach is not a compromise — it is the correct architecture for 2026.
3. Consider CLI wrappers for desktop integration. If your product includes desktop software components, a CLI-Anything harness gives agents structured access without building a custom MCP server from scratch. The CLI-Hub registry means agents can discover and install your tools automatically.
4. Watch the permission model. WebMCP’s opt-in model and ChatGPT Chrome’s user-consent model represent fundamentally different answers to “who decides what agents can do.” The resolution will shape agent commerce, attribution, and liability for the next decade.
The deeper pattern is that the agent-web interface is following the same fragmentation path that mobile took in 2008: multiple incompatible approaches racing toward a de facto standard, with the eventual winner determined more by distribution than by technical elegance.
WebMCP has the standards-body backing and browser-native integration. ChatGPT Chrome has 7 million users and the OpenAI distribution machine. CLI-Anything has the open-source community and the advantage of not needing the browser at all.
The HTTP-vs-Gopher question was settled by adoption, not by committee vote. This one will be too. The builders who instrument all three paths today — structured protocol, DOM fallback, CLI wrapper — will be the ones still standing when the dust settles.
Related reading:
- Your SaaS Now Has a Second Customer: The AI Agent — our earlier deep-dive on what WebMCP means for SaaS design
- Best AI Agents for Browser Automation in 2026 — comprehensive comparison of browser automation approaches
- GitHub Trending Is Now a Skills Marketplace — CLI-Anything in the broader context of the agent skills explosion