はじめに
この記事では、Model Context Protocol (MCP) が定義する Prompts と Resources という機能を、各AIアプリケーションが実際にどのようなUI/UXとして実装しているのかを整理します。
背景
業務でMCPホストの実装を担当する中で、Tools以外の機能（PromptsやResources）をどのようなUIでユーザに提供すべきか、設計に悩むことがありました。そこで、参考のために主要なMCP対応アプリがこれらをどう扱っているのかを調査することにしました。
本記事は、その調査結果を整理したものです。同じような課題を持つ方々にとって、実装のヒントになれば幸いです。
この記事の目的
- MCP仕様が「規定している範囲」と「規定していない範囲」を明確にする
- 主要MCPホスト（Claude Desktop/Code, GitHub Copilot, Cursor, Gemini CLI）における対応事例を具体的に紹介する
- 上記の事例から共通するパターンを抽出し、MCPホストを実装する際の判断材料を提供する
対象読者
- MCPを活用したアプリケーション開発を検討している開発者
- 既存のMCPホストがどのように設計されているか知りたい方
- AIエージェントアプリのUX設計に関心がある方
MCP の基本と役割分担
MCP が規定していること
Model Context Protocol (MCP) では、MCPサーバーがクライアントアプリケーションに提供できる機能として、主に以下の3種類が JSON-RPC ベースで標準化されています。
- Tools: クライアント経由でモデルから呼び出される関数的な処理
- Prompts: 再利用を目的としたプロンプトのテンプレート文
- Resources: モデルに渡すためのコンテキストデータ（ファイルやスキーマなど）
MCP が規定していないこと
一方で、MCPは以下の点について特定のUI/UXを規定していません。
- Tools / Prompts / Resources を：
- どのようなUIで表示するか
- どのようなトリガーでモデルに渡すか
- どのタイミングで、どれだけの量をコンテキストに含めるか
そのため、実際には各MCPホスト（MCPサーバーに接続するアプリケーション）が独自にUXを設計・実装しています。
現状をざっくり整理すると、以下のようになります。
- Tools の扱い: ほぼすべてのクライアントで共通しています（LLMのfunction calling/tools機能にそのままマッピングされるのが一般的です）
- Prompts / Resources の扱い: 仕様としての定義はありますが、具体的にどう見せ、どうモデルに渡すかはアプリ側の工夫に委ねられています
主要MCPホストの事例
ここでは、代表的なMCPホスト（Claude Desktop、Cursor、GitHub Copilotなど、MCPに対応したアプリケーション）が、PromptsとResourcesを具体的にどう扱っているのか、その実際の挙動を見ていきます。
なお、本記事で取り上げるアプリケーションは、MCPの公式サイトにおいて Prompts または Resources に対応している と記載されているものを中心に選定しました。
本記事に記載した挙動は、2025年11月時点のものになります。
アップデートされる可能性が高いため、詳細は公式ドキュメントをご確認ください。
Claude Desktop
公式ドキュメント
Prompts の扱い
- メッセージ入力欄の「+」メニューから「(MCP名)から追加」を選び、Promptを添付する
- ユーザが内容を確認したうえで送信できる
Resources の扱い
- メッセージ入力欄の「+」メニューから「(MCP名)から追加」を選び、Resourceを添付する
- ユーザが明示的にどのリソースをコンテキストに含めるか選択する形式となっている
Claude Code
公式ドキュメント
Prompts の扱い
- MCPサーバーが提供する Prompts は
/を入力すると補完候補として表示される - 形式は
/mcp__サーバー名__プロンプト名となる（例:/mcp__github__list_prs） - プロンプト結果は会話に直接挿入される
Resources の扱い
- プロンプト内で
@を入力すると、接続済みMCPサーバーのリソースがファイルと同様にオートコンプリート表示される - 形式は
@server:protocol://resource/pathとなる（例:@github:issue://123、@docs:file://api/authentication） - 複数のリソースを同時に参照可能（例:
Compare @postgres:schema://users with @docs:file://database/user-model） - 指定したリソースは自動的に取得され、添付ファイルとして扱われる
GitHub Copilot (VS Code)
公式ドキュメント
Prompts の扱い
- Agent Modeのチャット欄で
/mcp.<server>.<prompt>形式のSlash Commandとして現れる - サーバーが提供する事前設定されたプロンプトをスラッシュコマンドで呼び出せる
Resources の扱い
- IDEのUIで「Add context…」→「MCP Resources…」のようなフローで選択する
- チャットに紐づけるリソースをユーザが明示的に選択する
Cursor
公式ドキュメント
Prompts の扱い
- MCPのPromptsが「
/をタイプした時の補完候補として現れる」形で提供されている
Resources の扱い
- ユーザがリソースの読み込みを指示すると、クライアント(Cursor) が内部で
resources/list/resources/readを呼び出してリソースを取得する - 実行プロセスがチャット画面に表示され、何を取得しているか確認できる
- UIでの事前選択は不要だが、明示的な指示（「〇〇のリソースを読んでください」など）は必要となる
Gemini CLI
公式ドキュメント
Prompts の扱い
- MCPのPromptsをCLI上のスラッシュコマンドとして認識する
-
/prompt-nameのように実行できる
Resources の扱い
- (2025年11月時点では) MCP Resources に対応していない
- MCP公式サイトのクライアント一覧でも Resources 列が❌となっている
パターンの整理と分類
前節で見た具体例から、共通するパターンを抽出します。
Prompts の2つのパターン
コマンド入力型
-
使い方:
/<command>のように、入力欄で/をタイプすると補完候補にMCPのPromptが並ぶ -
特徴:
- IDEやCLIといったテキスト中心のUIと相性が良い
-
採用例:
- Claude Code
- Cursor
- Gemini CLI
- GitHub Copilot
添付型
- 使い方: メニューから選択して、メッセージにプロンプトを添付する形で送信する
-
特徴:
- リソースと同様の操作感で扱える
- ユーザが内容を確認したうえで送信できる
-
採用例:
- Claude Desktop
Resources の3つのパターン
手動選択型
- 使い方: メニューやボタンから MCP リソースを選択し、ユーザがどのResourceをコンテキストに含めるか明示的に選ぶ
-
特徴:
- どのリソースをコンテキストに含めたかが明確で、透明性が高い
-
採用例:
- Claude Desktop
- GitHub Copilot
インライン指定型
-
使い方:
@をタイプするとResourceリストが出てきたり、@server:protocol://resource/pathのようにチャット内から直接参照する -
特徴:
- 既存のファイル参照コマンド(
@+ 相対パス指定) と同じメンタルモデルで扱える - 「どのリソースを読ませたか」をプロンプトのテキストとして残せる
- 既存のファイル参照コマンド(
-
採用例:
- Claude Code
指示ベース取得型
-
使い方: UIでの事前選択は不要。ユーザが自然言語で指示すると、クライアントが
resources/list/resources/readを実行してリソースを取得する -
特徴:
- @メンションなどの特殊記法が不要
- 実行プロセスが可視化され、何を取得しているか確認できる
- 会話の流れで柔軟にリソースを取得できる
-
採用例:
- Cursor
対応パターンの比較
| MCPホスト | Prompts | Resources |
|---|---|---|
| Claude Desktop | 添付型 | 手動選択型 |
| Claude Code | コマンド入力型 | インライン指定型 |
| GitHub Copilot | コマンド入力型 | 手動選択型 |
| Cursor | コマンド入力型 | 指示ベース取得型 |
| Gemini CLI | コマンド入力型 | （対応なし） |
自分で実装する際の設計指針
前節までの整理を踏まえて、あくまで私見となりますが、自分でMCPホスト（エージェントアプリ）を実装する場合の指針を考察します。
Prompts の設計観点
1. コマンド入力型 / 添付型 のどちらか（または両方）を採用する
ターゲットとするユーザ層やアプリケーションの性質によって、パターンの相性も変わってくるようです。
エンジニア向けの開発ツール（CLIやIDE）であれば、コマンド入力型を採用することで、キーボードから手を離さずに操作できる自然な体験を提供しやすいかもしれません。
一方で、チャットツールのような一般ユーザ向けのインターフェースであれば、添付型の方がメニューから選んで貼り付けるという直感的な操作が可能になり、わかりやすさが向上するのではないでしょうか。
2. Promptsは「ユーザのワークフロー・マクロ」と捉える
Promptsを定義する際は、単なる「LLMの役割設定（System Prompt）」ではなく、ユーザが行いたい具体的なタスク単位で設計するのが良さそうです。
例えば、Cursorのコマンド機能のような、.cursor/commands で定義できる具体的なワークフロー（「テストコード生成」や「PR作成」など）をイメージしてPromptsを用意すると良いかもしれません。Promptsを「ユーザの意思決定を助けるショートカット」として扱うことで、より実用的なUXの実現に近づくはずです。
厳密にはMCPサーバー側の設計指針となりますが、クライアント側でも「そのような粒度のPromptが活用される」ことを前提にUXを設計（例：スラッシュコマンドのような呼び出しやすさを確保する等）すると良いと思います。
Resources の設計観点
1. 最低限、手動選択型を用意する
どのようなクライアントであっても、手動選択型のUIは最低限用意しておくと安心な機能と言えそうです。
AIがどの情報を参照して回答を生成したのか、その根拠となるコンテキストはユーザ自身が把握できることが望ましいからです。Claude DesktopやGitHub Copilotのように、メニューから明示的にリソースを選択できるUIを提供することで、透明性と説明責任を担保しやすくなると思われます。
2. テキスト中心のワークフローが多い場合はインライン指定型を検討する
もし開発中のアプリが、Claude Codeのようなテキスト入力を主体とするものであれば、@resource のようなインライン指定型の導入を検討してみても良いかもしれません。
この方式には、チャット履歴そのものに「どのリソースを参照したか」という記録がテキストとして残るため、後から振り返った際のデバッグが容易になるというメリットがありそうです。
3. 柔軟なUXを目指すなら指示ベース取得型を検討する
より高度で柔軟なユーザ体験を目指すなら、Cursorのような指示ベース取得型が選択肢の一つになりそうです。これは、ユーザが「〇〇のリソースを見て」と自然言語で指示するだけで、システムが必要なリソースを自動的に取得してくれる仕組みです。
ただし、この方式を採用する場合は、ブラックボックス化を防ぐ配慮が必要になるかもしれません。「どのリソースをいつ読み込んだか」をログに残したり、実行プロセスをUI上で可視化したりすることで、ユーザに安心感を与える設計が大切になりそうです。また、不用意に大量のデータを読み込まないよう、コストやレイテンシを考慮した制御も必要になるかと思われます。
まとめ
振り返り
MCPの仕様では Tools / Prompts / Resources という基本要素（プリミティブ）が定義されていますが、これらをどう使うか、実際のUX（ユーザ体験）については各クライアントの設計に任されています。
主要なクライアントの挙動を見てみると、Promptsは「コマンド入力型」「添付型」、Resourcesは「手動選択型」「インライン指定型」「指示ベース取得型」といったパターンに整理できそうです。
設計における視点
MCPホストを実装する際は、以下の3点を考慮して設計すると良さそうです。
- ユーザ層：エンジニア向けならコマンドで、一般ユーザ向けならUIで選択できるようにする
- 説明責任：ユーザ自身が、プロンプトとリソースを明示的に指定できる仕組みを用意する
- 柔軟性：会話の流れで動的にリソースを取得したいなら、指示ベース取得型も検討する
本記事で整理したパターンを、ご自身のアプリの特性に合わせて選択する際の参考として活用いただければ幸いです。