点击上方 程序员成长指北，关注公众号
回复1，加入高级Node交流群

前言

WebMCP 是一种全新的 Web 标准，旨在让网站直接为 AI 代理提供可调用工具，从而提升交互效率和安全性。它不取代网页，而是让代理访问网站更可靠、更结构化，为开发者提供渐进式增强方式，让现有网站功能轻松被代理发现和调用，开启网页与智能代理协作的新可能。

今日前端早读课文章由 @Nabors 分享，@飘飘编译。

译文从这开始～～

想象一下，你的网站可以直接告诉访客的 ChatGPT Agent：“这是我能做的事情，这里是如何让我执行它的方法。”

直到 2026 年 2 月 10 日之前，AI 代理与网站交互只有两种方式：

1、视觉层面

代理通过截图评估内容，读取文本，并推断光标在屏幕上应该移动到哪里。

2、语义层面

代理解析大量底层 XML（DOM、无障碍树），提取数据并调用元素上的事件。

这些操作可以在浏览器层面执行，也可以由代理控制整个计算机系统来系统化完成。无论哪种方式，都需要额外的往返请求、推理和多模态模型，影响性能、成本和可靠性，同时消耗大量令牌和时间，而代理往往还在自己 “摸索”。

WebMCP 提供了第三种更高效、更可靠的选择。网站可以将结构化工具以 JavaScript 函数的形式公开，并附带描述和模式，让代理直接调用。目前它正由 W3C Web 机器学习社区组孵化，并已在 Chrome 上发布。

如果你是网页开发者，WebMCP 值得关注，它可能会改变 “构建网站” 的定义。

亚马逊的起源故事

Alex Nahas 在 2025 年初 MCP 出现时，是亚马逊的后端工程师。亚马逊内部有成千上万的服务，他们搭建了一个庞大的 MCP 服务器，相当于把所有工具都塞进了同一个上下文窗口。

Alex 解释道：“你必须在连接字符串里用进程命令去禁用它们。”—— 可以说，这是一个相当混乱的局面。

真正的问题在于 授权。MCP 规范采用了 OAuth 2.1，而亚马逊内部几乎没人实现它。每个内部服务都有自己的认证方式，且互不兼容 OAuth 2.1。

在亚马逊，所有授权都是通过统一浏览器体验管理的，用户登录后可访问所有服务、仪表板和资源。Alex 想到了一个办法：在浏览器中运行 MCP，利用浏览器的单点登录 (SSO)、会话 Cookie 和现有身份提供者。

这就是 MCP-B（“B” 代表 Browser 浏览器）。Alex 将 MCP TypeScript SDK 集成到客户端 JavaScript 应用中，并使用 postMessage 构建自定义通信传输，与 Chrome 扩展通信。而且效果非常好，以至于不能仅限于亚马逊内部使用。

从边缘项目到 W3C 标准

谷歌 Chrome 和微软 Edge 的团队也在研究类似想法。Chrome 在试验 “脚本工具”，Edge 也在探索同样的问题：如何让代理以结构化方式与 Web 应用交互？

当 MCP-B 出现后，他们通过 W3C 与 Alex 合作，并将其命名为 WebMCP。

不过名字可能会引起误解：WebMCP 不是 MCP。它不遵循 JSON-RPC 规范。Alex 曾推动将完整 MCP 协议移植到浏览器，但工作组不希望过于绑定原始规范。WebMCP 继承了 MCP 的 API 表面和概念模型，是代理可调用的带模式的工具。

它专为浏览器设计，完全在客户端运行，不存在 Anthropic MCP 的客户端 - 服务器模式。在 WebMCP 中，网页就是 “服务器”，当代理访问时启动。React 组件中用于提交表单或查询数据库的函数，现在可以直接提供给代理，省去了模拟点击事件和文本输入的麻烦。

如果你现在在想 “Java 和 JavaScript”，你不是一个人。命名确实可能造成混淆，因为 WebMCP 暂无计划实现提示或资源功能，仅实现 MCP 标准的 “工具” 部分。幸运的是，Alex 提供了一个 polyfill，可以在浏览器中运行 WebMCP API，并转换为 JSON-RPC，让你得到规范兼容的 MCP SDK。

致命三联问题

当前，访问网页的代理面临一个未解决的安全问题：致命三联。

设想：你打开两个标签页。标签页 A 是银行，标签页 B 是恶意网站。浏览器代理位于两者之间，获取了两个标签页的上下文，并将它们视为平等。

恶意标签页可能指示 Agent 从银行标签页提取路由号，或者向银行标签页发送指令转账资金。这不是理论问题，而是浏览器代理现有架构下的必然结果。Alex 说：“如果你要用 Comet 或 Atlas，你就必须接受这是一个你愿意承担的风险。”

WebMCP 并不能完全消除这个问题，但可以显著降低攻击面。代理不再操作截图和原始 DOM，而是通过 明确的工具调用 执行操作。也就是网站特意公开的操作。你可以对工具进行哈希处理，设置首次连接的引导流程，并将信任范围限定在特定域名及 TTL（生存时间）。

它是否万无一失？不，动态第三方工具仍可能存在提示注入问题。但从 “模型能看到并执行用户能做的任何操作，包括读取 DOM” 到 “模型只能调用这些特定函数”，这是显著的范围缩小，可能会改变未来浏览器的设计。

三种 WebMCP 工具模式

Alex 构建了多个支持 WebMCP 的网站，他发现 WebMCP 工具通常分为三类：

1、只读工具

应作为平面列表公开，始终可在代理上下文中访问。这是 GET 操作：获取数据、读取状态。你不希望代理为了读取信息而遍历整个 UI。公开所有内容，让代理查询所需数据。

2、导航工具

是网站的系统提示，告诉代理网站的功能及信息所在位置。“这些是链接，你访问时会发现更多工具。” 这是蓝图。标记为破坏性操作时，它会产生可见更改 —— 页面实际导航，尊重破坏性提示的代理会提醒用户。

3、写入工具

执行动作，如填写表单、提交数据、修改内容。这里 MCP 的引导功能非常关键：代理可以填写表单，然后向用户展示 ——“我即将提交这些内容，是否确认？” 人类仍在决策环中。

Alex 认为，通过这三种基础工具，即便是老旧的 WordPress 网站也能 “基本上变成 AI 公司”。所有功能都可以用原生 JavaScript 实现，无需额外框架。

为什么网络不会消失

Alex 并不认为 MCP 和智能代理会取代网络。

考虑使用场景：许多应用不仅仅提供文本，像 Figma 这样的画布应用，或 Quickbooks、Shopify 这样的复杂仪表板，需要可视化界面，人类是主要操作方，代理只起辅助作用。而其他一些应用只做数据查询和简单事务，这类场景更适合把应用 “带到代理身边”。WebMCP 服务的正是第一类场景：代理访问网站，而不是网站去找代理。

无论未来人们如何浏览网页，HTML、CSS 和 JavaScript 仍然是构建兼容性应用的核心基础，每个平台都可以渲染它们。交互模式可能从浏览器转向代理，但底层技术不会消失。

WebMCP 是对网络的渐进式增强，使网站既能服务人类，也能服务代理。网站会一直存在，而代理需要更好的方式与它们交互。制定一个 Web 标准，是实现这一目标的正确途径。

我们还处于早期阶段

WebMCP 仍处于早期阶段。规范正从社区孵化阶段过渡到正式草案。Chrome 在 Chromium 中已提供实验性实现（需开启标志）。Alex 预计官方浏览器支持将在 2026 年中后期发布。

如果你现在想尝试：

1、Polyfill：安装 @mcp-b/global 并通过 navigator.modelContext.registerTool() 注册工具。它兼容任何前端工具调用框架 ——CopilotKit、AGUI、SystintUI。

2、Chrome DevTools 分支：Alex 维护了 Chrome DevTools 的 MCP 服务器分支，可调用 WebMCP 工具，这意味着 Claude Code 可以自行编写和测试 WebMCP 工具。

3、标准：关注 WebMCP 官方 GitHub。主席 Anssi Kostiainen 对新手非常欢迎。加入社区小组参与其中。

4、文档：docs.mcp-b.ai 提供 polyfill 和参考实现的完整文档。

这对你意味着什么

如果你开发 Web 应用，WebMCP 值得关注，因为它允许你定义代理如何与网站交互，而不是让代理自己去猜测。它是一种主动、渐进式的增强，就像给网站添加无障碍功能一样。

你无需重构现有架构。核心在于，你只是把已有的客户端逻辑包装一下。你的 add-to-cart() 函数、搜索、表单提交已经可用，WebMCP 只是让它们可被代理发现和调用。

无论它最终是否成为标准，方向已经很明确：想吸引使用 Claude 或 ChatGPT 等代理的用户的网站所有者，会希望提供面向代理的层，以提供最佳体验。

WebMCP 是目前最严肃的尝试，旨在让代理支持成为平台原生能力，而不是事后补充。

如何实现 WebMCP

实现 WebMCP 有两种 API：声明式（Declarative） 和 命令式（Imperative）。

声明式 API

声明式 API 的出现非常便利，它让在现有网站中添加 WebMCP 变得像在表单上加几个 HTML 属性一样简单：

• toolname（必填）

  在 <form> 上添加此属性，告诉系统这是一个 WebMCP 工具，并指定工具名称。例如，如果表单用于发布评论，可以命名为 publish-comment。

• tooldescription（必填）

  描述该工具的功能。如果不加此属性，表单不会被声明为 WebMCP 工具。

• toolautosubmit（可选）

  当代理填写表单时自动提交。如果没有此属性，代理只会填写表单，不会提交。

示例表单：

<form
     id="login-form"
     toolname="login"
     tooldescription="通过邮箱和密码登录应用"
     toolautosubmit="true"
 >
     <label for="email">邮箱</label>
     <input
         type="email"
         id="email"
         name="email"
         required
         toolparamtitle="邮箱"
         toolparamdescription="用户邮箱地址"
     />
 </form>

只需添加这些属性，表单即可被 WebMCP 识别。

命令式 API

命令式 API 允许我们通过 JavaScript 动态声明或移除 WebMCP 工具。

浏览器提供 navigator.modelContext.registerTool 方法，通过传入工具名称、描述和属性模式 (schema) 来注册工具。然后通过 execute 方法定义当代理调用该工具时应执行的操作。

何时使用哪种 API

由于 WebMCP 非常新（撰写本文时仅几小时历史），还没有明确的最佳实践，但已有一个趋势：

1、每个表单都应声明为 WebMCP 工具

• 实现成本非常低

• 不这样做，代理仍会使用网站，但效果会更差

2、非表单操作 **（如登出）可以使用命令式 API

• 是否这类操作应设计为表单而不是普通链接，这将是另一个讨论话题

关于本文
译者：@飘飘
作者：@Nabors
原文：https://www.arcade.dev/blog/web-mcp-alex-nahas-interview

Node 社群

我组建了一个氛围特别好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你对Node.js学习感兴趣的话（后续有计划也可以），我们可以一起进行Node.js相关的交流、学习、共建。下方加 考拉 好友回复「Node」即可。

   “分享、点赞、在看” 支持一波👍