OpenAI 开源 MCP Extensions：让 MCP 服务器拥有 ChatGPT 的原生插件能力-无双技术网

MCP 已经成了给大模型接工具的事实标准，但一个现实是：同一套 MCP 服务器，在 Claude 里和在 ChatGPT 里，能做的事并不一样。MCP 协议本身给的是「通用能力」——工具调用、资源、提示词；而侧边栏入口、文件查看器、聊天框里的 @ 引用、和宿主界面一致的样式，这些让插件「像原生功能一样」的东西，协议里并没有。

9 月 29 日，openai/mcp-extensions 开源了。它要解决的正是这一段差距：在 MCP 之上定义了一组 ChatGPT 专属扩展，并配上 TypeScript 和 Python 两套官方 SDK。项目用 Apache-2.0 许可，建仓一天就冲到 460 多星，是今天 GitHub 上最值得看的新项目之一。

有意思的是，这套东西其实和 Codex 的插件体系是同一套底层。换言之，你现在照着它写一个 MCP 服务器，同一份代码可以走 ChatGPT，也可以走 Codex。

ChatGPT 侧边栏里的 Bits & Bolts 插件：一个 CAD 零件库，左侧是全局导航图标，主区域是 36 个零件的三维预览卡片 — 官方示例插件 Bits & Bolts：一个跑在 ChatGPT 侧边栏里的 CAD 零件库。注意左侧那排图标——那就是扩展定义的「全局入口」。

它到底扩展了什么

官方 spec 写得非常清楚，一共大约十项扩展。挑最关键的几类说：

MCP App 入口（entrypoints）：正常情况下 MCP App 只能由模型调用。扩展允许你声明静态入口，让用户直接从界面打开。一共三种：Global（侧边栏全局导航）、Thread（会话内的内容标签页）、File（按文件后缀命中的查看器）。每个 MCP App 最多定义三个。
文件扩展名处理：你注册一个 file 类型入口并声明 extensions: [".csv", ".tsv"]，用户在任何会话里点开这类文件，就直接进你的查看器。
输入框 @ 引用（Composer mentions）：让用户在聊天框输入 @ 时搜索你插件里的资源，并把它作为引用加进消息。
OpenAI 表单（form elicitation）：在标准 elicitation 之上做扩展，支持缩略图选项、文件选择器、建议值等——本质是「让模型向用户要输入」这件事有了更好看的 UI。
结构化设置：插件在 ChatGPT 设置里有自己的一页，用结构化 schema 描述，而不是丢一段自由文本。
深度链接：桌面端 codex://、移动端 chatgpt://，可以直接把用户送到插件里的某个具体页面。

此外还有资源显示模式（inline / fullscreen）、模型上下文注入、本地文件打开与文件系统访问等。官方给了一张平台支持矩阵，很值得注意：文件入口、@ 引用、本地文件访问这类能力，在桌面端支持，但在 Web 和移动端是被标为「不支持」的。也就是说，你设计插件时必须考虑「同一功能在不同宿主上缺失」这件事，SDK 里对应字段在初始化完成前是 undefined，初始化后如果宿主不支持，仍可能保持 undefined。

写起来是什么样

两套 SDK 分别对应 npm 上的 @openai/mcp-extensions 和 PyPI 上的 openai-mcp-extensions。设计上它不另起炉灶，而是包装官方的 @modelcontextprotocol/sdk 和 @modelcontextprotocol/ext-apps，所以你原有的 MCP 代码基本不用动。

服务端是这样接入的：

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { OpenAIExtensions } from "@openai/mcp-extensions/server";

const server = new McpServer({ name: "my-server", version: "1.0.0" });
const openaiExtensions = new OpenAIExtensions(server);

然后在注册工具时，用 _meta 声明入口。比如下面这段，同时给一个工具挂了「全局入口 + 文件入口 + 设置入口」三种身份：

registerAppTool(server, "table.open", {
  icons: [{ src: "https://example.com/table.svg", mimeType: "image/svg+xml" }],
  _meta: {
    ui: { resourceUri: TABLE_URI, visibility: ["app"] },
    "openai/ui": {
      entrypoints: [
        { type: "global" },
        { type: "file", extensions: [".csv", ".tsv"] },
        { type: "settings", searchTerms: ["tables", "spreadsheet"] },
      ],
    },
  },
});

App 端则要包一层，并且要注意一个顺序问题——官方特意强调：必须在 app.connect() 之前注册 ontoolresult，用初次返回的结果来渲染，而不是连上后再回头调一次工具。后者会拖慢渲染并造成可见的闪烁。这类细节正是「像不像原生」的分水岭。

ChatGPT 会话里的文件查看器：右侧标签页显示一个 CAD/STL 模型的三维预览 — 文件入口的实际效果：用户点开一个 STL，插件在自己的 3D 查看器里渲染它，而不是丢给系统。

Bits & Bolts：一个能直接装的完整示例

光有 SDK 说明不了问题，所以官方附带了一个完整的示例插件 Bits & Bolts——一个 ChatGPT 里的 CAD 零件库。它把上面所有扩展都真用了一遍，而且可以直接从 ChatGPT 插件目录装上试用。

这个示例的工程含金量比想象中高。它是一个 pnpm monorepo：typescript/ 和 python/ 是两套 SDK 本体，plugins/bits-and-bolts/ 是示例，docs/spec.md 和 docs/publishing.md 是规范和发布流程。示例插件本身用 Vite + React 构建，前面提到的那 36 个零件不是贴图——仓库里躺着几十个 .glb 和 .stl 三维模型文件，由 build-models.py 和 Three.js 渲染器实时画出来，连键帽的网格（meshes）都单独用 JSON 描述。

ChatGPT 设置页里的 Bits & Bolts 一页：包含单位、默认视角、参考网格开关等结构化设置项 — 结构化设置：插件在 ChatGPT 设置里有专属一页，选项由 schema 描述，而不是一段说明文字。

发布链路也一起开源了

真正让我觉得这个仓库「认真」的，是 docs/publishing.md。它把两个包怎么独立发版讲得明明白白：Python 和 Node 版本号相互独立、各自一个 release PR；用 release-please 维护版本与 changelog；PyPI 和 npm 都走 OIDC 可信发布，不需要长期 token。

细节也抠到了：只有上传任务拿到 id-token: write；发布前强制校验 release tag 指向的正是被检出的 commit、且该 commit 在 main 上；仓库变量 RELEASE_PLEASE_ENABLED、PUBLISH_PYPI_ENABLED、PUBLISH_NPM_ENABLED 默认全关，得手动一项项开。连「私有仓库不会让注册表产物变私有」「重建旧 tag 会主动关掉 npm provenance，以免对错误的 source commit 背书」这种事都写进了文档。