MCP Client の Roots, Sampling, Elicitation 機能について調べたまとめ
はじめに
MCPサーバーの機能として Prompts, Resources, Tools がある一方で、MCPクライアントの機能としては Roots, Sampling, Elicitation があることを知りました。
そこで、これら3つの機能の役割について調査しました。
結論
- Roots
- クライアントがサーバーに対してファイルシステムへのアクセス境界を提供する機能
- サーバーがどのディレクトリやファイルにアクセスできるかを制御
- Sampling
- サーバーがクライアント経由でLLMに推論リクエストを送る機能
- サーバー側でAPIキーを持たなくても、クライアント経由でAI機能を利用可能
- Elicitation
- サーバーが実行時に動的にユーザーから追加情報を取得する機能
- 必要な時に必要な情報を対話的に収集
Roots
Rootsは、MCPクライアントがサーバーに対してファイルシステムの「ルート」を公開する標準的な方法を提供します。
これにより、サーバーがファイルシステム内のどこで動作できるかの境界を定義し、アクセス可能なディレクトリとファイルを明確にします。
主な機能
- アクセス境界の定義: サーバーがアクセスできるディレクトリを制限
- 動的な更新: ルートリストが変更された場合の通知機能
- セキュリティ: 適切な権限管理とパス検証
使用シナリオ
- プロジェクトディレクトリへのアクセス許可
- 複数のリポジトリへの同時アクセス
- ワークスペースの動的管理
プロトコルメッセージ
Request
{
"jsonrpc": "2.0",
"id": 1,
"method": "roots/list"
}
Response
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"roots": [
{
"uri": "file:///home/user/projects/myproject",
"name": "My Project"
}
]
}
}
処理フロー
Sampling
Samplingは、MCPサーバーがクライアント経由でLLMに推論リクエストを送信できる機能です。
これにより、サーバー側でAPIキーを管理することなく、AI機能を活用できます。
主な機能
- APIキー不要: サーバー側でLLMのAPIキーを持つ必要がない
- 人間の承認フロー: ユーザーがプロンプトと応答を確認・編集可能
- 柔軟なモデル選択: 抽象的な優先度設定によるモデル選択
使用シナリオ
- 収集したデータの分析
- コンテキストに基づいた意思決定
- 特定の形式で構造化されたコンテンツを生成
- 推論を用いてマルチステップの問題解決
プロトコルメッセージ
Request
{
"jsonrpc": "2.0",
"id": 1,
"method": "sampling/createMessage",
"params": {
"messages": [
{
"role": "user",
"content": {
"type": "text",
"text": "What is the capital of France?"
}
}
],
"modelPreferences": {
"hints": [
{
"name": "claude-3-sonnet"
}
],
"intelligencePriority": 0.8,
"speedPriority": 0.5
},
"systemPrompt": "You are a helpful assistant.",
"maxTokens": 100
}
}
Response
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"role": "assistant",
"content": {
"type": "text",
"text": "The capital of France is Paris."
},
"model": "claude-3-sonnet-20240307",
"stopReason": "endTurn"
}
}
処理フロー
Elicitation
Elicitationは、MCPサーバーが実行時に動的にユーザーに追加情報を要求できる機能です。
これにより、必要な時に必要な情報を対話的に収集できます。
モデルの提示文やロジックが、まだ解決されていない変数(例:{{current_user}}
、{{timezone}}
、{{organization.name}}
)を参照する場合に特に有用です。
主な機能
- 動的な情報収集: 実行時に必要な情報を要求
- 構造化されたスキーマ: JSON Schemaによる入力検証
- 3つのアクションモデル: Accept(承認)、Decline(拒否)、Cancel(キャンセル)
使用シナリオ
- アクションの確認:モデルが不可逆な操作(例: ワークスペースの削除)を実行しようとし、ユーザーに「本当に実行しますか?」と確認を促すためにElicitationを使用し、実行前にユーザーに確認を求める。
- 認証リダイレクト:ワークフロー中に、サーバーはユーザーの身分を確認する必要があり、クライアントのサインインまたは再認証フローへのリダイレクトを促す。
- 曖昧さの解消:ユーザーが「サブスクリプションをキャンセルしてください」と要求した場合、モデルは複数のサブスクリプションを検出する。確認プロセスを使用して「キャンセルしたいのはProプランかEnterpriseプランのどちらですか?」と促す。
- 段階的な入力収集:プロジェクト計画エージェントは「締め切りはいつですか?」といった高レベルな質問から始まり、チーム規模、マイルストーン、予算などの追加入力を段階的に収集する。
- 文脈に応じた分岐:カスタマーサポートのシナリオで、モデルはデバイス情報が欠落していることに気づき、「どのデバイスを使用していますか?」と促し、トラブルシューティングの手順を最適化する。
プロトコルメッセージ
Request
{
"jsonrpc": "2.0",
"id": 1,
"method": "elicitation/create",
"params": {
"message": "Please provide your GitHub username",
"requestedSchema": {
"type": "object",
"properties": {
"name": {
"type": "string"
}
},
"required": ["name"]
}
}
}
Response
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"action": "accept",
"content": {
"name": "octocat"
}
}
}
処理フロー
統合的な使用例
3つの機能を組み合わせたファイル分析エージェントが動作する様子
所感
Roots, Sampling, Elicitation については実装例がまだ少なく、具体的なユースケースをイメージしづらい部分もありました。一方で、これらの機能を使いこなせれば、非常に強力なMCPサーバーを作成できる可能性を感じました。
今回の機能に対応しているMCPクライアントがまだ少ないため、今後の動向を見守りたいと思います。
参考URL

ENECHANGEグループは、「エネルギー革命」を技術革新により推進し、より良い世界を創出することをミッションとするエネルギーベンチャー企業です。 enechange.co.jp/
Discussion