WebMCP 怎么接入网站？Chrome 149 Tool Schema、Form 与 registerTool 实战

如果你看到旧教程还在用 navigator.webmcp、把页面状态整包塞给 Agent，或者把 WebMCP 当成“让 AI 自动点网页”的魔法层，先不要照抄。到 2026 年 8 月，Chrome 的当前文档已经把 WebMCP 讲得更清楚：网站主动注册结构化工具，Agent 通过明确名称、描述和输入 Schema 理解能做什么。

Chrome 149 提供了 WebMCP Origin Trial；8 月 26 日的新指南进一步强调，工具设计应该从用户目标、状态转换和对话路径出发，而不是把每个按钮机械地变成 Tool。

最简单的接入：让现有 Form 直接成为 Tool

如果你的动作本来就是一个表单，例如搜索、筛选、预约、提交查询，可以优先使用声明式 API：

<form
  toolname="search_docs"
  tooldescription="Search XBSTACK technical documentation"
  action="/search"
>
  <input
    name="q"
    toolparamdescription="Technical topic or error message"
  />
  <button type="submit">Search</button>
</form>

这种方式的好处是页面在人类浏览器中仍然是普通 Form，同时 Agent 得到了结构化的任务名称和参数语义。它适合“页面原本就有清晰提交动作”的场景。

复杂动作：使用 document.modelContext.registerTool

当动作依赖页面状态、客户端逻辑或复杂验证时，当前文档使用 document.modelContext.registerTool：

await document.modelContext.registerTool({
  name: 'inspect_agent_readiness',
  description: 'Inspect the current site for agent-readiness signals.',
  inputSchema: {
    type: 'object',
    properties: {
      url: { type: 'string', format: 'uri' }
    },
    required: ['url']
  },
  annotations: {
    readOnlyHint: true
  },
  execute: async ({ url }) => {
    return await inspectReadiness(url)
  }
})

这里真正重要的不是语法，而是 Tool contract。name 要稳定且可理解；description 要说明什么时候应该调用；Schema 要把 Agent 能输入的边界写清楚；会产生副作用的动作不能伪装成只读。

不要把每个按钮都注册成 Tool

Chrome 8 月 26 日的指南给了一个很实用的判断框架：先写出用户目标，再写目标开始状态、完成状态和中间状态转换，然后决定哪些转换值得成为工具。

例如电商页面中，“展开详情”“切换 Tab”可能只是界面动作；“查询库存”“加入购物车”“提交订单”才更像 Agent 需要理解的任务节点。

如果注册几十个低层按钮工具，Agent 反而更难选。好的 WebMCP Tool 应该尽量对应用户任务，而不是 DOM 结构。

安全边界仍然要自己设计

WebMCP 只让 Agent 看见你显式暴露的工具，不会替你解决授权。当前 Chrome 安全文档建议对只读能力明确使用 readOnlyHint，跨源暴露则通过受信任来源约束，涉及用户数据和写操作时尤其需要谨慎。

对于删除、付款、发布、权限修改这类动作，仍然应该有业务侧鉴权、参数校验、用户确认和审计记录。不要因为调用方是 Agent 就绕过已有权限系统。

怎么验证接入真的生效

第一步是功能验证：在支持实验能力的 Chrome 环境中确认工具实际注册，参数 Schema 和执行结果符合预期。

第二步是 Lighthouse。Chrome 已经提供 Registered WebMCP tools 审核，可以列出页面通过声明式或命令式 API 注册的工具。如果结果为空，说明页面没有被 Lighthouse 观察到有效工具。

第三步是对话/Eval。用不同自然语言表达同一目标，观察 Agent 是否选择了正确工具、是否提取了正确参数、是否在错误状态下拒绝执行。

第四步是生产 telemetry。真正上线后，应记录工具曝光、调用、成功、失败和关键参数类型，而不是只看页面 PV。

WebMCP 和 llms.txt 不是一回事

llms.txt v2 解决的是“Agent 怎么发现和理解网站内容”；WebMCP 更偏向“Agent 在页面上能执行哪些结构化任务”。一个偏发现，一个偏操作。如果还需要理解 WebMCP 与独立 MCP Server 的边界，可以继续看 MCP 协议指南。

所以更完整的站点 Agent Readiness 应该是：

robots / sitemap / canonical
        ↓
llms.txt + Markdown discovery
        ↓
清晰的页面内容和结构化语义
        ↓
WebMCP tools（真正需要操作时）
        ↓
auth / confirmation / telemetry

XBSTACK 的 Agent Readiness Auditor 就是按这种分层思路检查，而不是看到 /llms.txt 或一个 registerTool 就直接判定“Agent Ready”。

当前建议

如果你现在准备试 WebMCP，先选一个只读、低风险、结果容易验证的任务做 Origin Trial，例如站内搜索、文档查询、产品参数读取。跑通 Tool Schema、Agent 选择、错误路径和 telemetry 后，再扩展到写操作。

WebMCP 的方向值得提前布局，但当前仍是实验技术。把实验边界、浏览器版本和 fallback 写清楚，比为了抢“AI 网站”概念一次注册几十个工具更重要。

专题入口 / MCP Hub

继续按 MCP 生产部署路径读，而不是堆 guide / tutorial

MCP 内容统一按协议理解、本地 Server、远程部署、OAuth、安全治理、stdio/JSON-RPC 排障和工具对比来承接，避免站内关键词互相抢。

进入 MCP 专题 → 查看安全治理清单 订阅