You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My current understanding of the ongoing effort of MCP Apps extension is to serve as the common standard shared by all clients:
This SEP [SEP-1865] addresses the current limitations through an optional, backwards-compatible extension that unifies the approaches pioneered by MCP-UI and the Apps SDK into a single, open standard.
However, as of today, there are still discrepancies between the current version of OpenAI Apps SDK and MCP Apps Extension. Some are just interface differences that can be unified under a common interface with some adaptors like the ones from MCP-UI or from Skybridge or even the draft #172). Some others simply can't be achieve with the existing tooling.
I tried listing those hereafter in order to have a better picture of the current situation with associated ongoing efforts on missing pieces. Feel free to let me know if something is missing.
Which of those will remain not implemented in ext-apps? Which should be discussed further to make their way in the final implementation before GA?
Pre-declared meta
On tool (tools/list operation)
Apps SDK
Ext Apps
Comment
_meta["securitySchemes"]
Deferred
_meta["openai/outputTemplate"]
_meta["ui"].resourceUri
Aligned ✅
_meta["openai/widgetAccessible"]
Deferred
_meta["openai/visibility"]
_meta["ui"].visibility
Aligned ✅
_meta["openai/toolInvocation/invoking"]
Deferred
_meta["openai/toolInvocation/invoked"]
Deferred
_meta["openai/fileParams"]
Deferred
On resource (resource/read operation)
Apps SDK
Ext Apps
Comment
_meta["openai/widgetDescription"]
Deferred
_meta["openai/widgetPrefersBorder"]
_meta["ui"].prefersBorder
Aligned ✅
_meta["openai/widgetCSP"]
_meta["ui"].csp
connect & resource domains included in both standards. frame and redirect only available in apps sdk. Will be added in #158
_meta["openai/widgetDomain"]
_meta["ui"].domain
Aligned ✅
Dynamic comms
Properties available in widget (Host -> UI)
Apps SDK
Ext Apps
Comment
window.openai.toolInput
ui/notifications/tool-input
Aligned ✅
window.openai.toolOutput
ui/notifications/tool-result
Aligned ✅
window.openai.toolResponseMetadata
ui/notifications/tool-result
Aligned ✅
_meta["openai/widgetSessionId"]
Deferred (sessions will likely be added in some form in the future)
Properties added by host on tool call (Host -> Server)
Apps SDK
Ext Apps
Comment
_meta["openai/userAgent"]
_meta["openai/locale"]
_meta["openai/userLocation"]
_meta["openai/subject"]
Methods (UI -> Host)
Apps SDK
Ext Apps
Comment
window.openai.setWidgetState(state)
Discussed in #61 and #62 as everything set in widget state is injected in model's context. To be clear, #62 will support writing to a shared mutable state with the model. All other related capabilities have been deferred
My current understanding of the ongoing effort of MCP Apps extension is to serve as the common standard shared by all clients:
From SEP-1865 initial message
However, as of today, there are still discrepancies between the current version of OpenAI Apps SDK and MCP Apps Extension. Some are just interface differences that can be unified under a common interface with some adaptors like the ones from MCP-UI or from Skybridge or even the draft #172). Some others simply can't be achieve with the existing tooling.
I tried listing those hereafter in order to have a better picture of the current situation with associated ongoing efforts on missing pieces. Feel free to let me know if something is missing.
Which of those will remain not implemented in ext-apps? Which should be discussed further to make their way in the final implementation before GA?
Pre-declared meta
On tool (tools/list operation)
On resource (resource/read operation)
Dynamic comms
Properties available in widget (Host -> UI)
Properties added by host on tool call (Host -> Server)
Methods (UI -> Host)
Others
_meta["mcp/www_authenticate"]sent by MCP server in the tools/call response as a challenge to trigger OAuthEdited on Jan 7th with @idosal comments