ChatGPT MCP 服务器托管将部署引入 Sites，但访问权限仍是边界

ChatGPT 现已支持 ChatGPT MCP 服务器工作流，可通过 Sites 构建、托管和部署工具，无需单独的托管服务商。这一变化消除了围绕模型上下文协议（Model Context Protocol，MCP）的最大实际障碍之一；该协议可让 AI 客户端通过统一接口调用外部工具。

Tibo Thibault 于 2026 年 10 月 1 日发布的一则公开帖子重点介绍了该功能。OpenAI 当前的文档确认了这一底层工作流。用户可以要求 ChatGPT 或 Codex 将 MCP 服务器添加至 Site、发布该 Site，并安装生成的插件。

这使得该公告的意义远超又一次网站构建器更新。此前，典型的 ChatGPT MCP 服务器需要代码、可从互联网访问的端点、部署基础设施，以及单独的连接流程。Sites 将其中多个步骤整合进同一对话式环境。

因此，真正的竞争并非 ChatGPT 与另一款模型之间的竞争，而是托管式、提示词驱动部署与传统自托管 MCP 路径之间的竞争。OpenAI 缩短了从想法到已安装工具的路径，但权限、测试和分发仍决定工具是否真正有用。

ChatGPT MCP 服务器托管带来了什么变化

ChatGPT Sites 现在既可作为应用界面，也可作为通过插件使用的 MCP 工具托管平台。

ChatGPT Sites 是 OpenAI 用于构建和发布交互式网站及轻量应用的环境。用户描述所需内容，审阅生成的预览，请求修改，并将结果部署到 Site URL。

新增的关键能力，是向该 Site 添加服务端工具。OpenAI 的Sites 指南称，用户可以要求 ChatGPT 或 Codex 为新的或现有的 Site 添加 MCP 服务器。他们必须说明这些工具可读取的信息，以及可进行的更改。

MCP 是一项用于向兼容 AI 客户端公开工具和数据的协议。服务器会描述可用操作、其输入及输出。随后，当用户提出相关请求时，ChatGPT 即可调用这些操作。

例如，Site 所有者可以创建项目仪表盘，再添加用于读取里程碑和更新其状态的工具。发布该 Site 后，将创建一个关联插件，在受支持的 ChatGPT 和 Codex 对话中公开这些工具。

这一流程压缩了此前彼此独立的多项工作：

• 用户在对话中定义所需工作流。

• ChatGPT 或 Codex 构建 Site 及其 MCP 工具。

• 所有者审阅 Site 并测试其行为。

• 发布会生成上线的 Site 及其关联插件。

• 用户安装并连接该插件。

• ChatGPT 可在后续对话中调用其工具。

Site 不只是静态界面。它可以承载信息、呈现交互式视图，并提供通过 MCP 公开的操作。OpenAI 的示例描述了一个团队手册，其中包含用于搜索和访问其内容的工具。

这种模式同样适用于项目跟踪器、内部目录、发布日历、文档查找器和运营仪表盘。只要其数据和权限经过审慎设计，团队还可将这种方式与可搜索知识库结合。

所有者必须先发布 Site，关联插件才会出现。添加或更改工具后，也需要再次发布，这些变更才会生效。已保存的草稿不会悄然修改上线插件。

OpenAI 将 Sites 称为公开测试版。它面向 ChatGPT 工作区、Plus 账户和 Pro 账户开放，但功能可能不会同时覆盖每一个账户。工作区管理员可以控制创建和发布权限。

部署 URL 是生产环境 URL。OpenAI 建议创作者在部署前保存版本并审阅改动。这一区别至关重要，因为对话式编辑可能让人感觉随意，但最终生成的软件可能已有真实用户。

结果是部署路径显著缩短。它并未消除软件运维工作，而是将其中许多环节迁移至托管产品和对话式工作流之中。

为什么提示词驱动部署会给自托管路径带来压力

对于许多规模较小的工作流，Sites 将 MCP 部署从基础设施项目转变为产品配置任务。

传统的远程 MCP 部署仍需要一个可正常运行、且 ChatGPT 能通过公共互联网访问的服务器。开发者必须实现工具、公开 HTTPS 端点、配置身份验证，并维持服务可用。

OpenAI 的MCP 快速入门展示了这一路径。开发者安装 MCP 软件开发工具包，创建服务器，公开 /mcp 端点，并通过 ChatGPT 的开发者控件连接公共 URL。

当团队需要自定义基础设施、复杂集成、独立扩展能力或对运行环境的控制时，这仍是合适的路径。它也让开发者能够直接掌控部署计划、日志、网络和数据存储。

然而，许多内部工具并非从这些需求起步。它们往往始于范围狭窄的请求，例如搜索手册、更新里程碑或检索项目记录。基础设施工作可能超过第一版的功能范围。

ChatGPT Sites 正是瞄准这一缺口。用户可以描述 Site、其数据以及 ChatGPT 应执行的操作。随后，Codex 可以生成所需的工具层，并将其连接至可安装插件。

这并不意味着工程知识不再重要，而是改变了这些知识何时变得必要。

第一版可以通过引导式构建产生，而无需手工搭建部署技术栈。工程关注点可转向工具边界、授权、错误处理和数据质量。

这正是核心反转。MCP 的设计初衷是标准化连接，但运行服务器仍会为那些只想要聚焦工作流的人带来阻力。OpenAI 现在正利用托管主机来降低这一运维负担。

这种压力首先会落在轻量级托管模式和内部原型上。开发者可能不再需要单独的云项目，只为测试一个包含三项工具的工作流是否解决了真实问题。

这种压力也会波及无代码和低代码 AI 构建平台。ChatGPT 现在在同一账户环境中连接了对话式定义、应用生成、托管和插件安装。这缩短了原型与可用 ChatGPT 工具之间的距离。

不过，自托管仍保留显著优势。托管 Site 并不会自动提供每个生产系统所需的部署灵活性、可观测性、可移植性或容量。

OpenAI 还会在公开测试期间实施按套餐划分的使用限制。这些限制覆盖一个账户下的 Sites，可能影响创建 Sites、添加存储空间或让繁忙的 Site 持续公开可用的能力。

文档建议用户查看其账户中显示的限制，但并未提供一项适用于所有人的固定容量标准。

这种不确定性使得“Sites 取代传统 MCP 托管”的简单结论难以成立。相反，它为规模较小或尚处早期阶段的部署提供了托管式默认选项。

开发者应将这两条路径视为不同的运维承诺：

• Site 托管工具优先考虑速度、集成式部署和引导式工作流。

• 自托管工具优先考虑基础设施控制、自定义架构和独立运维。

• Site 托管插件继承 OpenAI 账户和工作区控制。

• 自托管服务器仍须遵循 ChatGPT 的连接、授权和审查要求。

对许多团队而言，选择将更多取决于治理，而不是代码生成。构建 MCP 工具正变得更容易；决定谁能调用它，仍是更困难的产品决策。

Site 如何成为可安装插件

该工作流会将已发布 Site 与插件关联，但安装与授权仍是彼此独立的步骤。

OpenAI 的托管指南描述了具体流程。创作者从自己拥有的 Site 开始，要求 ChatGPT 或 Codex 添加 MCP 工具，对其进行审阅，然后发布 Site。

MCP 设置完成后，ChatGPT 会展示与该 Site 关联的插件卡片。创作者可以审阅该卡片，选择 Install，并完成连接流程。

之后，已安装的插件可以在受支持的 ChatGPT 或 Codex 对话中被提及。当其符合用户请求时，ChatGPT 也可能选择已安装的插件。

这一打包步骤很重要，因为原始 MCP 端点和可分发的 ChatGPT 使用体验并不完全相同。插件提供了一个可识别的单元，用户可以安装、查找、选择和管理它。

插件可包含技能、已连接应用、由 MCP 支持的工具和交互式扩展。Site 托管的 MCP 应用会成为这一更广泛打包系统中的一个组成部分。

当前插件目录可在 ChatGPT 网页端、桌面端和移动端使用。不过，OpenAI 警告称，具体能力可能因使用界面、账户、地区、套餐、角色和工作区配置而异。

这一限定很重要。插件出现在目录中，并不保证其中包含的每项工具或视图在所有环境中的运行方式都完全一致。

本地 MCP 应用就说明了这种区别。OpenAI 表示，本地应用可以通过 ChatGPT Desktop 上的插件运行。将该插件保存至账户，并不会让其本地工具在网页端或移动端可用。

Site 托管通过提供远程运行环境来解决这一限制。即便如此，插件的具体界面支持仍取决于其包含的能力以及当前产品可用性。

关联 Site 也有自己的访问模型。接收者可能需要查看 Site 的权限、使用插件的权限，以及访问任何已连接服务的授权。

安装插件不会绕过这些层级。仅共享 Site 并不会共享插件，而共享插件也不会授予无关数据的访问权限。

这种分离避免了一种看似简单却很危险的假设：工具可被安装，并不代表它能读取其创作者可以读取的一切内容。

每位用户可能都需要连接符合条件的账户。当 Site 访问已连接应用时，访问者会使用自己的连接和既有权限。

以连接至问题跟踪器的项目仪表盘为例。该 Site 可以显示已分配的问题，并公开更新操作。接收者应只能看到其问题跟踪器账户被允许查看的记录。

同样的原则也适用于文档存储库、客户记录和内部手册。Site 提供界面和托管工具，但底层服务仍然是授权边界。

这一模式为个人和工作区工具提供了更实用的路径。但当访问失败时，它也带来了多层次的排障难题。

工具调用失败可能源于 Site、插件连接、工作区角色、底层应用程序，或用户的服务商账户。创作者需要分别测试每一层。

因此，安装体验代表了真实的产品进展，但并不意味着可在所有环境中通用移植。OpenAI 统一了构建与打包流程，同时保留了不同的安全域。

权限才是产品边界

新工作流最强大的特性，也是它最大的风险：通过对话生成的工具可以执行真实操作。

创作者必须决定每个工具是只能读取信息，还是也可以修改信息。搜索操作和更新操作或许会并列出现，但它们带来的运行后果并不相同。

OpenAI 要求创作者在分享访问权限前审查 Site 内容和工具行为。它特别要求创作者考虑：用户应当只能读取数据，还是也应执行写入操作。

写入权限可能包括更改里程碑、创建记录、发送信息或更新已存储内容。这些操作需要比生成式界面所暗示的更严格审查。

精致的 Site 预览并不能证明其访问规则正确，也不能证明每项输入都会触发预期的服务器操作。

创作者应测试具有代表性的记录、权限级别、缺失数据、无效输入和被拒绝的操作。工具完成更改后，还应通过打开 Site 来验证结果。

企业控制机制又增加了一层保障。OpenAI 表示，多项插件权限可独立管理，包括使用插件、上传插件、通过 MCP 创建插件、分享插件，以及将其发布到工作区目录。

部分权限在 Enterprise 环境中默认禁用。管理员可能需要先为相关角色启用权限，创作者才能发布 Site 或分享其插件。

这种设计限制了意外分发，但也可能使不同账户之间的功能表现不一致。一位用户可能能立即构建并安装工具，另一位用户则可能看不到所需的控制选项。

公开访问需要更加谨慎。最初的社交媒体说法暗示，创作者可以将工具限制给指定人员，或向全世界公开分享。官方文档支持受控的工作区分享，以及单独的公开提交路径。

它并未说明个人插件分享可以普遍公开。目前，Pro 和个人账户用户无法通过分享链接，直接邀请其他 ChatGPT 用户使用托管在 Site 上的插件。

Business 和 Enterprise 成员可在工作区权限限制下与同事分享。接收者必须同时获得插件和其 Site 的访问权限，然后自行安装并连接。

公开目录分发遵循另一套流程。开发者需要提交插件接受审核，满足身份和权限要求，并且只有在获批后才能发布。

OpenAI 的审核要求要求远程提交提供真实、可公开访问的 MCP 端点。审核可检查工具架构、安全方案、注释、用户数据处理方式和预期行为。

审核指南还区分只读、破坏性和开放世界操作。这些分类会影响审核人员对工具行为及其风险的理解。

一个工具不会仅仅因为描述称其无害，就变成只读工具。其声明的注释与实际行为必须一致。

这一标准对 Site 生成的工具与手动编写的服务器同样重要。自然语言创建可以降低实现工作量，却无法替代准确的安全模型。

最大尚未解决的问题是：普通创作者能否可靠地识别不安全的工具边界。开发者知道，一个看似很小的更新函数也可能触发下游系统，或暴露敏感字段。

技术背景较弱的用户可能更关注工作流是否可用，而不会检查多余的响应字段、间接副作用或不一致的授权规则。

OpenAI 的托管工作流可以提供防护措施，但文档仍将测试责任交给创作者。它要求所有者审查工具、测试样例数据，并在分享前检查结果。

这使治理成为真正的采用约束。一个有用的工具既需要明确的能力，也需要经得起审查的权限边界。

ChatGPT MCP Server 使用场景应从小处着手

最佳的早期使用场景，是数据边界清晰、操作可逆、用户能够检查结果的窄范围工作流。

团队手册是 OpenAI 最明确的示例。Site 可以呈现手册内容，而 MCP 工具让 ChatGPT 能在对话中搜索其内容并检索相关章节。

该场景拥有明确的语料范围和相对简单的输出。创作者可以将 ChatGPT 的回答与底层 Site 对照，识别缺失或错误的信息。

项目仪表盘提供了第二种模式。读取工具可以获取里程碑、负责人、阻碍因素或截止日期。受控的写入工具则可以在用户确认后更新里程碑状态。

这一工作流提供了可见的验证方式。用户可以重新打开仪表盘，确认所请求的记录是否已正确更改。

文档查找工具也是另一个实用起点。Site 可以提供搜索已批准文件夹、返回匹配标题，以及打开当前用户有权访问记录的工具。

当这些工具与良好的信息组织结合时会更有价值。个人或团队的知识工作流仍依赖准确的源材料、稳定的权限以及清晰的检索边界。

内部目录、发布日历和状态报告也适合这一模式。每一种都可以采用小型工具集，搭配受限输入和易于理解的输出。

高风险工作流则需要更加谨慎。发送消息、删除记录、发布内容、更改权限或启动外部任务的工具，可能在 Site 之外产生后果。

这类操作应公开清晰的参数，并要求适当确认。创作者应避免在一个早期原型中同时组合广泛的数据访问权限和广泛的写入权限。

Site 还应展示足够的状态，让用户能够验证结果。对话中的确认并不足以证明外部操作已正确完成。

这正是 ChatGPT MCP server 托管与传统网站生成器不同之处。其产出不仅是内容或界面代码，它还可能成为未来对话中的一个实际参与者。

这会形成复合效应。安装后，只要 ChatGPT 判断该插件相关，或用户直接提及它时，插件便可能被选中。

因此，元数据十分重要。工具名称和描述应清楚说明预期范围。含糊的描述可能导致选错工具，或鼓励不合适的请求。

托管环境也改变了迭代方式。创作者可以请求 ChatGPT 或 Codex 添加新工具、修改现有操作，或变更 Site 的界面。

这些变更不会自动上线。所有者必须再次发布 Site，然后确认插件暴露的是预期版本的工具。

这一发布要求形成了有用的检查点。团队可以在变更后的能力触达用户前进行审查。

但它也可能造成版本混乱。Site 草稿、已发布 Site 和已安装插件未必始终反映相同的预期行为。

团队应维护简明的发布说明、命名测试用例，并为每个工具指定负责人。即使是小型内部插件，也应清楚用户当前调用的是哪个版本。

因此，最好的首个项目并不是构想中最包罗万象的助手，而是一个聚焦的工作流，其所有者能清楚回答四个问题：

• 工具可以读取哪些信息？

• 工具可以修改什么？

• 谁可以调用它？

• 用户如何验证结果？

如果这些答案仍然模糊，那么更快的部署只会更早地将不确定性带入生产环境。

三个信号将揭示 Sites 是否改变 MCP 的采用情况

下一项考验不在于生成了多少个 Sites，而在于有多少托管工具能成为受信任、可重复的工作流。

第一个信号是跨平台可靠性。OpenAI 表示，插件目录可在网页、桌面端和移动端使用，但具体功能可能因平台而异。

应关注 Site 托管的工具是否能在每个受支持客户端上保持一致行为。一致的安装、授权、工具选择和输出，将强化 Sites 作为通用 MCP 部署层的价值主张。

持续存在的平台差异则会削弱这一主张。创作者仍需为桌面端、网页端和移动端用户分别设计不同预期。

第二个信号是工作区采用情况。Business 和 Enterprise 环境提供受控分享，但管理员掌控所需权限。

应关注组织是否会为广泛的员工群体启用 Site 创建、MCP 插件创建和工作区分享。开发团队以外的采用，将表明对话式部署解决了真实的运营需求。

限制性的默认策略则会产生相反结果。如果安全团队无法自信地审计生成的操作和已连接的数据，Sites 可能仍只是原型工具。

第三个信号是公开插件质量。私有分发与公开发布是不同路径，目录提交还包括正式审核。

应关注由 Site 支持的插件是否能从个人实验成长为获批的公开产品。它们的可靠性、隐私披露、支持实践和用户满意度，将在真实需求下检验这一托管模式。

稳定的获批工具管线将强化 OpenAI 的说法：Sites 不仅能支持内部演示。反复出现的权限失败或不明确的工具行为，则会暴露提示词驱动部署的局限。

因此，剩余的不确定性是实践性的，而非概念性的。OpenAI 已记录构建、托管、发布、安装和分享工作流。该机制是真实存在的。

尚未得到验证的是，它能否在众多创作者之间妥善应对持续流量、复杂授权、运营调试和长期维护。

对开发者而言，眼下应立即针对一个边界明确的工作流，与传统自托管路径进行对比测试。比较设置时间、权限清晰度、错误诊断、更新控制和客户端覆盖范围。

对企业采购方而言，优先事项是治理。审查哪些角色可以创建工具、谁批准写入操作、已连接账户如何运作，以及用户在变更后会获得哪些证据。

对知识工作者而言，机会很直接。一个有用的内部仪表盘或参考资料集合，现在可以成为对话式工具，而无需先启动独立的基础设施项目。

ChatGPT MCP server 的转变之所以重要，是因为部署正更接近请求本身。决定性问题在于，团队能否让访问、测试和所有权同样保持紧密。选择一个窄范围工作流，在构建前定义其边界，并让拥有不同权限的用户参与测试。这些证据将揭示 Sites 只是更快的托管方式，还是创建 AI 工具的一条持久新路径。