MCP, MCP Apps, and WebMCP: Three Names, Three Different Jobs

If you follow AI tooling news, you have probably seen three names that sound like one thing: MCP, MCP Apps, and WebMCP. They share letters, they share some authors, and they all help AI agents get real work done. They are not the same technology, they run in different places, and they are at very different stages of maturity.

The short version: MCP is how an AI assistant reaches tools and data that live on a server. MCP Apps is an add-on to MCP that lets those tools show an interactive screen inside the chat instead of plain text. WebMCP is a separate, proposed browser feature that lets an ordinary web page offer tools to an AI agent while you have that page open.

Learning focus

By the end of this post you should be able to explain each of the three in a sentence, say where each one runs, describe the main security concern for each, and pick the right one for a given problem.

MCP: the plug between AI assistants and the outside world

The Model Context Protocol (MCP) is an open standard Anthropic introduced in November 2024. Before MCP, every AI app needed a custom integration for every service it wanted to talk to. MCP replaced that with one shared format: a service wraps its abilities in an MCP server, and any AI app that speaks MCP (the host, such as Claude, ChatGPT, Cursor, or VS Code) can use it.

A server offers three kinds of things. Tools are actions the model can call, like "search tickets" or "create invoice." Resources are data it can read. Prompts are reusable templates. Under the hood, messages use JSON-RPC 2.0 (a simple request-and-response format) over one of two transports: stdio for a server running on your own computer, or Streamable HTTP for a remote one.

On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation, a new fund under the Linux Foundation co-founded with Block and OpenAI. At that point there were more than 10,000 public MCP servers. The current spec revision, 2026-07-28, made the protocol stateless (each request now stands on its own, which makes servers easier to scale), deprecated the Roots, Sampling, and Logging features with a minimum 12-month window, and formalized an extensions field that clients and servers use to announce optional add-ons. That last change matters for the next section.

An example. You connect your company's ticketing MCP server to Claude. You ask, "What did customers complain about most this week?" Claude calls the server's search_tickets tool, gets back a list of tickets as text, and summarizes it for you. Nobody needs a browser tab open; the server does the work.

The main risk lives on the server side. The OWASP MCP Security Cheat Sheet warns about tool poisoning (hidden instructions in a tool's description or output that steer the model) and rug pulls (a server quietly changing its tools after you approved them). Its advice: never auto-approve tool calls, and require explicit confirmation for anything destructive, financial, or data-sharing.

MCP Apps: when a tool needs a screen, not a paragraph

Plain MCP tools return text, images, or structured data, and the host decides how to display it. That works for "summarize my tickets." It works badly for "help me pick a seat on this flight" or "adjust this chart's date range," where you really want buttons and sliders.

MCP Apps fills that gap. It started as a proposal, SEP-1865, published on November 21, 2025, and it merged two earlier efforts: the community MCP-UI project (created by Ido Salomon and Liad Yosef) and OpenAI's Apps SDK, with Anthropic and OpenAI contributors on the author list. It became the first official MCP extension, with a stable spec dated January 26, 2026, and it is listed as Stable in the extensions framework that the 2026-07-28 spec formalized.

Here is how it works. The server declares a UI ahead of time as an HTML resource with a ui:// address. A tool points at that UI through a metadata field (_meta.ui.resourceUri). When the tool runs, a host that supports MCP Apps loads that HTML into a sandboxed iframe (a walled-off mini web page) inside the chat, and the iframe talks to the host using MCP's same JSON-RPC messages, carried over the browser's postMessage channel. Because it is an extension, it is opt-in: client and server must both announce support for io.modelcontextprotocol/ui. A host that does not support it simply shows the normal text result.

An example. A travel company's MCP server has a choose_seat tool. In a host that supports MCP Apps, you see a clickable seat map right in the conversation. You tap 14C, the map asks the host to call the booking tool, and the host checks that request before passing it to the server. In a host without support, you get a text list of available seats instead.

The security model leans on that sandbox. App content cannot touch the host page, its cookies, or its storage. The host builds a content security policy from the domains the server declares and refuses everything else, and camera or microphone access must be requested explicitly. Critically, the app never calls tools directly: every click that should trigger a tool becomes a request the host can validate, log, and, if it chooses, ask you to approve.

Support at launch included Claude (web and desktop), ChatGPT, Goose, and VS Code Insiders, and it is the most widely implemented of MCP's official extensions. The ext-apps repository holds the spec and SDK.

WebMCP: the website itself offers tools to your browser's agent

WebMCP solves a different problem. Today, when an AI agent operates a website on your behalf, it mostly guesses: it reads the page, finds buttons, and clicks them like a very fast, very literal person. That is fragile, and it is one reason we keep covering agentic browsers and their failures.

WebMCP lets the site skip the guessing. A web page registers tools in its own JavaScript, describing what each one does and what inputs it takes, and an AI agent working in your browser can call them directly. The current draft spec exposes this on document.modelContext, with a registerTool() method. (Chrome's May 2026 announcement and many tutorials show navigator.modelContext, an older spelling, so expect code samples to drift as the draft changes.) There is also a declarative form that annotates existing HTML forms, which is still being worked out.

Despite the name, WebMCP is not an extension of MCP and not a replacement for it. Chrome's own comparison guide is explicit about this. The spec describes a WebMCP page as conceptually similar to an MCP server, but the tools run in the page's own script, in your tab, and they exist only while that page is open. There is no separate server and no separate login: the tool runs inside the session you already have, with your cookies and your account.

An example. You are on a grocery site, signed in, and you ask your browser's built-in agent to "reorder last week's list but swap the oat milk for almond." The site has registered get_past_orders and add_to_cart tools, so the agent calls them with clear inputs instead of hunting for the right buttons. Close the tab, and those tools disappear.

Where it stands is the part most coverage gets wrong. The proposal dates to August 2025, authored by engineers at Microsoft and Google, and it lives with the W3C Web Machine Learning Community Group. As of mid-November 2026 it is a Draft Community Group Report: not a W3C Standard and not on the Standards Track. Chrome runs an origin trial (a time-limited opt-in test for sites) from Chrome 149 through 156, with a local testing flag at chrome://flags/#enable-webmcp-testing, and its blink-dev intent estimated shipping around Chrome 157. Edge reportedly runs its own origin trial. As of Chrome's May 2026 intent, Mozilla and Apple had not stated a position, so treat it as a Chromium experiment for now.

The security model borrows web platform controls. The API only works on secure (HTTPS) pages, and a permissions policy named tools defaults to the page's own origin, so other sites and cross-origin iframes cannot see or call its tools unless the site opts in. Tools can carry hints such as readOnlyHint (changes nothing), consequentialHint (the agent or browser should ask you before running it), and untrustedContentHint (treat what comes back with suspicion). Chrome's security guidance is blunt that WebMCP tools are still exposed to indirect prompt injection and that sites must add their own defenses. Even a read-only tool can leak things about you, because it runs as you.

Side by side

	MCP	MCP Apps	WebMCP
What it is	Open protocol connecting AI hosts to tools and data	Optional MCP extension that adds interactive UIs to tool results	Proposed browser API letting a web page expose tools to an in-browser agent
Where the tool runs	On an MCP server (local process or remote)	Server runs the tool; UI runs in a sandboxed iframe in the host	In the web page's JavaScript, in your tab
How it talks	JSON-RPC 2.0 over stdio or Streamable HTTP	JSON-RPC over postMessage between iframe and host	Left to the browser; agent calls document.modelContext tools
Whose credentials	The server's own (OAuth for remote servers)	Same as the MCP server behind it	Your existing logged-in browser session
Lifetime	Available whenever the server is up	Whenever its tool runs in a supporting host	Only while the page is open
Status, Nov 2026	Spec 2026-07-28, stewarded by AAIF under the Linux Foundation	Official extension since Jan 26, 2026	W3C Community Group draft; Chrome origin trial
Main risk	Tool poisoning and rug pulls on the server side	Untrusted UI code, contained by the sandbox and host checks	Prompt injection from page content; acting as the signed-in user

Which one do you need?

If you are building, the choice usually falls out of where your capability already lives.

• Reach for MCP when the work happens on a backend, needs to run with no browser open, or should be available to desktop apps and coding tools like Claude Code or VS Code. Our Build and Secure an MCP Server tutorial walks through it.
• Add MCP Apps when your MCP tool's answer is something a person should interact with, such as a picker, a form, a map, or a chart. Keep the plain-text result good, because hosts without support fall back to it.
• Try WebMCP when your product is a website, the useful actions already live in the page, and you want browser agents to use them reliably inside the user's session. Treat it as an experiment until more than one browser engine ships it.

Many teams will end up with more than one. A store might run an MCP server for order lookups from any AI app, use MCP Apps to show a product carousel in ChatGPT or Claude, and register WebMCP tools on its own checkout page.

If you are using these tools rather than building them, the habits are the same across all three: connect only servers and sites you trust, read what a tool will do before approving it, and be most careful with anything that spends money, sends messages, or shares data.

Key takeaways

• MCP is the established open protocol, now housed at the Linux Foundation, that connects AI assistants to tools and data on servers; its latest revision is 2026-07-28.
• MCP Apps is an opt-in MCP extension, with a stable spec since January 26, 2026, that lets a tool show an interactive HTML interface in a sandboxed iframe inside the chat.
• WebMCP is a separate proposal, not part of MCP, in which a web page registers tools in JavaScript for a browser agent; it is a W3C Community Group draft with a Chrome origin trial, not a finished standard.
• Where the code runs is the clearest way to tell them apart: on a server, in a sandbox inside the AI app, or in your browser tab.
• Each has a different main risk: poisoned servers for MCP, untrusted UI for MCP Apps, and prompt injection while acting as you for WebMCP.

Next steps

Continue to: MCP Explained: Connectors for Users, Protocol for Builders for the full beginner track, or Connect Your First MCP Server to try one in about fifteen minutes. For the wider map of agent standards, see The AI Agent Landscape in 2026.

info

This content was developed with AI assistance and is regularly reviewed for accuracy. Spec status, browser support, and dates reflect the MCP specification, the WebMCP draft, and Chrome documentation available through November 2026. WebMCP in particular is changing quickly, so check the linked spec before building on it.