Skip to content

SEP-3118: App-Rendered Elicitations for MCP Apps - #3118

Open
krubenok wants to merge 3 commits into
modelcontextprotocol:mainfrom
krubenok:sep/app-rendered-elicitations
Open

SEP-3118: App-Rendered Elicitations for MCP Apps#3118
krubenok wants to merge 3 commits into
modelcontextprotocol:mainfrom
krubenok:sep/app-rendered-elicitations

Conversation

@krubenok

@krubenok krubenok commented Jul 23, 2026 •
edited
Loading

Copy link
Copy Markdown

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:

  • clients advertise the capability in request-scoped _meta["io.modelcontextprotocol/clientCapabilities"]
  • servers advertise it through server/discover
  • servers return the ordinary elicitation/create request inside an MRTR InputRequiredResult
  • hosts place the app's standard ElicitResult under the matching inputResponses key and retry with requestState

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

  • PUPPETEER_SKIP_DOWNLOAD=true npm_config_cache=/private/tmp/mcp-sep-mint-cache npm run prep
  • generated SEP documentation is current
  • schema, formatting, MDX-comment, SEP, and broken-link checks passed

Breaking changes

None. The proposal is additive and preserves native core form elicitation as the fallback.

Types of changes

  • Bug fix
  • New feature
  • Breaking change
  • Documentation update

Checklist

  • I have read the MCP documentation
  • The proposal follows repository style
  • Generated documentation is current
  • Relevant validation passes locally

@krubenok
krubenok requested review from a team as code owners July 23, 2026 05:02
@krubenok krubenok changed the title SEP-XXXX: App-Rendered Elicitations for MCP Apps SEP-3118: App-Rendered Elicitations for MCP Apps Jul 23, 2026
This was referenced Jul 23, 2026
Draft
Open
Open
@krubenok

krubenok commented Jul 29, 2026

Copy link
Copy Markdown
Author

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.

@krubenok

krubenok commented Jul 29, 2026 •
edited
Loading

Copy link
Copy Markdown
Author

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.

@krubenok krubenok mentioned this pull request Jul 29, 2026
Draft
This was referenced Jul 29, 2026
Draft
Open
dylanclark
dylanclark reviewed Jul 30, 2026
View reviewed changes
Comment thread docs/seps/3118-app-rendered-elicitations.mdx
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.

@dylanclark dylanclark Jul 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MAY the app do app-initiated tool calls unrelated to the elicitation request?

@krubenok krubenok Jul 30, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer
@dylanclark dylanclark dylanclark left review comments
Reviewers whose approvals may not affect merge requirements

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@krubenok @dylanclark