# OpenAI MCP Extensions adds a ChatGPT surface area to MCP servers > OpenAI MCP Extensions is a specification and a pair of SDKs that give Model Context Protocol servers places to appear inside ChatGPT, from a sidebar entry point to custom file viewers and composer mentions. It suits teams shipping an MCP server who want it to feel like a first-party feature, and it ties your plugin to ChatGPT. **openai/mcp-extensions** — Build plugins that feel like native, first-class features of ChatGPT. - Repository: https://github.com/openai/mcp-extensions - Stars: 1,127 · Forks: 53 - Language: TypeScript - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/openai-mcp-extensions ## MCP plus a ChatGPT-specific layer OpenAI MCP Extensions adds ChatGPT-specific capabilities to MCP so developers can build plugins that feel like native, first-class features. The wording is careful, and the two halves of it describe two different things. MCP is the protocol, and it gives a model a way to call tools. What this repository adds is a set of extensions on top of that, each of which maps a surface in the ChatGPT interface to something an MCP server can provide. The README summarises the whole project as a spec plus SDKs, and the documentation layout matches that: docs/spec.md lists all supported extensions, docs/patterns.md covers best practices, and CHANGELOG.md lists API changes. The supported surfaces are the substance of the project. A sidebar entry point lets users open your app from the sidebar. A file extension entry point renders a custom file viewer when a user opens a supported file type. Composer mentions let users search your plugin's resources from the composer and add references to a message. An extended form, described in the docs as form elicitation, lets users select from thumbnail choices rather than typing. That last one is the most interesting, because it moves the interaction from free text to a structured picker. The example in the demo is a CAD part selected through a form with thumbnail choices, and the file viewer example opens a CAD file in a custom viewer. A file viewer is a capability most MCP servers simply do not have a way to express, since the protocol is about tools and results, not about how a document is displayed. So the value proposition is not that MCP was insufficient. It is that MCP has no opinion about the user interface, and a plugin that wants a first-class interface needs somewhere to hang it. ## Two SDKs, and what each one covers The get started section names two packages and, importantly, says which is which. For TypeScript there is @openai/mcp-extensions, and the description says it is for MCP servers and Apps. For Python there is openai-mcp-extensions, and the description says it is for MCP servers. So the two SDKs are not symmetrical, and the Apps part of the TypeScript package has no Python counterpart in the current state of the repository. That gap is consistent with the release history. The recent releases are python-v0.2.0 and node-v0.2.0, both on 2026-10-10, and a marketplace-latest tag from 2026-09-29. The two SDKs shipped on the same day at the same version, and the naming with the language prefix in the tag suggests the two packages are released independently from one repository rather than as a single versioned artifact. The workspace layout shows how the pieces fit. The root is a private package called mcp-extensions-workspace, with typescript and python directories holding the two SDKs, a plugins directory holding the example, docs for the specification and patterns, and resources for the images used in the README. The plugins directory is where the Bits & Bolts source lives, and the README points at it as the place to see how the extensions are integrated in practice. The root package manifest is a pnpm workspace with pnpm@11.19.0 pinned and Node 22 or newer required, and the scripts show the shape of the build. A recursive build across the workspace, prettier for formatting, eslint for linting with zero warnings allowed, and separate type-checking steps for the SDK and for the example plugin: ```json "build": "pnpm -r build", "format": "prettier --check .", "lint": "eslint . --max-warnings 0", "types": "pnpm --filter @openai/mcp-extensions types", "plugins:types": "pnpm --filter bits-and-bolts typecheck", ``` There is also a package check step, run through publint, which is the tool that checks whether a package's published files and metadata are correct. A check script runs format, lint, types, build, plugin types and the package check in sequence, so the whole thing is verifiable with one command. ## The demo is the fastest way to see what an extension is The README offers a three-step demonstration before it offers any documentation, and for once that ordering is right. Install Bits & Bolts Remote from the ChatGPT plugins catalogue, select the Bits & Bolts icon in the sidebar to open the Parts Library, and open the Extensions walkthrough to explore a demo of each major extension. Each demo entry links into the corresponding section of the spec, and each is illustrated with a screen recording: opening an MCP App from the sidebar, opening a CAD file in a custom file viewer, searching for a CAD part with composer mentions, and selecting a CAD part in a form with an image picker. The reason this works as an introduction is that the extensions are visual. A spec document can define what a composer mention is in prose, but seeing a search box that reaches into your plugin's resource catalogue and drops a reference into a message is what makes the feature concrete. The walkthrough is a guided tour of exactly those interactions. One thing the demo makes obvious is that these extensions assume a user interface with a composer, a sidebar and a notion of opening a file. That is not a criticism, it is the scope. These entry points are defined against the ChatGPT product surface, and a server that implements them gets nothing extra in a client that does not. The plugin is called Bits & Bolts, and it is a CAD parts catalogue, which is a good choice for a reference implementation. It has a resource collection to mention, files to view, and a form with a finite set of choices, so it exercises every extension type rather than only the easy one. ## The route to a working plugin runs through an agent The first get started step is unusual for a developer SDK README, and it is worth reading as a statement about where the project thinks it is in its life. The instruction is to ask @Plugin Creator in Codex to build a new plugin or improve an existing one. In other words, the intended first user of this project is not writing the plugin by hand against the specification, but generating it with an agent that has been told how the extensions work. The remaining steps are more conventional. Install the SDK, choosing the TypeScript package for MCP servers and Apps or the Python package for MCP servers. Then learn more, through four pointers: the spec document for the list of supported extensions, the patterns document for best practices, the changelog for API changes, and the Bits & Bolts source for a worked integration. The feedback step closes the loop. The README asks for gaps, that is, extension points a plugin author needed and did not find, through a GitHub issue form. For a specification, that request list is the roadmap, and the fact that the project asks for it explicitly says where the value is being placed. The agents directory at the top level, alongside AGENTS.md, is consistent with that approach. A repository whose main entry point is an agent conversation keeps instructions for agents in the tree, and the .github directory holds the workflows. ## What is versioned, and what is still moving The maintenance picture has two parts, and they look different. The repository is not archived, and the last push was on 2026-10-10, the same day as the two SDK releases. The release line itself is young: node v0.2.0 and python v0.2.0, both dated 2026-10-10, and a marketplace-latest tag from 2026-09-29. A version 0.2.0 with a 0.x number is the signal to read carefully. The README itself points at CHANGELOG.md for API changes, which is a document you consult before every upgrade rather than occasionally. The package is pre-1.0, so breaking changes are still considered acceptable, and the two SDKs are versioned separately from one another even though they shipped on the same day, so a dependency that pins one does not pin the other. The release tooling in the repository is worth noting too. There is a release-please-manifest.json and a release-please-config.json at the top level, which means the versions and the changelog are produced by release automation from conventional commits rather than typed by hand. That is a good sign for consistency between the two packages, and it also means the changelog entries are generated from commit messages, so the quality of the history is the quality of the changelog. For an adopter, the practical consequence is that the spec and the SDKs will move, and the Bits & Bolts plugin in the same repository is the fastest indicator of what the current recommended shape of an integration looks like. ## Licence terms, and the security question the repo asks itself The licence is the Apache License 2.0, with the terms in the LICENSE file at the root. For a plugin SDK that a company will build on, that is the permissive choice with an express patent grant, and it raises no copyleft obligation on anything you ship. The repository also carries a SECURITY.md at the top level. For an SDK that runs inside a product surface and can render custom views of files, a security policy is not a formality, and having one is a reasonable expectation of a project asking plugin authors to handle user-given content. The other file that deserves a mention is the .agents directory and the AGENTS.md at the root, both of which tie back to the Plugin Creator workflow. A project that wants agents to write its plugins is implicitly asking for its conventions to be machine-readable, and a repository that keeps those instructions in version control is treating them as part of the product rather than as scratch notes. One limit is worth stating for anyone choosing this route. The extensions described here are ChatGPT surfaces, and the SDK binds you to that product's UI vocabulary: a sidebar, a composer, a file viewer, a form. A team that wants its MCP server to feel first-class in several clients is looking at a different problem, and this repository does not address it. What it does is make one particular client good to integrate with, which is a real and useful thing, provided it is the client you want. ## Conclusion OpenAI MCP Extensions suits a team that already ships an MCP server and wants it reachable from inside ChatGPT, with a sidebar entry point, a custom file viewer or composer mentions rather than a bare tool list. It is the wrong tool for a server meant to be used from many clients equally, because these entry points are ChatGPT-specific and do nothing for a client that does not implement them, and the wrong tool for a team that cannot accept a dependency on ChatGPT as a distribution channel. Before you adopt it, read docs/spec.md for the full list of supported extensions, follow docs/patterns.md for how they are meant to be used, and treat CHANGELOG.md as required reading, because the packages are still on version 0.2.0 and the API is moving. ## FAQ ### What is OpenAI MCP Extensions? It is a specification and a set of SDKs that add ChatGPT-specific capabilities to MCP, so a plugin built on the Model Context Protocol can appear in ChatGPT as a sidebar entry point, a custom file viewer, a composer mention or a form with thumbnail choices. ### Which packages do I need to install? For TypeScript there is @openai/mcp-extensions, described as covering MCP servers and Apps, and for Python there is openai-mcp-extensions, described as covering MCP servers. The two are versioned separately and were both released at version 0.2.0 on 2026-10-10. ### Where can I see the extensions in action? The README describes installing the Bits & Bolts Remote plugin in ChatGPT, opening the Bits & Bolts icon in the sidebar for the Parts Library, and opening the Extensions walkthrough for a demo of each major extension. ### Where are the supported extensions and their best practices documented? docs/spec.md lists all supported extensions, docs/patterns.md covers best practices, CHANGELOG.md lists API changes, and the Bits & Bolts source in the plugins directory shows the extensions integrated in practice. ## Sources - [Issues](https://github.com/openai/mcp-extensions/issues) - [License: Apache-2.0](https://github.com/openai/mcp-extensions/blob/main/LICENSE) - [openai/mcp-extensions on GitHub](https://github.com/openai/mcp-extensions) - [README](https://github.com/openai/mcp-extensions/blob/main/README.md) - [Releases](https://github.com/openai/mcp-extensions/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openai-mcp-extensions