Jonathon's AI Wiki

WebMCP in Chrome — Making Business Websites Agent-Ready (Greg Isenberg with Vinnie)

7 min read

Source: raw/WebMCP_-_Let_AI_Agents_pay_you_money.md — Greg Isenberg’s Startup Ideas podcast with guest Vinnie (Greg also calls him “Vince”), youtube.com/watch?v=EoNH3Tn8wYE, YouTube. Auto-caption transcript fetched 2026-08-27; the publish date is not in the transcript.

Read this with the WebMCP directory article

WebMCP Directory (nekuda.ai) is the wiki’s main WebMCP article. It covers the navigator.modelContext API, the W3C draft, the webmcp.cool directory and the npx skills add nekuda-ai/webmcp Claude Code skill. This article covers only what the episode adds: how to switch WebMCP on in Chrome, tools that depend on login state, where WebMCP sits among the other ways an agent can reach an app, and two service businesses built on it.

Vinnie demos an espresso-gear store with WebMCP tools. Whatever agent the shopper brings (Claude Code, ChatGPT, Grok Bot) compares machines, checks which accessories fit and fills the cart by calling a short list of tools the site declares, without parsing the page. The main technical point is that the tools run inside the user’s logged-in browser session: there are no API keys to hand over, and the tool list changes when the user logs in or out. Greg then gives two cash-flow business ideas for non-engineers, aimed at local service businesses including dentists.

Key Takeaways

  • What it is, in the hosts’ words.
    • Greg: a site can “tell an agent, here’s how to search, here’s how to book, here’s how to buy,” so the agent doesn’t have to work out the page like a human.
    • Vinnie: “MCP but in the UI in the browser,” a “brand new experimental feature from Google and Microsoft.”
    • Greg’s shorthand, which Vinnie accepts: “websites with agent buttons.”
  • It is experimental. Vinnie: it “launched in February, joint effort from Microsoft and Google, but it’s still in early days.” The proposal came “two years ago” and the launch was “the beginning of this year.” You have to enable a Chrome flag to use it (see Try It).
  • Why it beats agents that parse the page.
    • Computer-use and browser agents work from “the entire DOM” or from screenshots, hunting for where to click.
    • With WebMCP the site gives the agent an “efficient concise list of things that it can do.”
    • In the demo, the agent put two machines side by side and highlighted which specs matched the request: portafilter fit, two flat whites a day, and a 32 cm counter.
  • Tools can depend on browser state. This is the main difference from MCP servers and APIs.
    • The demo store labels its tools “always available” or “logged in.” Logging out left “only three tools.”
    • WebMCP uses the browser session, so “you just log in.” There are no API keys, tokens or MCP-server authentication steps.
    • Vinnie calls it “the least technical” way to make a site agent-native, “but with the most flexibility and the most features.”
  • The user brings the agent and pays for its tokens.
    • An in-app agent is a sidebar agent that the vendor builds, configures and pays tokens for. WebMCP lets the user’s own agent, with its own context and memory, work across many sites.
    • Vinnie still sees a place for in-app agents where the vendor wants a tightly gated scope; his example is the Cloudflare dashboard.
    • Dan Shipper makes the same bring-your-own-tokens argument in The AI Paradox.
  • Greg’s framing of the shift. SEO asked whether Google can understand the page. AEO asks whether AI can cite the answer. “Now we’re entering this WebMCP era which is basically can the agent finish the job?”
  • Where Vinnie would ship it first.
    • Compatibility-driven commerce: camera systems, parts, “any kind of web store that’s complicated.”
    • SaaS admin panels, consoles, analytics and marketing tools.
    • Regulated self-service, such as insurance or banking, using read-only tools or tools that touch only non-sensitive settings.
    • Internal company tools.

The Agent-Access Spectrum

Vinnie walked through this slide, which he tied to a tweet by “Dylan from Cloudflare”: “I don’t want to use your product’s agent. I want my agents to be efficiently enabled to use your product.”

ApproachHow the agent reaches the appVinnie’s caveat
Raw API (headless)Calls the API; never sees the appThe agent must hold an API key and handle authentication
MCP server (headless)A server added on top of the app’s back endAnother layer to build; the agent can’t manipulate the UI
Computer useScreenshots and clicks on a local or cloud computer”Slow and fragile at the moment”
Browser MCPReads the site’s HTML to find what to click”A little bit more fragile”
WebMCPCalls tools the site declares, inside the user’s browser sessionExperimental; needs a Chrome flag
In-app agentThe vendor’s own agent inside the productThe vendor configures it and pays for tokens; users can’t bring their own agent

Two Business Ideas (Greg, with Vinnie’s comments)

  1. A WebMCP (or “agent conversion”) agency.
    • The pitch: make “boring business websites agent ready.” Greg names “law firms and home service and HVAC, you know, med spas, dentists.”
    • Start with V1 tools such as requesting a quote or booking a consult.
    • Greg’s suggested pricing: “10,000 setup,” then “700” for monitoring and evals, depending on the client’s size.
    • Vinnie’s additions: sell a package (WebMCP plus an MCP server and other agent-native approaches) as first-mover positioning, and include internal office tools, not only customer-facing ones.
    • Greg: “maybe it’s just agent conversion agency and then WebMCP is just one of the technologies.”
  2. An agent mystery shopper.
    • Agents run a client’s most important user journeys: buying a hoodie on a Shopify store, booking a consult, filing a claim, requesting a quote.
    • The client gets a report on where the agent got stuck, bad tool descriptions, missing tools and conversion risk — “like a credit report.”
    • Sold monthly or weekly at “a few hundred a month or $100 a month.” Repeated fixes get turned into software. Vinnie suggests bundling it with the agency offer.

Both price ranges are Greg’s suggestions, not market data.

Try It

  1. Watch login-conditional tools work.
    • Enable “WebMCP support” in Chrome flags (chrome://flags), and allow remote debugging at chrome://inspect.
    • Point an agent at the demo store, which Vinnie says exposes 16 tools. The captions render its name and address as “crema andco” at “clientfly.dev”; both are unverified.
    • Log out mid-session and watch the tool list shrink. The demo’s GitHub repo can be cloned from a button on the site.
  2. Draft the tool list for one local-business site before building anything. For a dental practice, the likely candidates are: check accepted insurance, book a new-patient consult, and get hours and directions. ^[inferred] (The episode names dentists as a target market but not these tools.)
  3. Do the mystery-shopper pass by hand first. Give an agent a patient’s task on a practice site, such as “book a new-patient cleaning for next Tuesday.” Log where it stalls and why. That log is Greg’s idea 2 without the software.
  4. Check your changes with the Lighthouse agentic-browsing audit from the AI SEO Pre-Publish Checklist, which already treats Web MCP as a site-owner step.

Open Questions

  • Browser support. The episode mentions only a Chrome flag. It says Microsoft co-developed WebMCP but not whether Edge or any other browser ships it.
  • Same surface as the W3C draft? The episode never names the API. Whether Vinnie’s Chrome implementation is the navigator.modelContext surface described in WebMCP Directory is plausible but unconfirmed.
  • Who launched it. Greg calls it Google’s; Vinnie says it is a joint Google and Microsoft effort.
  • The demo URL and store name come from auto-captions.
  • No evidence of demand yet. There are no adoption numbers, and nothing shows that law, dental or home-service businesses will pay for agent-readiness now.

Graph View

Backlinks