WebMCP、服务级MCP还是普通浏览器使用方式：代理工具应归属于哪一类。
深入探讨WebMCP：页面工具与服务级MCP及普通浏览器代理的对比，涵盖会话、OAuth CIMD、发现机制、本地状态及所有权问题。
来源: WebMCP: My Architectural Uneasiness and Where I Think It May Fit
乍看之下，WebMCP的设计颇为合理。用户已登录，浏览器内运行着代理程序，网站还能告知可执行的操作，因此代理无需自行猜测表单字段和按钮的位置。问题在于该接口的定位。当人们致力于让代理能够使用某个应用时，这些功能应该由页面本身提供，还是由其底层的服务提供？此外，页面级的工具接口又能为常规的浏览器工具带来什么新增价值？
以上两个问题构成了下文评估的框架。
WebMCP是什么
通过 WebMCP，网站可以注册结构化的工具，兼容的代理程序可通过浏览器调用这些工具。每个工具都会说明其功能、接受的输入以及执行该功能的代码。注册可以通过 JavaScript 或带注释的 HTML 表单完成。Chrome 将这一理念作为拟议中的标准进行记录，相关测试从 Chrome 149 版开始，且该 API 可能会发生变化。
想象一个航班搜索页面。在没有 WebMCP 的情况下，代理程序会读取页面，找到目的地输入框，设置日期后点击搜索。而有了 WebMCP 后，网站可以发布一个名为 search_flights 的工具，该工具接收目的地和日期信息。代理程序只需填写参数，应用程序便会执行搜索操作。
应将三种路径区分开来：服务级MCP、WebMCP以及普通浏览器使用场景。并没有强制要求必须选择其中一种，同一个代理可以针对某个产品调用服务工具，针对另一个产品调用页面工具，而对于第三种场景则直接操作浏览器。
架构方面的顾虑
人们的第一反应是，WebMCP将服务相关的问题引入了表现层。在典型的商业应用中，查询库存、修改预订或下订单这些操作最终都会由后端服务处理，而浏览器本身也会调用相应的接口来完成这些任务。那么为何不在服务旁边定义面向代理的契约，而要将其定义在页面内部呢？
一种自然的替代方案是从现有的服务契约入手，比如 OpenAPI 规范或 gRPC 定义，然后在其基础上构建 MCP 接口。这种方案的优点在于所有权明确——负责业务运营的团队可以对该面向代理的契约进行版本控制、测试和管理，而交互式代理、批处理任务以及定时工作流都可以使用它。
即便将内部端点封装在页面工具中，也不会降低该契约的要求。代理会收到具有特定输入要求与行为规范的操作指令，一旦这些行为发生变化，工作流就会出错。无论该工具在何处被使用，团队都必须决定要提供何种兼容性及支持水平，而将接口放到 Web 层并不会自动减轻这些责任。
仔细审视后会发现，最初的某些假设并不成立。
- 浏览器拥有实时状态。编辑器中可能包含未保存的草稿、当前选中的内容，或是那些在服务器端没有对应功能的本地操作，而将客户端视为空壳会忽略所有这些内容。
- 无需重复逻辑。某个工具可以调用与按钮相同的客户端函数，进而访问相同的后端接口。真正的担忧在于该工具会带来自身的生命周期管理，以及随着时间推移业务规则可能会在其周围不断堆积。
成熟度也很重要。一定的试验是不可避免的，但基于不断变化的浏览器API构建的界面会增加额外的维护工作。
因此，更合理的观点是：可持续的业务运营最好由实现该功能的服务本身来掌控和管理，只有在有特殊理由时才需将相关契约放在页面中。
会话重用与委托访问
认证优势源于在已登录的浏览器环境中运行，WebMCP与普通浏览器都具备这一优势。此处的比较是将这种便利性与委托服务访问方式进行对比。WebMCP相比普通浏览器交互所新增的功能则是另一个问题，将在后文详细阐述。
当代理在已登录的网站上点击某个控件时，应用程序会通过现有的会话发送请求，而直接调用的 WebMCP 工具也可以使用同一个会话。两者都无需在代理主机与服务之间进行额外的授权流程。
这种优势在各种应用程序中愈发显著。一个涉及五个服务的工作流可能需要五次授权、五个令牌生命周期以及五组集成要求，此外还有取决于每个服务的客户端注册工作。如果用户已经登录了这五个网站，重用这些会话就能大幅简化相关设置工作。
将此称为免费认证未免言过其实。实时会话有其自身的安全生命周期，而已登录并不等同于同意客服人员可能进行的任何操作。尽管如此，这种集成方式确实带来了实际好处。仅选择某一层级并不能解决注入攻击和不当操作的问题，因为这两种情况都需要相应的防护措施，比如对关键操作进行确认，且其暴露程度和执行方式各不相同，因此每种设计都必须独立评估相关风险。
CIMD如何缩小差距
服务级访问体验也在不断改善。客户端标识元数据文档（CIMD）解决了OAuth流程中的一个难题：全新的客户端如何向从未见过它的授权服务器标识自身。客户端使用HTTPS网址作为自己的标识，该网址会返回一份元数据文档，其中列出了允许的重定向URI等信息。相应的服务器会获取并检查这份文档，从而无需提前为每对客户端和服务器进行注册。2025年11月发布的MCP授权规范建议支持CIMD，并在没有预注册的客户端信息时优先采用这种方式而非动态客户端注册。
在五服务场景中，若在所有五个授权服务器上都启用CIMD支持，即可取消预先注册的功能。虽然各服务仍保留原有的授权要求及令牌生命周期，但现有的授权或会话可以减少提示次数，因此不一定需要再进行五次新的登录操作。CIMD本身不会影响授权决策的作出。
上下文、生命周期与发现
未保存的文档体现了本地浏览器状态的重要性。用于编辑未完成草稿中选定段落的工具，所操作的状态是该服务此前未曾见过的，这正是相比转发后端操作而言，更需要提供页面级工具的更具体原因。
问题在于，本地状态会将这些工具绑定在页面上。当用户离开该页面或关闭它后，代理可能需要先重新打开应用程序并重建上下文。登录会话通常可以延续到页面关闭之后，而消失的则是未保存的状态以及存在于该状态中的工具。
发现机制则是另一回事：代理要如何知晓某个网站提供了什么功能？Chrome的官方文档指出，必须先访问该网站才能了解其WebMCP工具的信息。已知的MCP端点可以直接查询，无需人工干预，但从单纯的网址中定位这样的端点则是一项独立的挑战；此外，OAuth元数据只能找到已知受保护资源的授权服务器，无法提供MCP功能的通用列表。
SEP-2127 项目名为 MCP Server Cards，它提出了一种通过 HTTP 发布结构化服务器元数据的标准方式，从而使客户端能够在建立 MCP 连接之前发现服务接口，且无需操作面向用户的页面。这是一个很有前景的方向。在撰写本文时，该 pull request 仍处于开放状态，因此它只是针对现有缺陷提出的建议，并非已被广泛采用的解决方案。
在服务发现方面，双方目前都没有绝对的优势——页面工具需要用户访问网站，而从任意地址进行服务发现则尚未形成通用标准。此外，这两类技术也都无法保证良好的管理机制，因为 WebMCP 工具虽然可以经过充分测试和维护，但服务工具的设计却可能很糟糕。真正的问题在于责任归属以及该接口必须支持哪些工作流程。
浏览器代理在没有该功能的情况下依然可以正常工作
值得查看的是，浏览器代理在未使用WebMCP的情况下能够获取哪些信息。在同一个编码代理桌面会话中，浏览器工具定义优先采用基于无障碍功能的元素操作，条件允许时使用截图提供视觉上下文或作为备用方案，而文档页面返回的无障碍信息也颇具参考价值。这仅仅是针对特定会话的观察结果，并非对所有版本或默认设置的全称。
该集成为代理提供了关于渲染界面的结构化描述，包括文本框、按钮、标签、数值及状态等信息，同时还有面向DOM的工具可用于执行相应任务。实际呈现的页面内容以结构化文本的形式出现，其比例高于人们基于截图为主的预期。对于一个简单的搜索表单，代理收到的信息可能类似于此。
1 textbox “Destination”, value: “Tokyo”
2 button “Search flights”, enabled
由此，代理可以识别目标字段，点击“搜索航班”按钮并查看更新后的状态。HTML语义和无障碍标签已经承载了界面的大部分含义。模型接收到的页面视图取决于集成方式而非模型名称，OpenAI的计算机使用文档中展示了截图被发送给模型、操作则通过应用程序提供的工具返回的集成示例。
其结果是，代理无需 WebMCP 即可操作某个站点，这减少了站点开发者需要构建的内容。但这并不能决定 WebMCP 是否值得使用。无障碍功能树会列出各种控件，而设计良好的工具则能描述整个操作过程及其输入参数，从而减少交互次数和猜测成本。当浏览器代理需要通过十种控件来完成某项任务时，应用程序可以提供一个工具来替代这些控件。Chrome 将 WebMCP 视为渐进式增强技术，并提供了调试工具供用户测试。
在本次评估中并未进行有控制的 WebMCP 工具使用与未使用情况的对比测试，因此这属于架构层面的判断而非性能测试结果。要给出公正的结论，应衡量多种工作流程下的任务完成情况、交互次数以及耗时。一个成功的演示虽然是个不错的起点，却无法回答那个更广泛的问题。
能够部署的内容还取决于团队能够控制哪些接口。WebMCP需要网站的配合，而服务集成则需要可访问且经过授权的服务接口。如果第三方应用无法提供这两者，那么使用普通浏览器可能是唯一的可行方案。
现状分析
综上所述，可参考的出发点如下：
- 服务级工具适用于需要持续运行的业务操作，尤其是那些无需人工干预或需长时间运行的流程。
- WebMCP则在本地应用状态至关重要，或通过复用已认证的客户端工作流能大幅减少集成工作量时较为适用。
- 普通浏览器使用则适用于缺乏专用工具的情况，尤其是那些团队无法控制的应用程序。
对于那些已有明确服务边界的功能而言，若让 WebMCP 成为其默认载体，依然会引发担忧。虽然会话便捷性是支持这一方案的强有力理由，但它不应单独决定长期的架构设计。
若能有证据表明，在特定应用中，基于页面定义的工具相比普通浏览器使用方式能以更低的总体成本实现相同功能，而这种成本还包含了授权、维护、管理以及该接口无法处理的工作流程，那么就能改变目前的观点。
当以下三要素同时存在时，WebMCP的功能最为强大：实时且经过身份验证的会话、有价值的本地状态，以及值得重复使用的客户端工作流程。普通浏览器使用也能实现会话复用，因此关键问题在于哪些具体的工具能够起到辅助作用。那种仅将操作转发给服务的页面工具，仍然需要一个合理的理由来解释为何要在页面上保留面向代理的契约。