Add app-rendered elicitation MRTR example

[krubenok]

Summary

• add a self-verifying 2026-07-28 example of using an MCP App as the UI for a standard form elicitation
• negotiate the feature as elicitation: {} inside the existing io.modelcontextprotocol/ui extension on both peers
• attach _meta.ui.resourceUri only when the request-scoped client capabilities support app rendering
• use the SDK's existing MRTR engine to return InputRequiredResult, collect the standard ElicitResult, and retry with inputResponses

Design

This deliberately does not add a second extension package, custom method, or custom result type.

The example server publishes a self-contained text/html;profile=mcp-app resource and embeds an ordinary form-mode elicitation/create request in InputRequiredResult. The headless example client verifies two-sided negotiation, reads the bound app resource over the same connection, returns a standard ElicitResult, and lets the SDK perform the MRTR retry.

A graphical host replaces the deterministic selection with its MCP Apps View↔Host bridge; the core wire flow is unchanged. The Apps bridge continues to negotiate its own protocol version independently of core MCP 2026-07-28.

Related proposals:

• MCP Apps draft: Add app-rendered elicitations to the MCP Apps draft ext-apps#733
• Core SEP: SEP-3118: App-Rendered Elicitations for MCP Apps modelcontextprotocol#3118
• C# SDK: Add app-rendered elicitation support to MCP Apps csharp-sdk#1723
• Inspector reference: Add app-rendered elicitation reference implementation krubenok/inspector#1

Validation

• pnpm --filter @mcp-examples/apps-elicitation client
• example ESLint check
• repository pre-push build, typecheck, snippet-sync, and lint checks

[changeset-bot]

⚠️ No Changeset found

Latest commit: 10fa34b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@2578

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/@modelcontextprotocol/codemod@2578

@modelcontextprotocol/core

npm i https://pkg.pr.new/@modelcontextprotocol/core@2578

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@2578

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/@modelcontextprotocol/server-legacy@2578

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@2578

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@2578

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@2578

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@2578

commit: 10fa34b

[dylanclark]

Should this or another client also demo stateless mrtr elicitations

[krubenok]

Yes — the HTTP/modern leg is the stateless MRTR demonstration. createMcpHandler(buildServer) constructs a fresh server for every request, and the example runner exercises the initial tools/call plus the automatic retry over HTTP. I clarified that explicitly in the README and source comments, including commands for running the HTTP leg.