MCP 是一种协议，用于运行服务器，将你的工具暴露给任何位置的 AI 智能体。WebMCP 则是一项拟议中的 Web 标准，允许网页在用户打开该页面期间，声明智能体可以在页面上执行哪些操作。
如果你已经构建过 MCP 服务器，“WebMCP”这个名字很容易让人以为它只是把同一个协议搬进了浏览器。事实并非如此。两者的差异决定了面向智能体的代码放在哪里、以哪个身份运行，以及你现在能否依赖它。
本文将从运行时、身份、生命周期和发现机制四个方面对二者进行比较，然后将它们分别对应到不同的产品类型，并直截了当地说明 WebMCP 的当前状态。
核心要点
- MCP 工具运行在你自行部署和保障安全的服务器上，任何兼容的智能体都能访问。WebMCP 工具存在于网页中，仅在该页面于标签页中打开时才存在。
- WebMCP 工具在用户已打开的页面中运行，因此调用这些工具的智能体是在用户现有的会话、Cookie 和权限范围内工作的，它并不持有访问你站点的独立凭据。
- WebMCP 并不是 MCP 的替代品。Chrome 将其描述为一组受 MCP 启发的浏览器 API，舍弃了 resources 等服务端概念。
- WebMCP 仅在源隔离（origin-isolated）的文档中运行，并受
tools权限策略（Permissions Policy）控制，其默认值为self。 - WebMCP 自 Chrome 149 起进入 Chrome 源试用（origin trial）阶段，Chrome 表示该 API 仍可能发生变化。
一句话概括 WebMCP 与 MCP 的区别
MCP 是你运行的服务器，供智能体调用你的工具；WebMCP 则是你的页面声明智能体可以在其当前所在页面上做什么。Model Context Protocol（模型上下文协议）是一项将 AI 应用连接到外部数据、工具和工作流的开放标准，它并不关心智能体是否运行在浏览器中。Chrome 的指南何时使用 WebMCP 与 MCP将 WebMCP 称为一项由两个 API 组成的拟议浏览器标准。这些 API 只面向浏览器内置的智能体，由浏览器在该智能体与你的站点之间传递消息。关于自带智能体的浏览器的背景知识，请参阅我们的智能体浏览器简介。Chrome 称 WebMCP 是”受 MCP 启发的”——它是一个以 MCP 为蓝本的浏览器 API，而不是用 JavaScript 重写的 MCP。
在 MCP 和 WebMCP 中，由谁运行什么？
MCP 服务器是一个独立进程，有自己的部署、自己的身份验证和自己的可用性保障。WebMCP 不引入任何新进程：它直接在打开的标签页中运行。
使用 MCP 时，你需要运行一个服务，桌面端、移动端、云端或 Web 客户端上的智能体可以随时连接。这种覆盖范围是有代价的：你要托管服务器、管理版本、进行监控，还要决定如何对每个调用方进行身份验证。MCP 生态系统开发者指南介绍了客户端、服务器与协议之间是如何协同工作的。
使用 WebMCP 时，工具定义作为前端的一部分一并发布。无需额外部署，但工具与标签页绑定。每个 WebMCP 工具都会随着注册它的标签页一起消失。如果用户离开页面或关闭标签页，智能体就会失去对该工具的访问权限。
身份：智能体以已登录用户的身份行事
由于 WebMCP 工具在用户已打开的页面中执行，使用这些工具的智能体是在该用户现有的会话、Cookie 和权限范围内工作的，它不持有访问你站点的独立凭据。Chrome 指出，WebMCP 可以使用页面的实时会话数据、Cookie 和 DOM，而这些在打开的标签页之外都不存在。由此可知，工具发出的网络请求会携带页面当前已有的会话。
MCP 服务器面临的则是另一个问题。它是一个独立服务，必须自行判断调用者是谁、有权做什么。这通常意味着要为智能体或其所代表的用户签发并校验某种形式的凭据。WebMCP 跳过了这一步，因为它始终不离开用户的会话。你无需配置 API 密钥、设置服务账号，也不必为智能体单独构建授权层。
WebMCP 基于会话的身份机制也有代价。从页面的角度来看，一次 WebMCP 工具调用就是已登录用户执行的一次操作。除非你刻意设计了区分机制，否则代码无法分辨这是智能体调用还是用户点击。由此引出三项实践：
- 每个工具的权限范围，仅限于用户本来就能在 UI 中完成的操作。
- 对敏感操作要求确认。WebMCP 概览指出，执行敏感操作（例如购买）的工具可以在继续之前向用户显示确认对话框。
- 依靠平台层面的访问控制。WebMCP 仅在源隔离的文档中运行，并受
tools权限策略控制。该策略默认值为self，因此跨源 iframe 必须被显式授予访问权限。
<iframe src="https://widget.example.com/" allow="tools"></iframe>如果 iframe 没有该属性，默认的 self 策略将阻止在该跨源框架中注册工具。Chrome 文档还指出，在任何启用了 document.domain 的文档中（例如通过 Origin-Agent-Cluster: ?0 响应头），WebMCP API 都会被禁用。
WebMCP 与 MCP 对比一览
MCP 与 WebMCP 的核心分野在于：一边是持久性和覆盖范围，另一边是页面上下文和用户会话。
| 对比维度 | MCP | WebMCP |
|---|---|---|
| 用途 | 向任何运行环境中的智能体暴露数据和操作 | 让页面在用户访问期间可供智能体操作 |
| 生命周期 | 长期运行的服务器进程 | 仅在标签页打开期间存在 |
| 连接性 | 任意客户端：桌面端、移动端、云端、Web | 仅限浏览器智能体 |
| UI 交互 | 无界面（headless），独立于任何 UI | 在页面内运行，可访问 DOM |
| 发现机制 | 每个智能体宿主都有各自注册服务器的方式 | 页面在用户访问期间注册工具 |
| 身份 | 取决于服务器实现的身份验证方式 | 用户的实时浏览器会话 |
| 可用性 | 已发布的协议，提供多种语言的 SDK | 自 Chrome 149 起进入 Chrome 源试用 |
前五行内容基于 Chrome 对 WebMCP 与 MCP 的比较。
何时应使用 MCP，何时应使用 WebMCP？
对于在无 UI 的服务器上完成的工作，使用 MCP；对于在有用户在场的页面上完成的工作，使用 WebMCP。
- 后端服务、后台任务或无 UI 的数据访问：选择 MCP。 WebMCP 需要一个打开的页面，而且 Chrome 的概览指出，它主要为在本地浏览器中工作的用户而设计，而非用于无界面运行。可以从如何构建 MCP 服务器入手。
- 有已登录用户的 Web 应用：选择 WebMCP。 将其用于当前页面上的操作，例如填写复杂表单或在预订组件中选择日期——这类场景中，用户会话和页面状态至关重要。
- 两者兼用。 许多产品会同时需要两者：MCP 承载核心业务逻辑和数据，WebMCP 负责标签页内的操作。如果你已有 HTTP API，通过 MCP 将该 API 暴露给 LLM自然就是服务端的那一半。浏览器端部分请参阅我们的配套文章：借助 WebMCP 将站点操作暴露给 AI 智能体。
WebMCP 会取代 MCP 吗？
不会。Chrome 明确表示，WebMCP 既不是 MCP 的扩展，也不会取代 MCP。它专为浏览器打造，舍弃了 resources 等服务端概念。它还依赖于页面：只有访问站点才能发现其工具，标签页关闭后工具也随之消失。许多智能体任务根本不涉及网页，例如定时任务、IDE 助手、数据管道以及运行在云端的智能体。这些任务仍然需要 MCP 服务器。
WebMCP 的成熟度如何？
WebMCP 仍处于实验阶段。它可以通过自 Chrome 149 起的 Chrome 源试用使用，也可以在本地通过 chrome://flags/#enable-webmcp-testing 标志启用。Chrome 提醒，该 API 仍在讨论中，可能会发生变化。源试用有固定的运行期限，可能附带使用量上限，其目的是收集反馈以塑造最终的 API。WebMCP 规范是 W3C Web Machine Learning 社区组发布的草案报告，它既不是 W3C 标准，也不在 W3C 标准轨道上。Chrome 的文档只涵盖 Chrome 自身的实现，因此在其他浏览器或智能体宿主的官方文档确认之前，不要假定它们也提供支持。可以关注 Chrome Status 上的 WebMCP 条目，了解里程碑变化。Chrome 还指出，WebMCP 可以作为渐进式增强（progressive enhancement）来添加。请按这种方式构建，确保无论智能体能否看到这些工具，你的 UI 都能同样正常运行。
如何在两者之间做出选择
MCP 与 WebMCP 解决的是不同的问题。MCP 让你的能力能够随时被任何智能体访问；WebMCP 则让用户当前所在的页面能够被其浏览器中的智能体以用户自身的会话来使用。下一步，不妨列出你的产品对外暴露的所有操作并加以分类：无界面操作交给 MCP 服务器，与会话绑定的页面操作则作为 WebMCP 的候选项，在源试用机制下推进。由于 API 仍可能变化，请让 WebMCP 层保持精简。
常见问题
如何为真实访问者启用 WebMCP，而不仅仅是在我自己的浏览器中？
在 Chrome Origin Trials 控制台中注册你的源，并生成 WebMCP 令牌。在每个注册工具的页面上提供该令牌，可以放在 origin-trial meta 标签中，也可以放在 Origin-Trial HTTP 响应头中。令牌按源划分。如果没有令牌，使用标准版 Chrome 的访问者将永远看不到你的工具，因为本地测试标志只对启用它的那个浏览器生效。该试用自 Chrome 149 开始，最初计划持续到 Chrome 156。Google 已申请将其延长至 Chrome 162，因此请在 Origin Trials 控制台中确认你的令牌的截止日期。
不构建智能体的情况下，如何测试 WebMCP 工具？
使用 Model Context Tool Inspector，这是 Chrome WebMCP 文档中列出的一款 Chrome 扩展程序。它会列出页面已注册的工具，并允许你亲自运行它们。它还能确认浏览器是否可以解析你的 JSON Schema，并显示每个工具返回的结果或错误。你的页面仍需启用 WebMCP，可以通过 chrome://flags 中的 WebMCP 测试标志，也可以通过源试用令牌。
我能将 MCP 工具定义复用于 WebMCP 吗？
输入定义通常可以复用，但处理函数（handler）不行。MCP 工具和 WebMCP 工具都使用 JSON Schema 描述输入，因此工具的名称、描述和参数结构通常可以直接沿用。处理函数则不同：MCP 处理函数在你的服务器上运行，采用你所实现的身份验证方式；WebMCP 处理函数则是在页面中运行的 JavaScript，携带用户的会话和实时 DOM 状态。
Angular 支持 WebMCP 吗？
支持，但仅为实验性支持。借助 Angular 的实验性支持，你可以注册遵循 Angular 依赖注入生命周期的 WebMCP 工具，还能将 Signal Forms 转换为工具，而无需手动编写 JSON Schema。Angular 文档提醒，WebMCP 规范变化频繁，这些 API 甚至可能在非主版本更新中发生变化。请锁定你的 Angular 版本，并做好更新代码的准备。
