Repository navigation
SEP-3118: App-Rendered Elicitations for MCP Apps - #3118
krubenok wants to merge 3 commits into
Conversation
Sorry, something went wrong.
|
Following the MCP Apps working-group discussion, the concrete follow-up is now available:
The draft keeps this within the existing io.modelcontextprotocol/ui extension. App rendering is negotiated through its nested elicitation capability alongside core elicitation.form; the app resolves the unchanged standard elicitation/create request with a standard ElicitResult. It does not add a second extension, method, result type, or retry mechanism. |
Sorry, something went wrong.
|
The coordinated public references are now aligned to protocol revision 2026-07-28:
The primary flow uses request-scoped client capabilities, server capabilities from server/discover, and the core MRTR shape: the server embeds the ordinary elicitation/create request in InputRequiredResult; the host validates the App's standard ElicitResult, places it under the matching inputResponses key, and retries the originating request with requestState. No second extension, custom method, or custom result type is introduced. The Inspector is pinned to ext-apps commit 89ab2bc. The MCP Apps View↔Host bridge independently negotiates Apps protocol version 2026-01-26; that is separate from core MCP 2026-07-28. The references are generic and contain no product-specific example details. |
Sorry, something went wrong.
| same underlying app resource. | ||
|
|
||
| The app's response action (`accept`, `decline`, or `cancel`) retains its core elicitation meaning. | ||
| The app **MUST NOT** directly retry the server operation or bypass the host's response handling. |
There was a problem hiding this comment.
MAY the app do app-initiated tool calls unrelated to the elicitation request?
Sorry, something went wrong.
There was a problem hiding this comment.
Oh this is interesting! I would need to think about this a little more since it's plausible that we get into a case of continued nesting of tool call triggers an MCP App which triggers an MCP App + Elicitation which can side-trigger another MCP Tool (potentially with it's own Elicitation or MCP App) 😵
My initial thought is that we should keep it simple and say no to this up front?
Sorry, something went wrong.
This branch has not been deployed
Reviewers
1 more reviewerAt least 1 approving review is required to merge this pull request.
Motivation and context
This SEP proposes app-rendered form elicitations as an additive capability of the existing io.modelcontextprotocol/ui extension.
The proposal preserves a complete core form elicitation as the interoperable fallback and adds explicit ui.resourceUri routing for capable hosts. The primary flow is protocol revision 2026-07-28:
Legacy initialized sessions use the same capability objects in the initialize exchange and may deliver the same semantic elicitation as a direct server-to-client request. No second extension, app-specific method, or custom result type is introduced.
Reference implementations:
Normative MCP Apps draft: modelcontextprotocol/ext-apps#733
Related discussion:
Sponsor requested from the MCP Apps Working Group.
AI assistance disclosure: This proposal was developed with substantial assistance from OpenAI Codex. I directed the design, reviewed the proposal and reference implementations, and validated the behavior.
Validation
Breaking changes
None. The proposal is additive and preserves native core form elicitation as the fallback.
Types of changes
Checklist