WebMCP Runs In The Browser, Not On Your Server

Google I/O 2026 introduced WebMCP, which social media quickly dubbed 'the new MCP standard' — but it actually solves a different problem entirely. WebMCP is a browser-scoped tool protocol: tools live inside a Chrome tab, authentication relies on the user's active session, and the runtime only exists while the tab stays open. It fits scenarios where a human is present, like form-filling, dashboard interactions, or in-app copilots.

Server-side MCP servers (stdio/HTTP), by contrast, are triggered by cron jobs, webhooks, or queues, and authenticate via API keys rather than user sessions. The author runs three such MCP servers — for Gmail triage, Telegram messaging, and invoicing — as headless systemd services that together handle over 400 tool calls a day with no browser or user session involved. These workloads are impossible to replicate with WebMCP, since it fundamentally requires a human watching a screen.

The practical decision rule is simple: if an agent is triggered by a human click, WebMCP applies; if it's triggered by time, a queue, or a webhook, you need a real server-side MCP. Workloads requiring API keys or multi-tenant support demand server-side infrastructure, while tasks needing the user's logged-in session belong to WebMCP. For engineers, getting this distinction right avoids costly architectural mistakes.