1. 从 AMP 到 WebMCP：同一套剧本换了主角
Chrome WebMCP 是什么？简单说，它是 Chrome 团队推动的一套浏览器侧协议，目标是让 AI 代理不用再靠解析 DOM 去猜网页按钮在哪，而是由网站主动声明「我这里有哪些可被调用的操作」。适合谁？适合正在做 AI Agent、浏览器自动化、工具链接入的开发者。能做什么？把网页表单、按钮、动态交互抽象成 AI 可调用的工具描述，让代理调用更稳定。
但只要你经历过 AMP 那几年，就会有一种强烈的既视感。AMP 当年也是 Google 主导、也是「为了更好的体验」、也是网站必须额外适配一套东西才能拿到流量倾斜。结果呢？内容方被迫维护两套页面，生态怨声载道，最后 AMP 逐渐淡出。现在 WebMCP 的争议点几乎一模一样：为什么不用已有的 OpenAPI？为什么网站要额外维护一套给 AI 用的接口？浏览器直接解析 DOM 不是更合理吗？
我试过把这两件事放在一起看，结论是：技术本身不坏，坏的是「谁来定义标准、谁承担维护成本、谁掌握分发权」这三件事从来没变。这篇不站队，只交付能跑的东西——一套可复制的 MCP 服务端config.toml骨架、OpenAPI 到 MCP 的映射配置，以及在 Chrome 里验证 WebMCP 端点连通性的具体步骤。跑通之后，你自己判断它是开放标准还是平台锁定重演。
2. TaoToken 前置：把模型侧和协议侧解耦
在验证 WebMCP 之前，得先有一个能稳定调用的模型侧入口，否则你连「AI 代理调用工具」这条链路都跑不起来。我的做法是把模型调用统一走 TaoToken，这样协议层怎么变、Chrome 怎么改，模型侧不用跟着动。
TaoToken 官网地址是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 入口是 https://taotoken.net/api ，注意 API 这个地址不加 UTM 参数，直接填就行。它的作用是提供兼容主流协议的统一调用入口，你可以在模型对话、Coding Plan、控制台、API Keys 几个模块里分别拿到需要的东西。
具体分工是这样的：如果你只是想先验证模型能不能正常返回，去模型对话页面试；如果你要长期做编码类 Agent，看 Coding Plan；如果你要拿 Key 接进自己的 MCP 服务端，去 API Keys 页面生成。接入文档在 doc 页面，ClaudeCodeAnthropic 相关的配置也有对应说明。
这里有个关键点：WebMCP 争议的核心之一是「信任模型翻转」——网站定义工具，浏览器决定调用。那我们在本地验证时，就要把模型侧和工具侧分开管理，模型只负责决策，工具执行走我们自己的 MCP 服务端，这样权限边界清晰。TaoToken 在这里扮演的就是「模型决策层」的稳定入口，不掺和工具执行。
3. 可复制配置：config.toml 骨架与 OpenAPI 映射
下面这套配置是我实测能跑通的骨架。核心思路是：用 OpenAPI 描述你已有的后端接口，再通过映射层把它转成 MCP 工具，这样你不需要为 WebMCP 单独维护一套接口定义——这正好回应了「为什么不用 OpenAPI」的质疑。
先看 MCP 服务端的config.toml：
# config.toml - MCP 服务端骨架 [server] name = "webmcp-bridge" version = "0.1.0" transport = "http" host = "127.0.0.1" port = 8787 [model] # 模型侧统一走 TaoToken，协议层变化不影响这里 provider = "taotoken" base_url = "https://taotoken.net/api" api_key_env = "TAOTOKEN_API_KEY" default_model = "claude-sonnet" [openapi] # 指向你已有的 OpenAPI 描述文件，不重复造轮子 spec_path = "./openapi/flight.yaml" base_url = "https://your-backend.example.com" [mcp.tools] # 把 OpenAPI 的 operationId 映射成 MCP 工具名 [[mcp.tools.map]] operation_id = "searchFlights" tool_name = "search_flights" description = "根据出发地、目的地、日期搜索航班" [[mcp.tools.map]] operation_id = "selectSeat" tool_name = "select_seat" description = "为指定订单选择座位" [security] # 信任边界：只允许白名单工具被调用 allow_tools = ["search_flights", "select_seat"] require_user_confirm = true对应的 OpenAPI 片段（openapi/flight.yaml）长这样：
openapi: 3.0.3 info: title: Flight Booking API version: "1.0" paths: /flights/search: get: operationId: searchFlights parameters: - name: from in: query required: true schema: { type: string } - name: to in: query required: true schema: { type: string } - name: date in: query required: true schema: { type: string } responses: "200": description: OK /orders/{orderId}/seat: post: operationId: selectSeat parameters: - name: orderId in: path required: true schema: { type: string } requestBody: content: application/json: schema: type: object properties: seat: { type: string } responses: "200": description: OK这套配置的意义在于：你的后端接口只维护一份 OpenAPI，MCP 工具是映射出来的，不是重写的。WebMCP 如果真成了标准，你加一层适配即可；如果它像 AMP 一样凉了，你删掉映射层，OpenAPI 还在。这就是「不把鸡蛋放进一个篮子」。
注意：
require_user_confirm = true这行别省。WebMCP 最大的安全争议就是网站定义工具、浏览器自动调用，本地验证阶段强制用户确认，能避免「add_to_cart 实际在偷数据」这类问题。
4. 验证请求：在 Chrome 中确认端点连通
配置写完了，得验证。分两步：先确认 MCP 服务端本身活着，再确认 Chrome 侧能发现 WebMCP 端点。
第一步，启动服务端并做一次本地请求：
export TAOTOKEN_API_KEY="你的key" python -m mcp_server --config ./config.toml服务起来后，用 curl 打一下工具列表：
curl -s http://127.0.0.1:8787/mcp/tools | jq正常返回应该是这样的结构：
{ "tools": [ { "name": "search_flights", "description": "根据出发地、目的地、日期搜索航班", "source": "openapi:searchFlights" }, { "name": "select_seat", "description": "为指定订单选择座位", "source": "openapi:selectSeat" } ] }看到source字段指向 OpenAPI 的 operationId，说明映射层生效了。
第二步，在 Chrome 里验证 WebMCP 端点连通性。打开开发者工具，切到 Console，执行：
// 检查浏览器是否暴露 WebMCP 相关能力 if (navigator.modelContext) { console.log("WebMCP available"); navigator.modelContext.getTools().then(tools => { console.log("discovered tools:", tools); }); } else { console.log("WebMCP not available in this build"); }如果当前 Chrome 版本还没开这个预览功能，navigator.modelContext会是undefined，这很正常——它还是早期预览。这时候你可以退一步，用本地 MCP 服务端模拟浏览器侧的调用：
curl -s -X POST http://127.0.0.1:8787/mcp/invoke \ -H "Content-Type: application/json" \ -d '{ "tool": "search_flights", "arguments": {"from": "PEK", "to": "SHA", "date": "2026-03-01"} }' | jq成功的话会返回后端接口的真实响应。这一步跑通，说明「OpenAPI → MCP 工具 → 调用」这条链路是通的，WebMCP 只是在这条链路上多了一层浏览器发现机制而已。
5. 本篇常见错排查
报错一：navigator.modelContext is undefined。这是最常见的，原因就是当前 Chrome 没开 WebMCP 预览。别急着怀疑配置，先去chrome://flags搜相关实验项，或者确认你的 Chrome 版本是否包含该功能。没有就先用本地 MCP 服务端验证链路，别卡在这。
报错二：operationId not found。说明config.toml里的operation_id和 OpenAPI 文件里的对不上。注意大小写，searchFlights和searchflights是两个东西。建议用yq先把 OpenAPI 里的 operationId 列出来核对：
yq '.paths[].*.operationId' openapi/flight.yaml报错三：调用返回 401。模型侧或后端侧的 Key 没配好。模型侧检查TAOTOKEN_API_KEY环境变量是否导出成功，后端侧检查 OpenAPI 里base_url指向的服务是否需要额外鉴权头。两者是独立的，别混在一起查。
报错四：工具被拒绝执行。看config.toml里的allow_tools白名单，工具名没在里面就会被拦。这是安全设计，不是 bug。要加工具就往白名单里加，别直接关掉require_user_confirm。
报错五：端口冲突。8787被占用就换一个，改config.toml里的port，同时记得 curl 和 Chrome 里的地址一起改。
6. 跑通之后，再谈路线之争
把上面这套跑通，你手里就有了一条不依赖任何单一浏览器标准的 AI 工具调用链路：OpenAPI 描述接口，MCP 映射成工具，模型侧走 TaoToken 统一入口。WebMCP 如果成为开放标准，你加一层浏览器发现适配；如果它变成 AMP 那样的平台锁定，你删掉适配层，核心链路不受影响。
回到标题的问题：Chrome WebMCP 是开放标准还是 AMP 重演？我的判断依据很简单——看它是否强制、看维护成本谁承担、看不用它会不会被降权。AMP 当年三条全中，所以凉了。WebMCP 现在还在早期，三条都还没坐实，但开发者的警惕是对的。
如果你要长期做编码类 Agent，建议把模型侧固定下来，去 Coding Plan 页面看长期方案；如果只是验证模型调用是否正常，模型对话页面最快；如果要拿 Key 接进自己的服务端，直接去 API Keys 页面生成，接入细节看 doc 文档，ClaudeCodeAnthropic 的配置也有专门说明。链路跑通，标准怎么变你都不慌。
