Comparison · Two standards

WebMCP vs. MCP Apps: two paths to agent-enabled software

Two standards with confusable names, aimed at opposite surfaces. I ran them stacked on top of each other to find out where each one belongs.

2026-07-13By João Janini6 min readAgent-assisted

Last verified 2026-07-16. Hosts and protocols move fast, so details here may be stale. Check the primary sources before you build.

Halfway through a test run, WebMCP was operating ChatGPT itself. Tools I had authored locally were driving the live page: registering private MCP apps, refreshing connections, sending prompts, reading visible chat state. Inside that same page, MCP Apps sat in their sandboxed frames, talking to their own servers, unbothered. If the two standards were competing for the same job, one of them would have had to lose. Neither did.

WebMCP is the path for agent-enabled websites. The page registers tools with the browser agent, and those tools read or update the live page while the user has it open. MCP Apps are the path for interactive applications inside agent hosts: an MCP server delivers an interface into ChatGPT, Claude, or another compliant client. The host calls a tool, fetches its ui:// resource, and renders the app in a sandboxed frame inside the conversation.

Related ideas, different protocols

WebMCP is a proposed web standard inspired by MCP's structured tool model. It is neither an MCP extension nor a JavaScript port of the full protocol; Chrome's own comparison notes that it omits server-side concepts such as MCP resources. MCP Apps are the opposite case: an official extension to MCP that combines ordinary tools and resources with a UI protocol. A server declares that a tool is associated with a ui:// resource, and the host renders the HTML in a sandboxed iframe, communicating over JSON-RPC carried through postMessage.

WebMCP lives and dies with the tab

User opens website
  → page registers tools on document.modelContext
  → browser agent discovers tools for the current page state
  → agent calls one tool with structured arguments
  → page JavaScript or an annotated form performs the action
  → the visible website updates and returns a result

A tool can be registered imperatively in JavaScript or declaratively through annotations on an HTML form. Either way it runs under the page's normal security model, with access to the tab's application state, DOM, cookies, and authenticated session. The lifecycle is ephemeral. Tools appear and disappear as the application state changes, and when the tab closes, they are gone.

An MCP App outlives any tab

AI host connects to MCP server
  → host discovers server tools and resources
  → model calls a tool
  → host fetches the linked ui:// resource
  → host renders the HTML in a sandboxed iframe
  → app receives results and can call server tools through the host

The server is persistent and callable without the developer's website being open. The interface lives inside the conversation, next to the prompts and tool calls that produced it, which is exactly where approval screens, dashboards, media viewers, configuration forms, and multi-step workflows want to be.

Where the differences live

	WebMCP	MCP Apps
Primary interface	The website. It keeps navigation, layout, authentication, branding, and visible state.	The AI client. The app works within the host's iframe, permissions, dimensions, bridge, and content security policy.
Discovery	Only after the agent visits the page.	Through the client's connection to the server, before any website navigation.
State	Inherited from the live tab: selections, unsaved form values, session, current route.	Reconstructed deliberately from the server, tool results, and host messages.
Security boundary	The website's origin and browser permissions; cross-origin exposure restricted unless the page permits trusted origins.	A host-controlled sandbox with no access to the host page, cookies, or local storage.
Headless operation	No. Chrome's documentation requires a tab or webview, since tools execute in page context.	Yes. The server can run background or headless operations.

Choose by where the user already is

WebMCP fits when

The user is already on your website and wants an agent to operate what they see.
The workflow depends on live DOM state, current selections, or an authenticated browser session.
The human-facing site should stay visible while the agent fills, filters, navigates, or diagnoses.
The capability does not need to survive the tab closing.

An MCP App fits when

The capability should be reachable from ChatGPT, Claude, or another MCP client without opening your website.
The model needs a persistent server for data access, authentication, and business rules.
The user benefits from an interactive approval, dashboard, visualization, or form inside the conversation.
The same tool and UI should work across multiple compliant hosts.

Long support forms, catalog filtering, date pickers in a stubborn booking UI, checkout flows that must remain visible: the first column. The Gmail, Slack, and Sheets apps in this portfolio: the second. There, the server prepares a proposal and the MCP App renders a concrete review interface so a person can approve the consequential action. A product with a substantial website and reusable backend capabilities will often adopt both.

WebMCP Teach is temporary scaffolding

WebMCP Teach, the extension I built, does not convert a website into an MCP App and does not replace native WebMCP. It adds locally authored WebMCP tools to sites that have not adopted the proposed standard: a saved tool pack is scoped to a domain, registered when that domain is open, and executed against the live page through a declarative browser-step engine. When a site ships first-party tools, the pack should retire. Its job is proving workflows and covering the adoption gap.

The ChatGPT test from the opening is what it looks like when the layers compose. WebMCP controlled the host website and its browser session. The MCP Apps stayed separate server-backed applications rendered inside that website.

WebMCP Teach tool
  → operates ChatGPT's live web UI
  → opens or manages an MCP App
  → can target an accessible control inside the app frame

MCP App
  → communicates with its MCP server
  → renders its own UI inside ChatGPT
  → calls server tools through the host bridge

This is why "versus" is often the wrong preposition. WebMCP improves the agent's grip on the host website while an MCP App provides the task-specific interface and backend capability inside it.

The strongest architecture uses both

A product can keep its core domain operations behind an API and MCP server, render review and configuration experiences as MCP Apps, and expose WebMCP tools from its public website for live browser journeys. The three surfaces can share schemas, authorization rules, idempotency, and approval policies without sharing a runtime. The division of labor is clean: the server owns persistent capabilities and data, the MCP App owns the interactive experience inside the conversation, WebMCP owns high-fidelity interaction with the live page, and browser automation covers whatever has not exposed a structured tool yet.

Websites declare what can be done. Server-backed apps declare tools and interactive views. The agent picks the surface that fits where the user is standing. That is a floor plan, not a rivalry.