MCP リソース、ツール、プロンプト。

MCP リソースはコンテキストを提供し、ツールはアクションを実行し、プロンプトは再利用可能な指示を提供します。 MCP の設計が不十分だとエージェントが信頼できなくなるため、この違いは重要です。データはアクションとして公開されるべきではなく、アクションはプロンプトに隠されるべきではなく、プロンプトが構造化された機能定義を置き換えるべきではありません。

ショートバージョン#

モデル コンテキスト プロトコルには、いくつかのサーバー特性があります。最も重要なもののうち 3 つは、リソース、ツール、および メッセージ として文書化されています。

次のように使用します。

• リソース: 「これが読み取り可能なコンテキストです。」
• ツール: 「ここでできることがあります。」
• メッセージ: 「ユーザーが選択できるワークフロー テンプレートは次のとおりです。」

詳細については、MCP 対エージェント API、MCP 登録、および AEO 開発者ガイド を参照してください。

比較表#

|特集 |ベストユース |誰がそれを始めることが多い |例 |

この分割により、統合が理解しやすくなります。能力の限界が明らかな場合、エージェントはより適切に推論できます。

MCP リソースは何のためにありますか?#

リソースはコンテキストのためのものです。 MCP 仕様では、リソースによりサーバーがファイル、データベース スキーマ、アプリケーション固有の情報などのデータを共有できると記載されています。各リソースには URI があり、MIME タイプ、サイズ、タイトル、注釈などのメタデータを含めることができます。

リソースの良い例:

-file:///project/README.md

• データベーススキーマ
• 製品カタログのスナップショット
• API エンドポイントのドキュメント
• 現在のプロジェクト構成
• 政策文書

リソースは、モデルが検査または参照できるように十分に安定している必要があります。読み取ったときにビジネス状態を変更してはなりません。

MCP ツールは何に使用されますか?#

道具は行動のためにある。公式ツール仕様には、MCP サーバーは、言語モデルが API、データベース、計算などの外部システムと対話するために呼び出すことができるツールを公開できると記載されています。

ツールの良い例:

• create_issue
• get_order_status
• 配送見積の計算
• 検索_在庫 -submit_refund_request
• run_lighthouse_audit

このツールには、スキーマ、検証、レート制限、アクセス制御、監査ログが必要です。 エージェント可観測性ガードレール ページがここに関連します。

MCP プロンプトの用途 プロンプトは再利用可能なテンプレートです。これらは、ユーザーまたはクライアントが引数を使用して既知のワークフローをトリガーするのに役立ちます。メッセージでは、コード レビュー、コンテンツ作成、オンボーディング、またはサポートの優先順位付けに関する指示を収集できます。#

この手順は次の場合に役立ちます。

• ワークフローは反復可能です
• ユーザーは意図的に選択する必要があります
• 指導パターンは一貫性から恩恵を受けます
• 結果にはアクションではなく多くの言葉が含まれていますプロンプトで実行を非表示にしないでください。何かの状態が変化した場合、それは確認と登録のあるツールに属します。

避けるべき設計ミス#

|エラー |それが問題を引き起こす理由 |ベストデザイン |

AEO への影響#

エージェントが読み取り可能な Web サイトは、コンテンツ、指示、アクションが分離されているという、MCP サーバーと同じ設計上の問題に直面しています。

たとえば:

• 価格設定ページはリソースと同様のパブリック コンテキストです
• 決済 API はツールのようなアクションです
• バイヤーズガイドはワークフローを簡単にサポートします

明確に分離することで、AI エージェントは何を読み取ることができるか、何を推奨できるか、何を実行できるかを理解することができます。これが エージェント エンジンの最適化 の実践的な基礎です。

導入チェックリスト#

1. エージェントが読み取ることができるものをすべてリストします。
2. エージェントが実行できるすべてのアクションをリストします。
3. ユーザーが呼び出すことができる繰り返しワークフローをリストします。
4. 各項目をリソース、ツール、またはメッセージに割り当てます。
5. ツールの回路図を追加します。
6. リソースに有用なメタデータを追加します。
7. プロンプトはユーザーが制御できるようにします。
8. 権限とリスクを文書化します。

よくある質問#

MCP サーバーはリソース、ツール、メッセージを公開できますか?#

はい。多くの便利なホストは 3 つすべてを公開しますが、それぞれの機能には明確な機能が必要です。

リソースはツールよりも安全ですか?#

通常、リソースはコンテキストを読み取ることを目的としているためです。アクセス制御が弱い場合、機密データが漏洩する可能性があります。

モデルは自動的にプロンプ​​トを呼び出す必要がありますか?#

プロンプトは通常、ユーザーによって制御されるか、明示的に選択されるように設計されています。自動アクションは、ツールと権限を使用して慎重に処理する必要があります。

最も重要な MCP 設計ルールは何ですか?#

ツールには副作用を、リソースにはコンテキストを、プロンプトには再利用可能な命令を保持します。## 結論

優れた MCP 設計は、主に境界が明確であることが重要です。リソース、ツール、プロンプトがそれぞれ独自の仕事を行うと、エージェントの信頼、デバッグ、改善が容易になります。