What happened
The openai/mcp-extensions changelog lists two releases. Version 0.2.0 is dated October 10, 2026 in the changelog. It adds editable chat drafts through ui/message metadata with send: false: an app can append content to the active draft or open a new editable draft using target: "new" on desktop and in the Work browser. This is a documented message behavior rather than a statement that every client or app automatically exposes it.
The same release adds multi-round-trip forms. These require both client capabilities, elicitation.form and extensions["openai/elicitation"].form. The form schema is placed in _meta["openai/elicitation"].requestedSchema, while the core requested schema is an empty object schema. The release adds TypeScript requestFormInput and Python request_form_input, also exposed as OpenAIExtensions.request_input in Python. In other words, an extension can describe a requested form through the OpenAI-specific metadata while retaining the core schema shape required by the protocol flow.
Version 0.2.0 also adds the openai/mentions server capability with a searchTool; the search tool must set the read-only annotation annotations.readOnlyHint: true. The older mentions-search metadata remains supported when the new capability is absent, but is deprecated. The TypeScript server helpers migrate to MCP SDK 2, importing McpServer from @modelcontextprotocol/server; shared schemas and types are exported from @openai/mcp-extensions. Existing server imports remain supported. The changelog also documents API replacements and removes the old app-transport and settings entry points.
The release keeps legacy forms available under renamed APIs rather than making the earlier names disappear immediately. TypeScript gains OpenAIExtensions.elicitInputLegacy, while Python gains OpenAIExtensions.elicit_input_legacy; elicitInput and elicit_input remain supported aliases but are deprecated. Both TypeScript methods now take (context, params, options?). For maintainers, this makes the release both a feature update and an inventory of APIs that should be reviewed before a future migration.
Version 0.2.1 documents named context groups, including a default Context group and group or individual-item removal. It adds documentation for active and new conversation message support on iOS and Android, with either send value, and resource search from connected hosted apps in the Work browser through openai/mentions. It clarifies that numeric form answers are JSON numbers; exact large integers or decimal text should use string fields, and desktop rejects integer input that would change during numeric conversion. Legacy form aliases are deprecated in favor of resource and thumbnail; Python aliases file_input and FileUserOptions are deprecated in favor of resource_input and UserResourceOptions.
What the archive adds
The archive has related coverage of OpenAI’s MCP integrations: OpenAI’s Codex CLI added enterprise MCP sign-in and ServiceNow’s MCP plugin entered the OpenAI marketplace. Those are separate developments; this is a new SDK release with interaction details, not a restatement of either event.
Trend signal
This update supports the pattern that agent protocols are becoming an interoperability layer: the changelog specifies capabilities and metadata that apps and clients must share to interoperate. The signal is limited to the documented OpenAI extensions, and does not establish broad adoption across MCP implementations.
Why now
The release sequence is recent: 0.2.0 is dated October 10, 2026, followed by 0.2.1, which the supplied release material dates October 21. The newer release adds clarifications and mobile and Work browser details on top of the earlier interaction capabilities.
Why it matters
For teams building MCP apps for ChatGPT, editable drafts and multi-step forms offer more controlled ways to collect information and prepare a response than a single tool call followed by a final send. The explicit client capability requirements matter operationally: a form implementation must check that both required capabilities are available rather than assume all clients support it.
The migration notes also affect maintenance. Developers need to distinguish numeric values from exact numeric text, update deprecated file-input aliases, and adapt TypeScript server helpers to MCP SDK 2. They may also need to replace removed transport or settings entry points. These changes can reduce ambiguity in app behavior, but they also create version and compatibility work. The release is most useful to teams already building or maintaining OpenAI MCP extensions, not a general change for every MCP user.
Limits and uncertainty
The changelog describes specification and SDK changes; it does not provide adoption numbers, user outcomes, performance measurements, or evidence that every ChatGPT client supports every capability. It does not state pricing or a change in access to ChatGPT or the extensions platform. The supplied material gives a date for 0.2.0 and dates 0.2.1 as October 21 in the release excerpt, but the changelog page itself labels the sections by version rather than repeating a date for 0.2.1. It also does not explain how client capability negotiation behaves beyond the listed requirements.
The material does not provide implementation examples, a migration deadline, or a compatibility matrix across desktop, mobile, and the Work browser. It therefore cannot establish whether a particular deployed extension needs immediate changes. The deprecations identify direction, but not the timetable for removal.
Skill to build now
Audit one existing MCP interaction this week: identify where it asks for several user values or produces text the user should revise before sending. Add a capability check for elicitation.form and extensions["openai/elicitation"].form, then decide whether the existing fallback remains necessary. Separately, search the codebase for deprecated file-input and legacy form aliases so the migration can be planned rather than discovered during a later SDK upgrade.
Reader takeaway
If you maintain an OpenAI MCP extension, treat 0.2.x as a functional and compatibility update: assess whether multi-round forms or editable drafts fit your flow, check client capabilities, and migrate deprecated aliases deliberately. The release documents new interaction surfaces, but does not show how widely they are available in deployed clients.