MCPのフォーム確認、サーバーが提供する専用アプリでレンダリングできるように──4つの条件が揃わなければ自動で従来型に戻る

MCPサーバーがクライアントに「この操作を実行していいですか」「このうちどれを選びますか」と尋ねる仕組みをelicitationと呼ぶ。標準では、クライアント（Inspectorなど）が自前のフォームUIを表示してユーザーに答えさせる。MCP Inspector v2.4.0（2026年8月26日公開）に、このフォームをサーバー側が提供する専用アプリで描画できるようにする機能が追加されたことを、実装したマージ済みPR #2083の本文で確認した。

3行まとめ

• MCP Inspector v2.4.0のPR #2083は、サーバーが提供するMCP Appsの専用アプリをelicitation（ユーザー確認フォーム）にアタッチしてサンドボックス内で描画する機能を追加した。新しい拡張やカスタムメソッドは作らず、既存のio.modelcontextprotocol/ui拡張にネストしたフラグを足しただけの実装
• アプリ描画は「クライアントがelicitation.formを広告」「MCP AppsのMIMEタイプを広告」「双方がネストしたelicitation設定を広告」「リクエストが有効なui:// URIを含む」の4条件すべてが揃った時だけ発動し、1つでも欠けると標準フォームに自動フォールバックする
• この機能は上位のプロトコル拡張リポジトリ（ext-apps PR #733）が実装し、MCP本体リポジトリでは「SEP-3118」という正式仕様提案として審議中。この記事の確認時点でSEP-3118はまだOPEN（未マージ）状態で、Inspector側の実装が仕様の正式承認より先行している

新しい拡張は作らず、既存の仕組みに1つフラグを足しただけ

PR本文は、この機能の実装方針をこう説明している。

Implements negotiated, app-rendered form elicitations: a server may attach an MCP App to a standard elicitation/create, and a host that can run one renders it and returns the app's ordinary ElicitResult. The native Inspector elicitation form stays the fallback on every failure.

No second extension, no custom method, no custom result shape. The only new wire surface is a nested elicitation flag on the existing io.modelcontextprotocol/ui extension on each side, plus _meta.ui.resourceUri on the request.

（交渉制の、アプリ描画によるフォームelicitationを実装する：サーバーは標準のelicitation/createにMCPアプリをアタッチでき、それを実行できるホストはそれを描画し、アプリの通常のElicitResultを返す。Inspector純正のelicitationフォームは、あらゆる失敗時のフォールバックとして残る。第2の拡張も、カスタムメソッドも、カスタムの結果形式も無い。新しい通信面はただ1つ、双方の既存のio.modelcontextprotocol/ui拡張にネストしたelicitationフラグと、リクエストの_meta.ui.resourceUriだけだ）

つまり、まったく新しいプロトコル拡張を作るのではなく、既にあるMCP Apps用の拡張フィールドに、elicitationにも対応しているかを示す1つのフラグを足しただけ、という最小限の実装だ。

アプリ描画が選ばれる4つの条件

PR本文には、いつネイティブフォームではなくアプリ描画が選ばれるのか、その条件が明記されている。

App rendering is selected only when all four gates hold:

1. the client advertises elicitation.form;
2. the client advertises the MCP Apps MIME type;
3. both peers advertise the nested elicitation setting on io.modelcontextprotocol/ui;
4. the request carries a valid absolute ui:// URI in _meta.ui.resourceUri.

（アプリ描画が選ばれるのは、次の4つの条件すべてが揃った場合のみだ。1. クライアントがelicitation.formを広告していること。2. クライアントがMCP AppsのMIMEタイプを広告していること。3. クライアントとサーバーの双方がio.modelcontextprotocol/ui上のネストしたelicitation設定を広告していること。4. リクエストが_meta.ui.resourceUriに有効な絶対ui:// URIを含んでいること）

この4条件を表にまとめると次の通り。

4条件のうち1つでも欠けると、標準のInspectorフォームに自動的にフォールバックする。PR本文はこの点を「最も重要な半分」と呼んでいる。

The same tool against a server that did not advertise the nested capability falls back to the built-in form. This is the half that matters most — a client that over-claims the capability strands every user of a server that never opted in

（同じツールでも、ネストした機能を広告していないサーバーに対しては組み込みフォームにフォールバックする。これが最も重要な半分だ——もしクライアントが実際には無い機能を過大に主張すれば、オプトインしていないサーバーの全ユーザーが置き去りにされてしまう）

現時点で対応しているのはWebクライアントだけ

3つのクライアント（Web・CLI・TUI）のうち、実際にアプリ描画を行えるのはWeb版だけだ。

Only the web client advertises the nested client-side setting, and only because it has a sandbox renderer to back it. Supplying InspectorClientOptions.appElicitation is what opts a client in, so CLI and TUI keep advertising the MIME type (they know what an App is) without ever claiming they can resolve an elicitation through one.

（ネストしたクライアント側設定を広告するのはWebクライアントだけで、それはサンドボックスレンダラーを持っているからにほかならない。InspectorClientOptions.appElicitationを指定することがクライアントのオプトインにあたり、CLIとTUIはMIMEタイプ自体は広告し続ける（アプリが何かは分かっている）が、アプリを通じてelicitationを解決できるとは決して主張しない）

実装は先行し、正式仕様「SEP-3118」はまだ未マージ

PR #2083の本文は、この機能がInspector独自の思いつきではなく、上位のプロトコル拡張リポジトリmodelcontextprotocol/ext-appsのPR #733（krubenok氏、タイトル「Support MCP Apps-rendered Elicitations」）が定義する配線プロトコルに従っていると明記している。実際にこのPR #733を開いて確認すると、Inspector側が実装した4条件とほぼ同じ内容（クライアントがelicitation.formを広告、MIMEタイプの一致だけではオプトインにならない、クライアントとサーバー双方がio.modelcontextprotocol/ui.elicitationを広告、という条件）が定義されていた。

さらにこのPR #733は、MCP本体のリポジトリ（modelcontextprotocol/modelcontextprotocol）で審議されている正式な仕様提案「SEP-3118: App-Rendered Elicitations for MCP Apps」（同じくkrubenok氏）に対応する実装だ。この記事でSEP-3118のPRページを直接確認したところ、ステータスはOPEN（未マージ）だった。つまりInspectorのPR #2083は、まだ正式に承認されていない仕様提案を先取りして実装した状態にある。PR #2083本文自身も「Inspectorはext-apps#733の配線プロトコルを話すが、そのヘルパー関数はまだ使っていない：リリース済みの@modelcontextprotocol/ext-apps（1.7.5）はそのPRより前のバージョンだ」と明記しており、core/mcp/appElicitation.tsなどの該当コードは、将来ext-appsパッケージが該当機能を含むリリースを出した時点で削除される予定のコードだと自己申告している。

動作確認の方法

PR本文によると、この一連の挙動——アプリ内での選択がサーバーへ届く往復、非対応サーバーへの自動フォールバック——はnpm run smoke:web:elicitというヘッドレスChromiumを使ったスモークテストで確認されている。サーバー側がフォーム内の選択肢をエコーバックし、それがサーバーまで正しく往復することもテストで押さえられているという。

自分でアプリ描画のelicitationを試したわけではない

本記事はPR #2083の本文・MCP Inspector 2.4.0のリリースノート・上位のext-apps PR #733・MCP本体のSEP-3118 PRページをそれぞれ実際に開いて確認した内容にもとづく。この記事を書いている自分の手元では、実際にMCP Appsを実装したサーバーを用意し、Web版Inspectorでアプリ描画のelicitationが動く様子を目視で確認する検証は行っていない。CLI・TUIが将来的にサンドボックスレンダラーを持つ計画があるのかどうかも、このPR本文からは読み取れなかった。SEP-3118が今後マージされて正式仕様になるのか、あるいは議論の末に内容が変わるのかは、この記事の確認時点（OPENステータス）からは分からず、読者が読む時点では状況が変わっている可能性がある。

関連記事: MCP（Model Context Protocol）とは / MCP Inspectorのv2が標準に / MCPサーバーが接続できない時の対処法

感想・指摘はコメント欄へ。