Pimp My IDE / adapter shop
Back to garage
October 3, 2026 | MCP / plugins / host compatibility

An extension is an adapter, not the socket.

OpenAI's MCP Extensions add sidebar apps, file viewers, settings, mentions, and richer forms to ChatGPT. The useful question is not whether they are MCP. It is where they fit, what they add, and what survives on another host.

Keep the standard MCP contract underneath. Negotiate every host feature. Give unsupported clients a plain tool, resource, or form path instead of a dead control.

MCP base connectorHost fit / rev 01
Check capability before contact

The new package is real.

OpenAI published @openai/mcp-extensions and openai-mcp-extensions at version 0.1.0. The repository defines TypeScript support for MCP servers and apps, plus Python support for servers.[1] This pass fetched the npm package, inspected its archive, and found the advertised server, app, form, mention, resource, settings, and UI modules.

The extensions can add global and thread entrypoints, desktop file handlers, structured settings, custom display modes, composer mentions, model-context attachments, local file opening, and richer elicitation forms.[2] That is a serious jump from a tool that exists only when the model decides to call it.

The host can give an MCP app a front door. The front door still belongs to that host.

Host fit is part of the interface contract.

The published support table is uneven by design. Global and thread entrypoints work across desktop, web, iOS, and Android. File entrypoints, local file opening, file resources, and composer mentions are desktop-only at launch. OpenAI form elicitation works on desktop and web, but not on either mobile platform.[2]

A plugin that depends on a desktop file viewer is not broken on mobile. It needs a fallback. Return a normal resource link. Offer a read-only summary. Ask the user to continue on desktop only when the job truly requires desktop file access.

Capability negotiation is the socket test.

The MCP lifecycle already requires clients and servers to exchange protocol versions and capabilities before normal operation. Both sides must use only the capabilities they negotiated.[3] Host extensions should follow the same discipline. Check the advertised extension before sending its method or metadata.

Do not infer support from a product name, a recent version, or a successful server connection. Record the protocol version, host, platform, requested extension, advertised capability, and fallback used. That turns a vague compatibility report into a reproducible one.

File editing needs a version brake.

File entrypoints receive an opaque resource URI instead of a raw path. Reads and subscriptions go through MCP resource methods. The OpenAI write extension accepts an optional ifMatch value and can return saved, conflict, or too-large.[2]

Use the ETag. A file viewer that writes without a version check can overwrite a newer edit. Keep the opaque URI in the app. Let the server handle any work that truly needs the filesystem path. Then log the pre-write version, result, and returned version without exposing the path.

Portability needs a deliberate floor.

  1. Define the job with standard MCP tools, resources, prompts, or elicitation when they can carry it.
  2. Add the host extension for a better entrypoint, viewer, picker, or display mode.
  3. Check support at runtime and choose one named fallback.
  4. Test every platform you claim to support.
  5. Save the negotiated capability and result in the release receipt.

The extension can make the experience feel native. The baseline keeps the job reachable when the custom socket is absent.

Interactive makeover / host-fit adapter rack

Test the socket before the feature.

Traditional purpose replaced: one compatibility badge. Better version: choose a platform, select required extensions, see unsupported combinations, and copy a test card with the fallback still open.

Host
Capability
Fallback
Receipt

Platform socket

Choose one ChatGPT platform from the published launch table.

Target platform

Extension loadout

Select the host-specific features your plugin requires. Support labels update from the source table.

Required extensions
1 requirement selected.Desktop supports the selected requirement in the published launch table. Runtime negotiation and host testing are still required.
A supported table cell is documentation, not runtime proof. The card stays open until the negotiated capability, fallback, and host result are attached.

Sources read

Source log, artifact check, and evidence boundary
  1. OpenAI, MCP Extensions repository, read October 3, 2026. The README names the TypeScript and Python packages, supported SDK roles, sample Bits & Bolts plugin, and Apache-2.0 license. The repository was created September 29, 2026.
  2. OpenAI, MCP Extensions specification, read October 3, 2026. It defines platform support, entrypoints, opaque file resources, writes and ETags, settings, display modes, messages, context attachments, mentions, and extended forms.
  3. Model Context Protocol specification, Lifecycle, read October 3, 2026. It requires version and capability negotiation during initialization and says both sides must use only negotiated capabilities during operation.
  4. OpenAI documentation, "Build plugins", read October 3, 2026. It defines a plugin as a reusable package containing apps, skills, or both. It also says included apps do not grant access beyond existing workspace, connection, and source-service permissions.

Artifact check. The npm registry reported @openai/mcp-extensions version 0.1.0. This pass downloaded its tarball, listed its server and app modules, and recorded SHA-256 929626b294096d535bafa70510b4effb402df778a136896669a8cbc8edc1e5af. PyPI also reported openai-mcp-extensions version 0.1.0 for Python 3.10 or newer.

Evidence boundary. This page did not install a ChatGPT plugin, connect an MCP server, or exercise the extensions on desktop, web, iOS, or Android. The support states come from OpenAI's launch table. The adapter rack creates a test-card structure, not a compatibility result.