用 WebMCP 为网站提供智能体调用入口

给网站接入 AI Agent，不一定要让它对着页面猜按钮。作者给自家的服务页加入了 WebMCP，把查询服务、检索 FAQ、预填表单变成可直接调用的工具。做法很克制：先开放查询，把提交留给访客。

这篇值得读的是接入边界：页面该暴露什么能力，怎样兼容不支持的浏览器，哪些操作必须保留人工确认。它提供了一套小规模试验思路，但没有证明 WebMCP 已经成熟，也没有流量增长的证据。

先把页面能力变成工具，别急着开放写操作

传统网页自动化依赖页面外观：识别按钮、猜测用途，再执行点击。弹窗或主题更新，都可能让原来的操作路径失效。

WebMCP 的思路是让页面注册具名工具，Agent 根据描述和输入结构调用。页面直接告诉 Agent「我能做什么、需要什么参数」，减少它从界面推断操作的环节。

作者选择了三个入口：

• get_webmcp_services：返回服务套餐和联系方式，只读。
• answer_webmcp_question：搜索页面 FAQ，最多返回 3 条答案，只读。
• prepare_audit_request：预填审计申请表，不发送申请，由访客检查并点击提交。

这三个工具覆盖了查询、问答和申请准备，数据都来自页面已有内容，没有另建一套知识系统。

FAQ 工具的实现也很朴素。它把问题转成小写，用 /[^a-z0-9]+/ 分词，只留下长度大于 2 的词；再计算每条 FAQ 命中了多少词，过滤零分结果，按分数降序排列，执行 .slice(0, 3)，最后用 JSON.stringify(matches) 返回。

这是关键词匹配，并没有语义检索。实现容易检查，但匹配质量取决于用户措辞和 FAQ 内容。

接入代码很短，兼容性和输入约束要看仔细

据原文，截至 2026 年 10 月，WebMCP 仍是拟议中的 Web 标准，Chrome 处于 origin trial 和实验开关阶段，Firefox、Safari 尚未宣布支持。

作者还提到，API 在 2026 年从 navigator.modelContext 移到了 document.modelContext。下面的检查兼容两个入口，也让不支持的浏览器直接跳过：

const mc = document.modelContext || navigator.modelContext;
if (!mc || typeof mc.registerTool !== 'function') return;

要注意第二行：这段代码需要放在允许 return 的函数体里，不能直接作为模块顶层代码粘贴。

注册工具使用 mc.registerTool，包含名称、描述、inputSchema 和 execute。其中 answer_webmcp_question 要求传入字符串 question，并通过 annotations: { readOnlyHint: true } 标注只读意图。描述还明确写出最多返回 3 条，方便 Agent 判断结果范围。

表单工具则调用 clip 处理 name、email、website，通过 CustomEvent('uwm:prefill', { detail }) 向 React 表单发送预填数据，再定位 uwm-audit-form，调用 scrollIntoView({ behavior: 'smooth', block: 'center' })。

原文没给出 clip 的实现，也没展示 React 监听事件的代码，因此不能把它当作完整可运行方案。输入截断同样不能代替校验。

工具负责准备，访客负责确认，服务端继续检查权限。

作者把发送表单、预约、修改购物车都放在需要访客批准的范围内，并提醒不要通过工具暴露管理功能或其他客户的数据。

普通表单也能接入，但它不是远程 MCP 服务

如果已有表单能表达操作，原文给出了更短的声明式写法，用两个属性描述工具：

<form toolname="search_products"
      tooldescription="Search the store catalog by keyword and maximum price."
      action="/shop">
  <label for="q">Search</label>
  <input id="q" name="q">
  <label for="max">Max price</label>
  <input id="max" name="max_price" type="number">
</form>

关键是 toolname 和 tooldescription。q、max_price 仍是普通表单字段，目标地址仍为 /shop。按原文描述，浏览器会填好并展示表单，默认由访客点击按钮。不过示例本身没有提交按钮，照搬时还需要补齐实际交互。

WebMCP 与远程 MCP server 的运行位置不同：前者运行在页面里，使用访客当前会话；后者运行在服务端，供 AI 应用使用。选型时要先看能力需要依附网页会话，还是需要由独立服务提供。

作者还介绍了自家的免费 checker：读取一个页面及最多 8 个脚本，列出发现的工具，检查表单和 Agent 所需的数据。这是检测入口，原文没有给出它的识别覆盖率或准确率。

我的判断

我赞同从只读能力开始。页面已经展示的服务信息和 FAQ，适合作为接入试验，也更容易人工核对结果。

但「比点击更可靠」目前是架构上的合理预期。作者没有提供成功率、耗时或与传统浏览器自动化的对照数据，也没有交代实际 Agent 调用规模。它适合作为经验参考，不能当成效果保证。作者同时销售相关集成服务，文章也带有服务推广目的。

对国内团队，还有一个直接限制：示例分词规则只保留英文字母和数字，纯中文问题会被过滤掉，无法直接用于中文 FAQ。中文检索需要另做处理。

成熟度也要算进投入。原文明确说目前使用它的 Agent 很少，API 仍可能变化，没有证据表明它影响搜索排名。普通表单和现有交互仍要做好，readOnlyHint 这类标注也不能替代实际权限控制。

能拿来做什么

• 先从服务说明或 FAQ 选一个只读入口，复用已有数据，检查工具返回内容是否与页面一致。
• 在 React 里接入表单预填时，让事件更新表单状态，并保留访客检查、手动提交及原有校验流程。
• 面向中文用户时，先验证中文问题能否检索成功，再决定采用分词、全文检索或其他匹配方式。
• 把 WebMCP 作为渐进增强试验：检测支持后再注册工具，持续检查 API 变化，并用实际调用结果判断是否继续投入。