WebMCP 试用前要看什么：浏览器代理调用网站工具的权限边界与回退方案

如果一个网站希望让浏览器代理代替用户完成“查库存、填表单、提交预约”，WebMCP 给出的思路不是再造一套后台接口，而是把网站已有的 JavaScript 动作或 HTML 表单描述成代理可以发现的工具。它目前仍处于提议标准和早期预览阶段，真正试用时最该先确认的不是“能不能调用”，而是调用发生在哪个页面、拿着什么权限、失败后能否退回人工操作。

WebMCP 适合当作渐进增强：先让普通用户流程完整可用，再把少量、边界清楚的动作暴露给代理，并把写操作当成高风险行为逐一确认。

WebMCP 解决的是哪一段交互

传统代理要完成一次下单，通常只能观察页面、定位输入框、模拟点击，再根据页面变化猜下一步。这条路径对按钮文案、布局和异步状态都很敏感。WebMCP 的变化在于：网站主动声明“我提供哪些工具、工具需要哪些结构化参数、执行后返回什么结果”，代理先发现工具，再调用网站自己的业务逻辑。

Chrome 官方介绍把它描述为一种让网站对 AI agent 暴露结构化工具的提议式 Web 标准。当前实现围绕 document.modelContext 展开；公共草案还明确说明，浏览器可以用自己的方式把工具提供给代理，并不承诺一定采用某种 MCP 传输格式。

从工具注册到页面状态的调用链

以“把一项待办加入当前列表”为例，页面可以注册一个名为 add-todo 的工具，给出 text 参数，然后在 execute 中复用页面原本的 addTodoItemToCollection 逻辑。关键点不是给代理再写一份业务代码，而是让代理进入既有的状态更新路径。

document.modelContext.registerTool({
  name: "add-todo",
  description: "Add a new item to the user's active todo list",
  inputSchema: {
    type: "object",
    properties: {
      text: { type: "string", description: "The text content of the todo item" }
    },
    required: ["text"]
  },
  async execute({ text }) {
    await addTodoItemToCollection(text);
    return { content: [{ type: "text", text: "Todo added" }] };
  }
});

这条链路可以拆成四个可检查的节点：页面注册工具、代理读取名称和 schema、页面执行既有动作、页面返回文本结果。只要其中一个节点把“已提交”说成“已保存”，用户看到的状态就会和代理拿到的结果脱节，所以返回内容应对应真实的 UI 状态，而不是写一段乐观提示。

第一次试用先处理两个实验开关

Chrome 149 的官方 DevTools 更新文章提到，WebMCP 调试能力仍是实验功能，需要在 chrome://flags 中启用 #devtools-webmcp-support 和 #enable-webmcp-testing。Chrome 的 WebMCP 文档还提醒，具体功能处在 early preview，不能把 Canary 或实验旗标下的行为当成稳定版兼容承诺。

1. 准备一个只包含测试数据的页面，先确认普通按钮和表单能独立完成任务。
2. 在 Chrome Canary 的 chrome://flags 中启用文档要求的实验项，重启浏览器。
3. 打开页面的 DevTools Application 面板，检查工具名称、输入 schema 和调用事件。
4. 先用只读或可撤销动作验证返回结果，再测试写入动作；每次调用后对照页面真实状态。

如果 Application 面板看不到工具，优先检查页面是否在当前浏览器实验范围内、注册代码是否在文档加载后执行，以及页面是否真的使用了 document.modelContext。不要先把问题归咎于代理模型。

权限边界要放在工具描述之外

WebMCP 页面可能运行在用户已经登录的浏览器会话里，因此“代理能调用工具”实际上可能等于“代理能借用用户当前身份执行动作”。Chrome 的安全建议把恶意工具描述、被污染的工具输出和间接提示注入都列为风险来源。工具名称和描述不是安全策略，返回的第三方文本也不能自动当成可信指令。

跨源 iframe 默认不能随意取得同样的能力；WebMCP 草案给出的方向是通过 Permissions Policy 的 allow="tools" 显式委托。Chrome 安全文档还建议用 exposedTo 把工具限制到明确的可信 origin。对于读取订单、发送评论、提交付款这类动作，最好拆成“读取”和“确认写入”两个阶段，不要把所有能力塞进一个万能工具。

不支持 WebMCP 时的回退设计

WebMCP 的价值在于改善代理完成任务的可靠性，但它不应成为唯一入口。页面仍要保留正常的 HTML 表单、按钮、键盘操作和服务端校验；代理没有发现工具时，可以继续使用普通页面交互，用户也能手动完成同一个任务。

回退时有三条底线：第一，写操作前继续显示确认信息；第二，服务端再次校验用户身份、参数和业务状态；第三，工具返回失败时给出可读错误，并让用户回到表单而不是停在半完成状态。这样即使实验 API 变化，网站的核心业务链路也不会被一起带走。

哪些场景现在值得试，哪些先别接

适合先试的动作

查询公开信息、筛选当前列表、生成待确认的草稿、读取可公开的页面状态，比较容易观察结果，也容易撤销。它们适合用来验证工具 schema 是否清楚、页面状态是否能被准确反馈。

需要人工确认的动作

改地址、发评论、提交订单、删除数据和改变账号设置都可能产生外部影响。即使工具标记为只读，也应检查它实际是否改变状态；Chrome 安全文档建议在没有明确只读提示时按可能写入来设计防护。

把实验能力接入生产前的核对清单

• 工具名称、参数名和描述是否短而明确，没有把指令藏在描述里。
• 是否记录了工具来源 origin、调用参数、返回状态和用户确认动作。
• 跨源 iframe 是否只向确实需要的来源授予 allow="tools"。
• 读操作和写操作是否分离，写操作是否可以撤销或回退。
• 关闭实验开关或不支持 WebMCP 时，普通按钮和表单是否仍能跑通。

常见问题：试用 WebMCP 时最容易混淆的边界

WebMCP 是 MCP 服务端吗

名称相近，但不要直接把网页工具等同于后端 MCP server。WebMCP 的草案重点是页面在客户端暴露工具，浏览器如何把工具交给代理由实现决定。

为什么工具注册成功却不能调用

常见原因包括实验开关未启用、权限策略没有授予、页面并非预期 origin，或者工具注册发生在页面状态尚未准备好时。先在 DevTools 中核对工具清单和调用事件，再看代理侧。

结语

WebMCP 的新闻价值在于它把“代理如何操作网站”从猜测页面，推进到网站声明可调用能力。但它仍是实验中的平台提议，试用的正确姿势是从最小、可观察、可撤销的动作开始，把来源限制、用户确认和普通页面回退一起设计。等 API 和浏览器支持范围继续稳定，再决定是否扩大工具面。