mrkeyoor.com_
Fri 16 Oct 18:51 UTC
Dev Toolsevaluationupdated 16 Oct 2026

mcp-extensions review

OpenAI MCP Extensions adds ChatGPT-specific interface features to Model Context Protocol servers and apps. It lets a plugin open from a sidebar, handle supported files, or ask for structured input, so users can work with an app beyond a tool response in chat.

Verdict

Our MCP Extensions checkout installed 255 packages in 9 seconds and built in 8 seconds, but had no test target to run. Adopt it for a specific ChatGPT interaction you can validate in the intended host. Keep ordinary MCP behavior available where the extension is unsupported, and review the demo before copying its state handling.

We ran it

Lab card: what happened when we ran mcp-extensionsScreenshot of mcp-extensions (github.com/openai/mcp-extensions)
Install✓ · 9s255 packages · 222 MB
Build✓ · 8s
Testsn/ano test script
Repo308 files~15,197 lines of source · 109.6 MB · 3 CI workflows

Answers from our run

Does mcp-extensions build from source?

Dependencies installed in 9 seconds (255 packages), and the build succeeded in 8 seconds. We cloned commit 0d60621 into a clean Debian container with 3 CPUs and no project-specific setup.

Does mcp-extensions have tests you can run?

Not through a standard command: the project exposes no test script or target that our harness could run.

Who should not use mcp-extensions?

Developers promising the same experience in every MCP client: these extensions explicitly target ChatGPT.

What are the alternatives to mcp-extensions?

MCP TypeScript SDK, MCP Apps. Our MCP Extensions checkout installed 255 packages in 9 seconds and built in 8 seconds, but had no test target to run.

Setup4/59-second install and 8-second build; host setup remains separate
Docs4/5Spec, SDK examples, and patterns explain platform boundaries
Community4/5October release activity and detailed current integration reports
Maturity3/5Build passes; host behavior and API changes still need validation

Who it’s for

Plugin developers with an existing MCP server who need ChatGPT-specific interaction surfaces.
TypeScript teams building both server tools and an embedded app interface.
Python server authors who can pair backend extensions with a separately built app when needed.

Who it’s NOT for

Developers promising the same experience in every MCP client: these extensions explicitly target ChatGPT.
Mobile-first file editors: the specification lists file entrypoints as desktop-only.
Teams depending on composer mentions in a browser: official documentation says mentions are desktop-only.
Builders who assume the reference demo is ready to copy unchanged: issue 32 reports oversized model-facing results from embedded catalog previews.

Setup reality

Our sandbox installed commit 0d60621 in 9 seconds, adding 255 pnpm packages and using 222 MB. The build passed in 8 seconds. Tests were skipped because no test script or target was present. The checkout had 3 CI workflows and monorepo workspaces, but no Dockerfile or tests directory.

The TypeScript package extends MCP server and app SDKs. Python supports the server side. A usable plugin still needs your tools, any service credentials those tools require, app resources, and a supported ChatGPT connection. No universal API key can supply all of that.

Feature support varies by host and client version. The SDK documents separate server and app imports and compatibility requirements for forms. Our repository build did not exercise sidebar navigation, file editing, authentication, or the hosted demo.

ChatGPT-specific entrypoints justify the extra SDK

MCP Extensions lets a user open your app from ChatGPT's sidebar without waiting for the model to call a tool. The README also demonstrates file viewers, composer mentions, and richer forms through Bits & Bolts, a CAD-parts example. These features solve a concrete interface problem: a useful app often needs to stay open while a conversation continues. They make sense when your product needs that persistent surface inside ChatGPT.

Our checkout contained 308 files and about 15,197 source lines, with monorepo workspaces rather than a single sample script. The repository README points to separate TypeScript and Python SDKs, a protocol specification, and the demo source. The TypeScript side covers servers and app interfaces, while Python covers server extensions. You still build the product behavior and supply whatever services it calls. Installing this repository does not produce your finished plugin.

What happened when we ran it

Our sandbox installed commit 0d60621 in 9 seconds, adding 255 pnpm packages and occupying 222 MB. The build passed in 8 seconds on October 15, 2026. The run used a fresh Debian container with 3 CPUs, 8 GB of RAM, Node 22, no secrets, and no elevated privileges. That is a straightforward repository build result, with no measured host-interaction result attached to it.

Tests were skipped because there was no test script or target. Our scan found 3 CI workflow files, no Dockerfile, and no tests directory. The 109.6 MB checkout and successful build establish that the workspace could be prepared in the sandbox. They do not establish that a form opens, a file saves, or the model sees the same app state as the user. No dependency vulnerability result was supplied for this run.

Desktop support does not imply mobile support

The extension specification's platform table lists file entrypoints as desktop-only. Its web column refers to the Work browser and describes expected launch support, so it needs to be read with that scope intact. A file editor built around those entrypoints should not promise the same workflow on a phone. Decide which client must support the feature before designing the screen around it.

The 8-second build tells us nothing about that distribution boundary. Official OpenAI documentation says composer mentions are available only in the ChatGPT desktop app and describes web availability as still rolling out to some plans. Capability checks belong in the product's behavior. A screenshot from the CAD demo cannot show whether your intended audience has the necessary client and access.

Server and app dependencies follow different paths

The TypeScript guide separates shared types, server imports, and app imports. Its server path uses MCP server SDK 2, while the app path documents its own MCP Apps dependencies. That is helpful specificity for a developer integrating an existing server. Follow the path matching the code you are writing, and keep the installed versions aligned with the examples. Mixing a server snippet into app code adds avoidable integration confusion.

Our 255-package installation was the repository workspace, not a measured minimum for every downstream plugin. The guide also distinguishes multi-round-trip forms from legacy requests according to the negotiated MCP protocol. If your plugin needs user input during a tool call, verify the whole interaction on the real connection. Importing the form helper successfully cannot tell you whether that host supports the required exchange.

Copy the demo's interaction ideas carefully

Issue 32 reports that Bits & Bolts returns a full catalog with inline image previews in model-facing structured content. The report describes output truncation and host persistence problems. These are reported demo behaviors, not findings from our sandbox. They matter because a reference app is easy to treat as an approved production pattern, especially when its interface already looks finished.

The project's patterns guide recommends sending selected content and high-level state through the appropriate context mechanisms, with server tools available for additional details. That is a useful basis for reviewing your own app. The model may need the selected part's identity without every image in the catalog. Keep the visual interface and the model's working context synchronized, then inspect the actual result sent through your host instead of assuming the SDK keeps it small.

October releases accompany unresolved host questions

The last push was October 10, 2026, and the latest release endpoint returned python-v0.2.0 from that day. GitHub listed 12 open issues and PRs. Recent reports ask about mobile navigation and reuse of app instances. Those discussions show active integration work while also identifying decisions the public API does not yet make obvious to users. A Python release tag should not be read as the version of every package in the workspace.

Use the base MCP TypeScript SDK when tools and resources already solve the job, or MCP Apps when you need the shared interactive layer. MCP Extensions earns its place when a particular ChatGPT entrypoint improves how someone uses your app. I would implement that interaction first, validate it on the target client, and expand only after navigation and state updates behave as the user expects.

Alternatives

ProjectWhat it isPick it when
MCP TypeScript SDK gh↗The underlying TypeScript SDK for general MCP servers and clients.pick this instead when ordinary tools and resources meet the requirement across hosts.
MCP AppsThe shared MCP app specification and SDK for interactive interfaces.pick this instead when you want the common app layer before adding ChatGPT-specific surfaces.

What people are saying

  1. [velocity-scout] openai/mcp-extensions

Sources

  1. MCP Extensions README
  2. Extension specification
  3. TypeScript guide
  4. Interaction patterns
  5. Oversized demo result report
  6. Official OpenAI extension guide
  7. Python release

More dev tools reviews

compose-samples · librepods · sqlmap · coucou · world-execute-me-dsh-pv · CarrierSIM · the whole board →