Add elicitation/create support to render custom Elicitation forms

[Avcharov]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Example

Call display-pdf w/o mandatory "url" parameter results in custom iframe with elicitation

Screen.Recording.2026-03-02.at.19.16.46.mov

Implementation details can be found in THIS BRANCH

Motivation

MCP servers can currently pause a tool call and request structured user input from the client via elicitation/create. This works well when the client is Claude Desktop or another host that renders its own native elicitation UI.

However, in the ext-apps model, the app running inside the iframe is better positioned to handle elicitation - it has domain-specific context and can render a purpose-built form instead of a generic dialog. For example, a PDF viewer app can show a URL input field with appropriate validation and placeholder text, rather than relying on the host's generic form renderer.

Today there's no way for a server's elicitation/create request to reach the app iframe.

Proposal

Add end-to-end plumbing so that elicitation/create flows from the server through the host and bridge into the app:

• App class — add an onelicitation setter that registers a handler for elicitation/create requests forwarded by the bridge

Hosts that want to support this would need to:

Declare elicitation: {} in client capabilities during initialize
Call AppBridge.setupElicitationForwarding(client) — this returns a setBridge callback that handles request buffering and forwarding automatically
Call setBridge(appBridge) after the app has completed ui/initialize

// In connectToServer():
const setBridge = AppBridge.setupElicitationForwarding(client);

// In initializeApp(), after ui/initialize completes:
setBridge(appBridge);

The helper encapsulates the timing gap between the server sending elicitation/create (which can happen immediately during tools/call execution) and the app iframe being ready to handle it.

Open questions

1. Should setupElicitationForwarding move into connect()? Currently it's a separate static method the host calls explicitly. We could integrate it into AppBridge.connect() to match how tools/resources/prompts are auto-forwarded — but those flow App→Server while elicitation flows Server→App, and the bridge-per-tool-call lifecycle makes automatic wiring harder.
2. Capability negotiation between app and bridge — the host has no way to know whether the app has registered an onelicitation handler. If it hasn't, the request will hang until the app's side times out. Should AppBridge advertise elicitation support as part of ui/initialize?
3. Fallback behavior — if the app doesn't handle elicitation, should the host fall back to its own native UI, or return { action: "decline" }?
4. Multiple elicitations per tool call — the current implementation supports sequential elicitations within a single tool execution. Should the spec explicitly address this?
5. Extracting fallbackRequestHandler — hosts currently need to set this manually on the MCP client for both Streamable HTTP and SSE paths. Should AppBridge provide a default or recommend one?

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[Avcharov]

@ochafik @antonpk1 @idosal What do you think?