嗨，我是 Lena。开始留意这件事的时候，我其实并不是想找一个定论。我只是一直在看不同 AI client 怎么处理 tool 连接——但总觉得这件事没我原先以为的那么尘埃落定。
MCP 是什么，为什么大家会问 ChatGPT
很多搜索 "ChatGPT MCP servers" 的人，似乎都默认答案只会是简单的是或否。起初我也是这么想的。
Model Context Protocol（MCP）是 Anthropic 在 2024 年 11 月提出的开放标准，用来规范 AI system 与外部工具、系统和 data source 的集成与数据共享方式。它背后的想法——也是我真心觉得很值得观察的一点——有点像给 AI 准备的 USB-C 接口。与其让每个工具都配一根自己的专用线，不如用一种标准 protocol 把一切连起来。
MCP 标准，以及它是谁提出来的
这个 protocol 的起源故事出奇地务实：开发者 David Soria Parra 厌倦了总要在 Claude Desktop 和自己的 IDE 之间来回复制代码，于是这件事就从这种挫败感里长出来了。这个细节我一直记得。它并不是从宏大的基础设施叙事开始的，而是从一个人受够了那种细小、重复的摩擦开始的。
自从诞生以来，Anthropic 就一直在努力让 MCP 保持 open-source、community-driven、vendor-neutral。也正因为这种开放性，“ChatGPT 和 MCP” 这个问题才显得合理。如果它是一个通用标准，不是应该所有人都同样支持吗？
不过……事情从这里开始，就没那么简单了。
ChatGPT 支持 MCP Servers 吗？
嗯，这一段我其实困惑了挺久。
简短答案是：是的，ChatGPT 确实支持 MCP servers——但它究竟 怎么支持、又是 对谁开放，这件事已经变过好几次，而且还在继续演化。我现在也不敢说自己完全看清了。
OpenAI 的 MCP 支持现状
2025 年 3 月，OpenAI 正式在 Agents SDK、Responses API 和 ChatGPT desktop app 里采用了 MCP。那就是转折点。在那之前，ChatGPT 有自己的一套工具生态，MCP 并不在其中。
OpenAI 已经在 ChatGPT 中推出了完整的 MCP 支持，也带来了开发者期待已久的能力：可以直接在聊天里通过 custom connectors 执行 read 和 write 操作。 这个功能目前以 beta 的形式放在 Developer Mode 下，本质上是把 ChatGPT 变成一个可编排的 automation hub，让它能够与外部系统或内部 API 交互。
但——也是我注意到时觉得有点出乎意料的地方——不同 plan 的可用范围并不一样。
完整的 MCP 支持，包括 modify/write 操作，正在以 beta 形式向 ChatGPT Business、Enterprise 和 Edu plans 推出。Plus 或 Pro 的个人用户也可以在 Developer Mode 中连接 MCP servers，但 write/action 能力会更受限制。至于 ChatGPT Apps，截至 2025 年 11 月，Business、Enterprise 和 Education plans 也已经支持了。
还有一个命名变化值得注意。到了 2025 年 12 月 17 日，ChatGPT 把 "connectors" 改名成了 "apps"。现有功能并没有变，但现在的文档和产品 UI 都在用 "apps"。我当时得把好几页重新看一遍，才确认自己没有把术语搞混——确实花了点时间。
还有一点：ChatGPT 不能直接连接 localhost 上的 MCP servers。ChatGPT 没法直接连到你的 localhost 服务器——不过，用 ngrok 之类的服务做一个 tunnel 并不难。真要开始之前，最好先知道这个现实限制。
OpenAI 之前用的是什么：function calling 和 Custom GPTs
在 MCP 到来之前，OpenAI 已经有自己的一套 tool integration 方式。Function calling——也就是 OpenAI 最早那套方法——允许开发者为模型可调用的工具定义 JSON schema。它当然能用，但每一次集成都要单独配置。没有共享的 discovery layer，也没有标准化方式让一个工具自己声明它能做什么。
Custom GPTs 也能让用户配置 tool access，但它们仍然运行在 sandbox 里，提供不了 MCP server 连接那种同等级的 programmatic control。
差别倒不是说哪一种坏了。更像是，它们本来就在解决略微不同的问题。
ChatGPT 的 Tool Calling 和 MCP，到底差在哪？
说实话，我现在也还在把这件事一点点拼起来。
Function calling schema
OpenAI 的 function calling 要求开发者手动描述每一个工具——名字、参数、返回什么。模型读取这些描述，再决定什么时候调用哪个 function。它是 vendor-specific 的。如果你换了 client，就得重来。
MCP 的标准化 discovery layer
MCP 是一个 open-source 标准，用来把 AI application 连接到外部系统。通过 MCP，像 Claude 或 ChatGPT 这样的 AI application 可以接到 data source、tool 和 workflow——从而访问关键信息，并实际执行任务。
我注意到的关键行为差异是：用 MCP 时，tool discovery 是协议内建的一部分。 server 会主动声明自己能做什么，client 会接收这些信息并学会如何使用它。当一个使用 MCP 的 OpenAI application 收到用户请求时，整个流程会包括 tool discovery、context building、model decision-making、tool execution 和 result processing。这个循环在不同 client 之间是标准化的。
各自的得与失
用 function calling，你得到的是 fine-grained control，以及一套成熟、文档充分的 API。用 MCP，你得到的是 portability——server 写一次，理论上任何兼容的 client 都能用。像 Claude、ChatGPT 这样的 AI assistant，以及 Visual Studio Code、Cursor、MCPJam 等开发工具，现在都支持 MCP，这让“写一次、到处接入”变得更现实。
这种 portability 对你的具体场景到底有多重要……我不太确定。这大概只有你自己才知道。
如果你需要完整的 MCP 支持，还有哪些替代方案？
如果你碰到的是 plan 限制、localhost 限制，或者只是想看看 chatgpt mcp servers 在不同环境里到底是什么体验，那还有一些别的 client，对 MCP 的处理方式确实不太一样。
Claude / Claude Code
Claude 是最早原生支持 MCP 的 client。现在 Claude 已经有一个由 MCP 驱动、包含 75 多个 connectors 的目录，Anthropic 最近还在 API 中推出了 Tool Search 和 Programmatic Tool Calling，用来优化生产级 MCP 部署。Anthropic 的终端 coding agent——Claude Code——同样原生支持 MCP，本地 server 也包括在内，不需要再走 tunneling 的绕路方案。
你也可以阅读 Anthropic 官网的 MCP 官方文档，看看 tools、resources 和 prompts 是如何作为 primitives 被组织起来的。
Cursor
Cursor 是一个面向 coding 的 editor，它已经采用 MCP 来把 agent 连接到项目上下文、database 和开发工具。很多 agent builder 日常就是在这里工作的。相较于聊天界面，MCP 在这里给人的感觉更像是嵌进了开发 workflow 本身。
Cline
Cline 是一个 open-source 的 VS Code extension，能够运行带有 MCP 支持的 agent workflow。如果你想观察 MCP 在一个本地、可控的环境里到底怎么工作，它很值得关注——不过我会说，搭起来还是需要一点耐心。
Open-source 的 MCP 兼容 client
Model Context Protocol 现在已经是一个由 The Linux Foundation 托管的 open-source 项目，整个社区都可以参与贡献。MCP GitHub organization 已经提供了 Python、TypeScript、Ruby、C# 等多种 SDK。任何想自己构建 custom client 的人，都可以实现 MCP，而不必依赖某一个特定 vendor。
更大的图景：Connection 与 Evolution
有个念头我总会绕回来，但我也不确定自己是不是已经想明白了。
MCP 很擅长解决 connection 问题。server 写一次，让很多 client 都能用。这确实很有价值。MCP 已经成了把 AI system 连接到现实世界数据和工具的事实标准——OpenAI、Google DeepMind、Microsoft，以及成千上万正在构建 production agent 的开发者，都已经采用了它。
但只有 connection，并不意味着系统会从发生过的事情里学习。一个 agent 可以成功调用 tool，也可能把任务做砸，而下一次 session 开始时，它对这两件事都没有记忆。协议处理的是 interface；它并不处理系统会如何使用自己学到的东西。
我一直会注意到这道空隙。我还不确定最后是什么来填上它——但它看起来已经不像随机噪声了。
FAQ
1 ChatGPT 支持 MCP servers 吗？
是的。OpenAI 已经在 ChatGPT 中加入了完整的 MCP 支持，网页版的 Pro、Plus、Business、Enterprise 和 Education 账号都可以在 Developer Mode 的 beta 中使用。个人 plan 上的 write/modify 操作目前仍然更受限制。只能连 Remote servers——localhost 仍然需要 tunneling service。
2 ChatGPT plugins 和 MCP servers 有什么区别？
ChatGPT plugins（现已 deprecated）是一套封闭的、专属于 ChatGPT 的系统。MCP servers 则是开放、跨平台的标准。为 MCP 构建的 server，原则上可以与 Claude、Cursor 或其他兼容 client 一起工作，而不只是 ChatGPT。你可以查看 OpenAI 的 MCP 开发者文档，了解如何为 ChatGPT 专门构建合规 server。
3 我可以把 MCP 和 OpenAI API 一起用吗？
可以。OpenAI 在 2025 年 3 月对 MCP 的正式采用，覆盖了 Agents SDK、Responses API 和 ChatGPT desktop app。你也可以在 API Playground 里以编程方式配置 MCP servers。面向 enterprise 部署时，还可以结合 OpenAI Help Center 的 Developer Mode 文档 来确认哪些 write 权限需要 admin approval。
我会继续看这件事最后怎么落下来。术语还在变，plan 限制也还在更新，而当你说“支持 MCP”时，每个 client 实际到底跑了什么，也并不总是说得很清楚。先写到这里吧。
……这里面确实有什么在发生。只是现在还没有完全看清。
