AIREITERChatGPT MCP 服务器并不是能返回 /mcp 响应就算部署完成。ChatGPT 还必须能够访问服务器、发现正确的工具、完成用户认证，并在合适的场景下调用这些工具。对大多数团队来说，托管服务是更合理的默认选择；如果服务器必须留在私有基础设施中，则应考虑 Secure MCP Tunnel。
先确定部署边界，再开始写代码
部署边界会直接决定传输方式、认证工作量、运维负担，以及服务器能否对外发布。ChatGPT 是一个远程 MCP 客户端，不会像某些桌面客户端那样直接启动本地 stdio 进程（OpenAI 帮助中心）。
| 部署方式 | ChatGPT 连接方式 | 适用场景 | 主要代价 |
|---|---|---|---|
| 托管式公共部署 | 稳定的 HTTPS Streamable HTTP 端点 | 大多数团队应用和面向客户的应用 | 平台限制以及对供应商的依赖 |
| 自建公共端点 | 运行在容器、VM 或集群上的稳定 HTTPS 端点 | 已有平台团队，并且有合规或网络方面的要求 | 需要自行负责 TLS、扩缩容、补丁、回滚和监控 |
| Secure MCP Tunnel | 由 OpenAI 托管的端点中转到私有 stdio 或 HTTP 服务器 | 本地部署系统、私有网络和开发环境 | 健康运行的 tunnel-client 会成为可用性的一部分 |
默认优先选择托管服务：如果 MCP 服务器是无状态的、流量并不持续，而且团队还没有成熟可靠的公共应用平台，托管通常是最省事的方案。Vercel 的路由处理器模式和 Cloudflare 的无状态 Worker 模式，都能提供 ChatGPT 所需的稳定 HTTPS 端点；但在做决定前，务必确认各平台对请求时长、流式传输和状态管理的限制（Vercel、Cloudflare）。
在需要时自建公共端点：如果服务器必须靠近现有数据库、接入已经建立的身份基础设施、满足数据驻留要求，或者运行时间不适合无服务器模型的任务，那么自建更合适。但前提是团队已经具备密钥管理、部署回滚、告警机制，并且明确了负责值班的人员。
使用 Secure MCP Tunnel：如果开放公网入口并不是合适的安全边界，就应采用隧道方案。OpenAI 的隧道客户端会向 api.openai.com:443 发起出站 HTTPS 连接，再将请求转发给私有 HTTP 或 stdio 服务器，因此不需要监听入站互联网连接。OpenAI 的部署文档也明确指出，Secure MCP Tunnel 不满足公开提交所要求的稳定、可公开访问的 HTTPS 端点条件（OpenAI 隧道文档、OpenAI 构建指南）。
把本地工具推进到可生产使用的 ChatGPT MCP 服务器
可靠的 ChatGPT MCP 服务器部署，应该分别验证工具行为、协议行为、生产环境可达性和模型路由。通过其中一关，并不代表下一关也一定没问题。
1. 设计职责清晰、契约稳定的工具
从一个用户动作对应一个工具开始。OpenAI 的构建指南将 list_projects、get_project 和 update_project 拆成三个独立工具，而不是用一个工具承载互不相关的模式（OpenAI 开发者文档）。每个工具都需要具备面向动作的名称、准确的描述、明确的输入 Schema、有用的输出，以及真实可靠的安全标注。
只有在工具绝不会改变状态时，才能标记 readOnlyHint: true。对于不可逆或难以撤销的操作，应使用 destructiveHint: true；如果工具会访问开放范围的外部实体，则使用 openWorldHint: true。OpenAI 将这些标注定义为面向模型的元数据，用于工具行为和安全处理；但对于每个受保护请求，授权仍必须由服务器执行（OpenAI 开发者文档）。
如果后续调用可能需要更新同一条记录，就应在 structuredContent 中返回稳定的记录标识符。不要把令牌、密钥和不必要的个人数据放入 content、structuredContent 或 _meta；OpenAI 明确说明，_meta 对模型不可见，但它并不是安全存储。
2. 在本地提供 Streamable HTTP
ChatGPT 通常通过 Streamable HTTP 建立远程连接，常见路径是 /mcp。这个路径只是惯例，并非强制要求，但最终部署的完整 URL 必须填写到 ChatGPT 中（OpenAI 连接指南）。
先在本地运行服务器，然后启动 MCP Inspector：
npx @modelcontextprotocol/inspector@latest将 Inspector 连接到类似 http://localhost:3000/mcp 的 URL。确认初始化流程正常，列出所有工具，然后分别使用有效请求、无效 Schema、缺少标识符和空结果场景调用每个工具。对于受保护工具，还要确认缺少凭据或凭据权限不足时会安全失败。
3. 对外暴露前先做好生产级访问控制
公开健康检查接口，并不意味着应该公开整个工具面。如果工具只提供明确允许公开的只读数据，那么未认证端点可能可以接受。但涉及私有数据、用户专属数据或实际操作时，每个请求都必须完成认证和授权（OpenAI 构建指南）。
对于受 OAuth 保护的 MCP，服务器充当资源服务器。未认证请求应返回 401，并将客户端指向受保护资源元数据，通常位于 /.well-known/oauth-protected-resource。授权流程应使用 PKCE、范围尽可能窄的令牌、严格的 issuer 和 audience 校验；如果持久连接需要，还应支持刷新令牌（OpenAI 帮助中心）。
不要因为 MCP 令牌和上游服务都认识 bearer token，就把 MCP 访问令牌直接转发给上游服务。令牌的目标资源必须是实际接收它的服务；调用下游服务时，应使用服务凭据或适当的令牌交换方案（MCP 部署安全指南）。
4. 部署不可变的候选版本
将通过 Inspector 验证的同一个构建版本部署到预览或 staging 端点，再把这个制品提升到生产环境。生产端点必须使用 HTTPS、保留完整的 MCP 路径、能够访问所需依赖，并将密钥放在托管平台的密钥存储中。
如果采用精简的 Vercel 参考方案，请安装 mcp-handler、@modelcontextprotocol/server 和 zod；将返回的 Web Handler 挂载到 app/api/mcp/route.ts；为 GET 和 POST 导出它；然后执行以下命令部署：
npx vercel deploy --prod此时，ChatGPT 的连接 URL 形式为 https://your-project.vercel.app/api/mcp。Vercel 文档显示，在启用 Fluid compute 时，函数默认时长为 300 秒，符合条件的付费配置还可以获得更高上限。因此，对于可能超过单次请求生命周期的工作，应改造成可恢复的任务，而不是让空闲流一直保持打开（Vercel 部署指南）。除非所选运行时提供了明确的共享状态设计，否则应让路由保持无状态。
连接 ChatGPT 前，先补齐以下四项运维控制：
- 为高成本工具设置请求超时和速率限制。
- 记录初始化失败和工具调用失败，但不要记录令牌或敏感结果。
- 为每次调用记录发布标识符，确保故障能够对应到具体部署代码。
- 为工具 Schema 或授权回归问题准备经过测试的回滚路径。
不要只针对 localhost 运行 MCP Inspector，也要直接测试生产 URL。重新检查工具发现、Schema、标注、认证、有效调用和错误处理。即使应用在本地运行正常，负载均衡器、代理、CORS 规则或身份提供商重定向仍然可能导致失败。
用三层模型设计访问控制
ChatGPT MCP 的访问控制包含三个彼此独立的执行层；启用 OAuth 只能解决身份层的问题。
| 层级 | 执行位置 | 必须回答的问题 |
|---|---|---|
| 工作区访问 | ChatGPT 管理控制 | 谁可以创建、发布、启用或使用这个应用？ |
| 用户身份 | OAuth 授权服务器和 MCP 资源服务器 | 当前调用者是哪一个账户？令牌是否对本服务器有效？ |
| 资源与操作授权 | MCP 工具处理器和后端 | 该用户是否可以在这个租户、记录或环境中执行此操作？ |
在 ChatGPT Business 中，管理员或所有者负责控制开发者模式和发布权限。Enterprise 和 Edu 工作区还提供针对开发者访问、应用访问和操作权限的 RBAC（OpenAI 帮助中心）。这些控制只决定 ChatGPT 能否使用应用，并不能证明调用者有权在后端编辑客户 A 的记录。
MCP 处理器必须从经过验证的凭据中提取身份，并在每次调用时执行租户级和对象级授权。绝不能把模型生成参数中的用户 ID、组织 ID 或角色当作身份凭证。所有工具参数都应视为不可信输入。
将读权限和写权限分开。一个实际的策略可以是：广泛授予 projects:read，只向编辑者授予 projects:write，并在执行破坏性操作前重新进行一次服务端检查。ChatGPT 可能会针对重要操作请求确认，但确认只是用户体验层面的保护措施，不是授权控制。
提示注入同样属于访问控制问题。工具输出和检索到的文档中可能包含恶意指令，因此写入工具应只暴露最窄的必要操作，并在服务端校验允许写入的字段。一个万能的 execute_action 工具，会同时放大路由歧义和潜在影响范围。
在 ChatGPT 中连接、测试并发布应用
连接端点会创建一个草稿应用和一份元数据快照。发布则是把经过审核的配置提供给工作区使用；它与部署服务器代码不是同一个操作。
- 根据适用的 ChatGPT 工作区策略启用开发者模式。
- 打开应用创建流程，填写完整的 HTTPS MCP URL；如果挂载路由使用了
/mcp，也要包含它。 - 选择认证机制，并在需要时完成 OAuth。
- 运行 Scan Tools，检查所有发现的工具名称、Schema、标注和操作，然后创建草稿。
- 在发布到工作区之前，先在新的聊天中测试草稿。
对于私有服务器，请将连接方式选择为 Tunnel，然后选择关联的隧道，或填写其 tunnel_id。操作人员需要 OpenAI Platform Tunnels Read + Use 权限，而 ChatGPT 开发者模式仍然是另一项独立的工作区权限（OpenAI 隧道文档）。
元数据变更需要明确的生命周期管理。对于开发者模式连接，先部署或重启服务器，打开连接，选择 Refresh，确认变更后的元数据，然后开始新的对话。OpenAI 当前针对 Business 的指南指出，已发布应用若要修改工具或元数据，必须重新创建并发布；Enterprise/Edu 管理员可以刷新操作、查看差异并启用新操作，而新操作默认处于禁用状态（OpenAI 帮助中心）。
即便如此，保持向后兼容仍然是最稳妥的服务器策略。可以增加可选字段和新工具，但不要悄悄改变现有工具的含义。在所有已批准的快照和客户端完成迁移前，应继续保留旧 Schema。
测试 ChatGPT 用户真正会遇到的行为
协议测试只能证明服务器能够响应；ChatGPT 测试还必须证明模型会选择正确的工具、提供合适的参数、遵守边界，并在不相关时避开工具调用。
Reddit 用户 u/EmailNo8428 这样描述了这个双层问题：
“实际上，你同时在测试两件事：工具逻辑，以及特定客户端调用工具的方式。”（r/mcp）
建立一套小型、带版本管理的评测集，至少覆盖以下场景：
| 场景 | 预期结果 |
|---|---|
| 直接请求 | 使用有效参数选择用户明确点名的能力 |
| 间接请求 | 根据用户目标推断正确工具 |
| 后续请求 | 复用此前返回的稳定标识符 |
| 负向请求 | 不调用任何 MCP 工具 |
| 权限不足 | 返回有用的授权错误，且不泄露数据 |
| 写入请求 | 选择范围最窄的写入工具，并触发适用的确认流程 |
| 含糊请求 | 询问必要信息，而不是自行编造参数 |
| 空结果 | 返回有效的空状态，而不是传输错误或 Schema 错误 |
记录实际选中的工具、参数、返回结果、错误和确认行为。每当工具名称、描述、Schema、标注、认证规则或结果结构发生变化，都要重新执行受影响的用例；OpenAI 在连接指南中也要求采用同样的刷新和重新测试流程。
如果服务器能通过 Inspector，却在 ChatGPT 中经常选错工具，通常说明工具边界、描述或 Schema 还不够清晰。如果路由选择正确，却出现 401、超时或状态丢失，那么问题多半出在基础设施或授权逻辑上。把这两类问题分开诊断，能明显缩短修复周期。
常见问题
ChatGPT 能直接连接 localhost 或 stdio MCP 服务器吗？
不能。ChatGPT 通常连接远程 MCP 端点。OpenAI Secure MCP Tunnel 可以在不开放公网入口的情况下，将请求转发给私有 stdio 或 HTTP 服务器；临时 HTTPS 隧道可以用于开发，但不能用于公开插件提交。
ChatGPT MCP 服务器必须提供公共 HTTPS 端点吗？
普通远程连接和公开插件提交都要求稳定的 HTTPS。私有开发者模式服务器可以使用 Secure MCP Tunnel，让服务器继续留在客户控制的环境中。
必须实现 search 和 fetch 吗？
不需要。OpenAI 表示，连接的服务器已经不再强制要求这两个工具。如果应用需要参与企业知识库或深度研究检索场景，则应实现标准的 search 和 fetch 契约（OpenAI 帮助中心）。
服务器部署后，为什么 ChatGPT 仍然显示旧工具？
ChatGPT 保存的是已经发现的元数据，而不是把每次代码部署都视为已批准的工具变更。开发者模式连接需要执行刷新并开始新的对话；已发布的工作区应用则要遵循对应方案的审核和重新发布流程。