MCP-B: A Protocol for AI Browser Automation

Original Article ↗ Hacker News Discussion ↗

MCP‑B is a new protocol that lets websites expose their functionality as structured “tools” directly in the browser, so AI agents can interact with them through deterministic function calls instead of brittle DOM or visual automation. Commenters see potential in accessibility, admin workflows, and user-controlled automation across tabs, but raise strong concerns about security, cross-origin data leakage, auth models, and whether most site owners will ever opt in given business incentives around ads and engagement. Many compare it to REST, OpenAPI, and past standards like RSS, arguing that while the idea is technically elegant, its real impact will depend on adoption, guardrails, and whether users start preferring “AI-ready” sites.

What MCP-B Does

  • Extends Model Context Protocol into the browser: a site embeds an MCP server in its JS, exposing functions (“tools”) that an AI client can call.
  • A browser extension (the MCP-B client) discovers these tools and lets any compatible AI model use them, so sites don’t need to build their own AI UIs.
  • Emphasis is on deterministic function calls over browser events instead of DOM parsing or vision.

Comparison to Existing Browser Automation

  • Different from Selenium/Playwright: those automate the UI by driving the DOM; MCP-B lets the app author publish higher-level, semantic actions (e.g., “add to cart”) directly.
  • Compared to test attributes or OpenAPI/Swagger: those are static and require prior knowledge; MCP-B advertises available tools dynamically at connection time via a standard protocol.
  • Some argue a generic Swagger MCP client might cover similar ground but tool overload and naming clashes are cited as issues.

Use Cases and Potential

  • Suggested uses: simplifying complex SaaS/admin UIs, purchases or multi-step flows, cross-tab workflows (e.g., moving content from Google Docs to a CMS), accessibility/assistive automation.
  • “Bring your own model” is attractive to app developers who don’t want to own chat/agent infrastructure.

Adversarial / Arbitrary-Site Automation

  • Discussion of injecting MCP servers via user scripts or dev builds to turn any site into an MCP target, framed as “adversarial interoperability.”
  • Some think this will be the main long-term value, as many businesses won’t voluntarily expose revenue-critical flows.

Burden on Site Owners & Ecosystem

  • Concerns that expecting every site to build MCP endpoints is unrealistic; more value if tools can be autogenerated from existing apps/frameworks.
  • Predicts platform-level integrations (WordPress, Shopify, Rails/Next/Laravel plugins) and directories/discovery standards.

Security & Privacy Concerns

  • Heavy debate around auth and cross-origin risks: an agent tied to a browser session can access whatever the user can, and may leak data between sites via prompt injection.
  • Suggestions include treating agents as untrusted delegates with least-privilege access, consent prompts when new domains/tools are used, and mechanisms to avoid exposing raw sensitive data to the model.
  • Some see MCP-B as weakening the web’s same-origin expectations if not carefully constrained.

Debate on MCP vs “Smarter” LLMs

  • One camp argues we should focus on LLM self-discovery and autonomous tool creation; another says current models are too unreliable/expensive for that, so explicit protocols like MCP-B are a practical bridge.

Business Incentives & Adoption

  • Skepticism that many commercial sites will ship MCP-B, likening the trajectory to REST APIs or RSS: powerful for users but misaligned with ad/engagement models.
  • Counterpoint: if enough users value “AI-ready” experiences, market pressure could drive adoption despite bot-abuse and anti-scraping concerns.