Simon Willison 在一篇标注为 2026 年 7 月 29 日的实践记录中，分别尝试把自定义 MCP 服务器接入 Claude 和 ChatGPT。结论不复杂：两款产品的标准网页聊天界面都能连接，但入口不直观，配置也要经过多步操作。

这不是 Anthropic 或 OpenAI 的正式产品发布，而是一篇个人实测笔记。它说明 MCP 已经从开发工具和 API 场景进入日常聊天产品，但现阶段更适合知道服务器、认证和权限意味着什么的开发者。普通用户看到“支持 MCP”，很容易误以为点一下就能调用外部工具，实际并非如此。

Claude 和 ChatGPT 已经开放入口，体验却不能画等号

MCP 全称 Model Context Protocol，由 Anthropic 在 2024 年 11 月公开。它试图用一套通用协议，让模型连接外部工具和数据源，例如代码仓库、文档系统、数据库或企业内部服务。

过去，这类连接通常要为不同模型和应用分别开发插件或接口。MCP 想解决的是重复适配问题，思路近似软件世界里的通用接口标准：服务器按协议暴露能力，支持 MCP 的客户端负责发现和调用。

Willison 的记录提供了一个具体变化：Claude 和 ChatGPT 的标准聊天界面已经能够连接用户自建的 MCP 服务器。用户不必只在专用开发工具里调用这些能力。不过，从现有线索能确认的是“两边都能接”和“配置并不省事”，不能据此认定两款产品的入口、认证方式、工具支持范围完全相同。

对比项ClaudeChatGPT
使用场景标准网页聊天界面标准网页聊天界面
自定义 MCPWillison 的实践显示可以接入Willison 的实践显示可以接入
配置体验入口不够直观，需要多步设置入口不够直观，需要多步设置
能否认定功能对等不能不能
用户仍需处理服务器部署、认证、权限和维护服务器部署、认证、权限和维护

原始摘要没有列出两款产品的完整菜单路径，也没有交代账户、套餐、地区、传输方式和认证机制。因此，这些细节不能靠推测补齐。准备接入的团队仍要对照各自账户中的实际入口和官方文档，而不能把一篇 TIL 当成长期有效的配置手册。

日期也应保留一层核验。来源标注为 2026 年 7 月 29 日；如果读者在这一日期之前看到转载或存档页面，应检查页面时间、时区或预定发布状态，避免把未来日期误写成已经发生的正式发布。

支持协议不等于交付完整产品

MCP 的价值取决于两件事：客户端是否容易配置，服务器是否值得信任。前者决定有多少人愿意尝试，后者决定企业敢不敢把真实数据交给它。

这也是 MCP 与早期 ChatGPT 插件热潮之间最值得保留的对照。插件强调用户在产品内安装现成能力，MCP 更偏向一套连接标准。标准可以降低开发者重复适配的成本，却不会自动完成服务器托管、身份认证、权限审批和安全审查。协议解决“怎么连”，没有替团队回答“该不该连”。

“工欲善其事，必先利其器。”这里的“器”并不只是模型。一个自定义 MCP 服务器至少涉及以下现实问题：

  • 服务器部署在哪里，故障后由谁处理；
  • 使用长期密钥、短期令牌还是其他认证方式；
  • 模型能读取哪些数据，又能执行哪些写入操作；
  • 请求和工具调用能否留痕，敏感信息是否会进入日志；
  • Claude 或 ChatGPT 的客户端更新后，原有连接是否仍然兼容。

聊天界面提供连接入口，不代表平台已经替第三方服务器背书。服务器一旦获得文档、工单或数据库权限，风险也不再局限于“模型答错了”，还包括越权读取、误操作和数据外泄。尤其是带有写入、删除、发送等动作的工具，权限范围应当比只读查询更窄。

开发者可以试接，企业应先算清维护账

独立开发者和小团队最容易从这项能力中受益。已有 MCP 服务时，可以用 Claude 和 ChatGPT 分别验证调用效果，不必先为每个平台重写一套集成。现实动作也很明确：先接只读、低敏感度的数据源，再比较两边的配置成本、调用稳定性和错误反馈。

企业技术负责人面对的是另一笔账。接入内部知识库看起来只是增加一个聊天入口，实际可能牵动身份系统、网络边界、审计记录和供应商管理。若服务器还要由团队自行托管，省下的接口开发时间，可能会转化为持续的运维和安全成本。

因此，是否接入不该只看演示能否跑通。至少要先回答三个问题：有没有明确的业务场景，权限能否缩到最小，出了问题能否追查。答不清时，继续使用受控的 API 集成或内部客户端，往往比直接开放到通用聊天界面更稳妥。

接下来真正需要观察的变量也很具体：两家公司会不会把入口放到更显眼的位置，能否统一认证与授权流程，能否提供更细的工具权限、审计记录和管理员控制。入口变浅只是易用性改进；安全责任能否被清楚划分，才决定 MCP 会停留在开发者试验，还是进入企业采购清单。