Anthropic Simon 测试揭示自定义 MCP 连接背后的摩擦

Anthropic 观察者 Simon Willison 将一个自定义 MCP 服务器连接到 Claude 和 ChatGPT，但这项实验展现出两条截然不同的设置路径。他在 7 月 29 日的测试表明，尽管存在产品门槛、远程托管要求和授权工作，标准聊天界面仍可使用开发者构建的工具。

Anthropic Simon 实验之所以重要，是因为 Model Context Protocol 正在超越编程代理和桌面配置文件。MCP 是一种用于连接 AI 应用与外部工具和数据的开放协议，如今正进入日常聊天窗口。这扩大了它的受众，也让产品层面的限制更难被忽视。

Claude 将这种连接呈现为自定义连接器。ChatGPT 则通过其应用系统和开发者控制功能提供相似能力。两者都能连接远程服务器，但都不会将该服务器变成可在任何环境通用的插件。协议标准化了通信，而各个宿主平台仍控制着发现、权限、审批和可用性。

Simon Willison 的 MCP 测试实际改变了什么

一个自定义 MCP 服务器如今可以同时服务 Claude 和 ChatGPT，用户无需离开标准网页对话界面。

Willison 在其于 2026 年 7 月 29 日发布的自定义 MCP 测试中记录了这一过程。核心结果很直接：开发者可以托管 MCP 服务器，将其注册到两项服务中，并在各自常规聊天界面内提供工具。

这一结果使该实验区别于早期围绕 Claude Code、桌面配置文件或面向开发者客户端展开的 MCP 演示。这些环境原本就让工具连接相对自然。标准消费级聊天产品则多了一层账户规则和界面控制。

服务器必须能从远程访问。使用标准输入输出传输的本地进程，无法直接出现在浏览器会话中。宿主需要提供一个可通过互联网访问的 HTTP 端点，并实现各客户端所预期的 MCP 功能部分。

远程访问改变了部署模式。开发者不再只是配置一个应用程序，让它在个人电脑上启动一个可信进程；而是在运营一项网络服务，必须处理传输安全、身份、授权、可用性，以及潜在的多用户需求。

Claude 将这类集成称为自定义连接器。Anthropic 表示，它们可通过远程 MCP 服务器将 Claude 连接至托管工具和数据源。其当前的连接器指南列出了符合条件的个人和工作场所账户可使用的 Claude 与 Claude Desktop 支持。

ChatGPT 则通过自定义应用和 MCP 连接器描述同一类广泛能力。OpenAI 的界面还区分了创建应用、测试应用、批准应用，以及在工作区内提供应用等步骤。

这种命名差异不只是表面问题。“连接器”意味着通往既有服务的桥梁；“应用”则意味着某种被打包、审核并通过宿主控制的产品界面分发的内容。MCP 可以支持任一模式，但这些标签会塑造用户预期。

服务器还需要提供有用的工具定义。这些描述会告知模型每个工具的用途、何时应调用，以及接受哪些输入。即使端点在技术上有效，若工具之间重叠或描述模糊，实际表现仍可能不佳。

因此，Willison 的测试证明的是协议层的互操作性，而不是各产品间完全一致的行为。Claude 和 ChatGPT 可以发现同样的基本能力，但它们仍可能以不同方式选择工具、请求不同审批，并通过不同界面呈现结果。

对开发者而言，值得记住的并不是两家公司都以某种形式支持 MCP。更重要的变化在于：同一个托管实现如今能够触达两款主流聊天产品中的用户。这使跨产品测试变得可行，无需维护两套完全独立的集成协议。

为什么 Anthropic Simon 的结果给两大 AI 平台带来压力

MCP 将竞争的一部分从模型智能转向对工具、权限和分发的控制。

Anthropic Simon 的结果给 Anthropic 带来压力，因为它创建了 MCP，并将该协议推广为开放标准。Claude 必须继续作为令人信服的参考客户端。若外部服务器在其他地方表现得更可预测，协议作者身份并不能保证平台偏好。

OpenAI 面临的是相反的压力。它并非 MCP 的发起者，但 ChatGPT 作为应用平台具有巨大影响力。开发者会期待它支持那些已能与 Claude 和其他 MCP 客户端配合使用的集成。

这形成了协议可移植性与平台控制之间清晰的竞争。开发者希望一次描述工具，并将其连接到多个兼容产品；平台运营者则希望决定哪些账户可以连接服务器、哪些操作被允许，以及高风险调用如何接受审查。

Claude 目前为多种账户类型提供直接的自定义连接器概念。工作场所使用场景引入了管理员控制，因为连接器可能暴露公司数据或执行操作。所有者可以配置可用性，而个人用户仍以自身权限进行身份验证。

ChatGPT 采用了更明确的部署结构。OpenAI 当前的开发者模式指南称，完整 MCP 支持已面向网页版的 Business、Enterprise 或 Edu 客户提供。该指南还描述了 Pro 用户可获得的更有限的读取和获取访问权限。

当服务器暴露写入操作时，这一区别尤为重要。搜索文档集合是一种风险状况；更新客户记录、发布内容或删除项目则是另一种。

OpenAI 表示，写入和修改操作可能会根据权限、上下文和潜在影响触发确认。一些风险特别高的操作可能被阻止。工作区管理员还控制应用是否能从私人测试进入获批可用状态。

Anthropic 同样建议用户检查工具请求，并仅启用与当前对话相关的工具。这一警告反映出代理式界面的基本局限：自然语言请求并不总能揭示模型可能认为有必要执行的每一项外部操作。

这些控制削弱了最简单的可移植性承诺。开发者可以复用服务器、模式和授权基础，但不能假设访问权限、用户流程、确认行为或模型决策会保持一致。

这类割裂不一定意味着协议失败。MCP 定义了客户端与服务器之间的共同语言，但并不要求每个宿主采用相同的产品政策。

不过，产品摩擦可能决定协议兼容性在实践中是否重要。隐藏在管理员设置后的连接，触达的用户会少于可从个人设置页面启用的连接。只读实现也无法替代允许经审慎批准后执行写入的竞争对手。

工具调用质量还带来另一层压力。模型必须选择正确的工具、生成有效参数、解读错误并传达结果。支持 MCP 传输并不保证能够可靠完成用户任务。

因此，开发者应在两个平台上测试相同的提示词。服务器可能暴露完全相同的工具，却产生不同的调用模式。这些差异可以揭示描述是否存在歧义，或某个宿主是否施加了更严格的控制。

更广泛的竞争问题已不再是 Claude 或 ChatGPT 能否调用 API。两个平台都可以。关键在于，哪一个能让普通用户理解、治理并可靠使用外部能力。

一个协议仍产生两种设置体验

MCP 减少了重复的集成代码，但并未消除安全连接周围的运营步骤。

对于 Claude，基本路径位于“设置”和“连接器”。用户添加自定义连接器，提供远程服务器地址，并在服务器要求时完成身份验证。工作场所所有者可能需要先启用或配置连接器。

Anthropic 的服务器文档引导构建者参考该协议的授权规范和官方 SDK 示例，并指出支持当前的远程授权模式。

对于 ChatGPT，路径则位于“应用”和高级设置。用户或管理员启用开发者访问权限，创建应用，输入远程 MCP URL，选择身份验证方式，并接受与自定义服务器相关的警告。

Business 工作区管理员可以为其工作区创建和部署应用。Enterprise 和 Edu 环境则为开发者与用户增加基于角色的控制。这些规则使连接成为组织治理的一部分，而不只是个人配置。

共同的技术核心是远程 MCP 端点。现代远程服务器通常使用 Streamable HTTP，这是一种通过 HTTP 请求和流式响应承载 MCP 消息的传输方式。该端点必须支持兼容客户端预期的初始化和工具发现交互。

MCP 消息使用 JSON-RPC 2.0，这是一种用于请求、结果、通知和错误的结构化格式。该协议规定客户端如何发现并调用工具，但不定义每个工具背后的底层业务逻辑。

以私人研究服务器为例。它可能提供一个用于搜索存储文档的工具，以及另一个用于检索完整记录的工具。Claude 和 ChatGPT 都可以从同一端点发现这些定义。

开发者仍必须决定谁可以搜索哪些记录。这个决定应属于服务器及其授权层。在某个客户端界面中隐藏工具，不能替代在数据源处强制执行访问控制。

当服务器处理用户专属数据时，OAuth 变得至关重要。客户端引导用户完成授权流程，获取访问令牌，并在调用受保护的 MCP 服务器时提交该令牌。服务器随后会在返回数据前验证令牌。

MCP 的授权规范要求兼容的 HTTP 授权部署提供受保护资源元数据。该元数据告诉客户端授权服务位于何处，并支持发现机制，无需硬编码每一种客户端—服务器配对。

这正是快速验证转变为真正工程项目的地方。服务器需要稳定的 HTTPS 地址、正确的元数据、重定向处理、令牌验证和合适的作用域。授权失败时，它还需要提供客户端能够理解的错误信息。

客户端注册可能带来另一项兼容性问题。一些系统支持动态注册或客户端元数据文档；另一些则要求预先创建客户端标识符。围绕某一种假设设计的服务器，可能需要调整后才能让两款聊天产品顺利完成身份验证。

实际实施应从范围狭窄的只读工具开始。例如，团队可以通过一个搜索功能公开经批准的项目笔记。用户可以要求任一助手查找此前的决策，而无需获得更新或删除权限。

这一使用场景也自然连接到个人或团队知识库。MCP 可以提供访问层，而底层系统仍负责索引、权限、保留策略和来源质量。

在读取路径运行正常后，开发者可以添加更精确的操作。每个写入工具都应有明确用途和有限范围。“更新一个任务状态”比“执行任意项目操作”更容易审查。

工具描述应像 API 合约一样受到同等重视。模型在决定是否调用函数时会看到这些描述。模糊的名称会增加错误选择、重复调用或不必要数据访问的可能性。

输入模式也应拒绝歧义。修改账户的工具应要求提供稳定的账户标识符，而不应只依赖可能匹配多条记录的客户名称。

响应应返回足够的结构化信息，让模型能够解释发生了什么。写入工具可以包含已变更对象、其先前状态和新状态。这有助于宿主呈现有意义的确认信息。

测试必须覆盖的不只是成功调用。开发者还应测试过期令牌、已撤销权限、不可用依赖、格式错误的输入，以及访问其他用户记录的尝试。这两个宿主对这些故障的呈现方式可能不同。

这也解释了为何尽管协议开放，添加自定义服务器仍可能耗时很长。MCP 消除了某一类集成重复工作，但并未消除部署、身份管理、安全审查、产品配置或质量保证工作。

真正的权衡在于可移植性与信任

让一台服务器能够连接多个助手的开放性，也使该服务器在用户、模型和敏感系统之间拥有特权位置。

自定义 MCP 服务器可以看到通过其工具发送的输入。它可能返回被模型当作上下文的内容。如果它提供操作能力，也可能以用户身份修改外部数据。

这种组合形成了多道信任边界。用户必须信任聊天服务提供商、MCP 服务器运营者、已连接服务以及授权实现。组织还必须信任那些引导模型行为的描述。

提示注入是一项主要风险。恶意指令可能嵌入在工具检索的数据中，例如文档、支持工单或网页。模型可能将这些内容理解为指令，而非不受信任的材料。

当有多个工具可用时，风险会进一步增加。检索到的内容可能试图说服模型使用敏感参数调用另一个工具。因此，一次读取操作可能成为非预期写入序列的起始步骤。

Anthropic 和 OpenAI 都警告用户只能连接受信任的服务器。这一建议很有必要，但信任并不是完整的安全控制措施。即使是善意的服务器，也可能存在授权错误或权限范围过宽的操作。

服务器必须独立验证每一项请求。它绝不应因为调用由 Claude 或 ChatGPT 生成，就假定调用是安全的。宿主确认可以帮助用户，但无法替代服务器端访问检查。

令牌处理需要格外谨慎。MCP 规范禁止令牌直通，即服务器将原本面向一个服务的令牌转发给另一个服务。令牌应具有明确的受众，接收服务器应验证该受众。

最小权限原则提供了最清晰的起点。研究连接器应先请求读取权限，再请求写入权限。日历工具若只需列出可用时间，就不应请求删除权限。

写入操作也应采用狭窄的语义。名为 delete_everything 的工具显然很危险，但宽泛的管理功能也可能在更友好的名称背后隐藏类似风险。每项操作都应对应一个可审查的用户意图。

高影响操作应支持幂等性，以防止意外重复导致多次变更。模型可能在响应不明确后重试。若缺少保障措施，一项请求的任务可能创建重复记录或消息。

审计日志同样重要。运营者需要知道哪个用户授权了调用、运行了哪个工具、哪个对象发生变化，以及宿主是否报告了确认。日志应避免保留不必要的提示内容或秘密信息。

服务器运营者应将面向用户的数据与控制指令分离。工具结果可以清晰标记不受信任的文本，并在可能时返回结构化字段。模型仍容易受到操纵，但精心设计的输出可以减少歧义。

宿主平台也面临尚未解决的问题。其批准提示必须提供足够信息，让用户理解某项操作。若工具可执行多种操作，笼统地请求“允许工具访问”几乎无法提供保护。

工具行为可能在连接后发生变化。Anthropic 明确指出，服务器开发者可能在不发出警告的情况下修改工具。用户今天批准了一个无害的搜索连接器，之后可能会从同一端点遇到更广泛的功能。

版本控制和审查可以降低这一风险。组织可以固定部署版本、监控模式变更，并在工具获得写入权限时要求再次审查。公共服务器运营者可以发布更新日志，并保持权限范围稳定。

数据流动还涉及隐私问题。一家公司可能允许其助手搜索内部记录，却禁止这些记录流向另一个处理方。MCP 服务器的托管地点和保留政策会成为决策的一部分。

因此，安全部署需要的不只是有效连接。团队应记录数据类别、允许的操作、身份验证范围、保留规则、事件联系人和撤销流程，还应测试每个宿主如何报告工具使用情况。

anthropic simon 演示证明跨平台连接是可行的。它并不能证明每台可连接服务器都适合生产环境。兼容性只是评估的起点，而非终点。

这一差异对于希望让偏好的助手访问私有笔记或项目历史的知识工作者尤其重要。连接器可以减少在工具之间复制内容的需要，也可能扩大敏感上下文传输的路径。

评估这一权衡的团队，应从那些即使在受控访问下暴露也能承受的信息开始。一个可搜索、包含经批准工程文档的集合，比通往所有内部系统的不受限制网关更安全。

随后，他们可以衡量助手是否找到正确来源、是否遵守权限，以及是否清晰解释工具使用情况。扩展应基于证据，而不是仅仅因为存在 MCP 端点。

Anthropic Simon 实验揭示了接下来应关注什么

MCP 的下一项考验，是跨平台服务器能否成为常规产品，而非通过高级设置拼装的专业集成。

第一个信号是围绕远程授权的趋同。Claude 和 ChatGPT 都需要在不为每种配对进行自定义注册工作的情况下安全连接用户。如果一项符合标准的 OAuth 部署能在两者之间可靠运行，采用范围将进一步扩大。

如果授权仍充满客户端特有的例外情况，可移植性的主张就会减弱。开发者仍可复用服务器的部分组件，但仍需维护单独的设置说明、元数据和故障排查路径。

最有力的证据将来自普通服务：它们发布一个远程端点，并为多个助手提供经过验证的说明。这些服务不应要求用户将长期 API 密钥粘贴到聊天设置中。基于浏览器的同意流程应授予范围狭窄、可撤销的权限。

第二个信号是 OpenAI 如何扩大完整 MCP 访问权限。当前文档将托管式工作场所账户的完整支持，与功能更有限的 Pro 能力区分开来。更广泛的个人使用路径将对 Claude 的自定义连接器体验形成直接压力。

如果继续强调管理员部署，则意味着另一种策略。ChatGPT apps 将主要充当受治理的工作场所软件，而 Claude 可能保留更直接的个人实验路径。

两种路线都不必然更好。企业通常需要审批、可审计性和角色控制。独立开发者则看重从已部署服务器到可用对话的短路径。

第三个信号是两个平台如何处理写入操作。搜索和检索能够形成有用的演示，但操作能力决定 MCP 是否会成为真正的应用层，同时也带来最棘手的安全和界面问题。

应关注更清晰的权限摘要、操作预览、确认策略和审计记录。能够充分解释外部影响的宿主，可以让写入工具更易用，而无需假装它们没有风险。

开发者还应关注宿主是否提供更好的诊断信息。连接失败通常会将多种可能原因归结为一个错误。问题可能涉及传输协商、授权元数据、重定向配置、令牌受众或工具模式验证。

更好的诊断信息将缩短从可运行的本地服务器到可靠远程集成的路径，也会减少服务器运营者逆向推断不同宿主预期的压力。

注册表和发现系统代表了另一重要层面。开放协议并不能告诉用户哪些服务器值得信任。经过策展的目录可以提供帮助，但也会给平台所有者增加一个控制点。

一台被某个宿主收录的服务器，在另一个宿主中可能仍只能作为手动自定义连接。即使实现具备可移植性，开发者仍会面临分发问题。审查周期和收录规则可能成为竞争差异化因素。

因此，用户应区分服务器兼容性与服务器可用性。一项服务可以在技术上同时适用于 Claude 和 ChatGPT，但仍可能难以发现，或受到工作区策略限制。

同样的区别也适用于界面支持。MCP Apps 可以在兼容宿主中返回交互式界面，而基础工具服务器主要交换结构化数据和文本。尽管使用相同的底层协议，不同支持级别仍会让某项集成显得更丰富。

对于构建者而言，眼下的策略应保持谨慎：托管符合标准的远程服务器，从一个范围狭窄的读取工具开始，并在两种产品中测试完全相同的提示。记录身份验证、发现、调用和错误处理上的每一项差异。

接下来，在明确授权后引入一项受限的写入操作。确认重试不会重复产生变更，并且撤销机制有效。仔细审查每个平台在操作执行前显示的内容。

对于组织而言，决策应从工作流出发，而不是出于对 MCP 的热情。找出一项重复性任务：基于聊天的访问能切实减少切换工具或搜索的成本。然后定义完成该任务所需的最小数据和操作范围。

一个合适的候选场景可能是搜索经批准的技术文档并返回来源链接。另一个可能是起草项目更新而不发布。两者都能创造价值，同时让最终变更仍处于人工控制之下。

“anthropic simon”这一搜索短语很可能会吸引正在寻找 Simon Willison 具体实验的读者。它的长期价值则远不止于搭建步骤本身。这项测试揭示了协议标准化的边界，以及平台政策开始发挥作用的位置。

MCP 已跨越一个重要门槛，进入 Claude 和 ChatGPT 的标准接口。接下来的问题是：连接一台可信服务器，能否变得平淡无奇、可预测，并且对普通用户清晰可见。

开发者现在就能帮助回答这个问题。选择一个低风险工作流，构建一个权限范围严格受限的远程端点，并在相同的测试提示下比较两个宿主。差异将表明，MCP 是否正在实现切实的可移植性，还是仅仅提供了一个共享的技术基础。