MCP プラグイン

MCP プラグインは、AI アプリケーションから別のプログラムが実装したツールを使えるようにします。ホストはツールの説明と実行先を登録します。ディスパッチャーは内蔵ツールをローカルで動かすか、MCP クライアントを通して外部サーバーへ呼び出します。外部ツールの実装はサーバー側に残ります。

本例ではプロジェクトファイルと再試行ポリシーのノートを読みます。ホストはすでに read_file を持ち、ノートは Notes サーバーにあります。ツールを追加するのは、転送先付きの一覧を増やすことに相当します。説明が要求できる内容を、アドレスが実行先を示します。ただし正しい宛先でも、存在しないノートは読めません。

MCP プラグインがツールを増やす仕組み

ホストはモデルとツールを調整し、ツールプールと Notes 用 MCP クライアントを持ちます。サーバーは外部ツールを実装し、ローカルプロセスでもリモートサービスでも構いません。図の境界を越えるとはホストの実行器を離れることで、必ずしもインターネットを経由しません。役割は MCP のアーキテクチャ に沿います。

ここでの「プラグイン」は、ホストが統合設定をまとめる形式です。MCP が全アプリケーションに同じパッケージ形式を要求するわけではありません。統合を有効にすると、ホストが Notes クライアントを作り、ツールを検出します。

MCP プラグインのステップ

初期設定は Notes 統合を有効にし、ノート n1 を要求します。2 件は固定テスト入力であり、モデルが実際に選んだ出力ではありません。

1. 内蔵ツールから開始。 プールは read_file の 1 件で、ローカル実行器への経路を持ちます。両実行カウンターは 0。Notes クライアントを作るだけではツールを呼びません。

2. 能力を検出し、ツール一覧を取得。 server/discover を ID notes-1 で送り、tools 能力を受け取ります。次に tools/list を ID notes-2 で送り、文字列 id を取る read_note と、文字列 query を取る search_notes を受け取ります。まだ未登録なので、プールの登録済み項目は 1 件です。

3. 実行先を登録。 ホストは外部名へ notes. を付け、経路にはサーバーの元の名前を保持します。

プールは 3 件になりました。接頭辞はホスト独自の命名規則で、サーバーは自分のツール名を受け取ります。モデルには名前、説明、入力スキーマを提示し、実行器オブジェクトはホスト内に保ちます。

4. ローカル呼び出し。 c1 は read_file({"path":"README.md"}) を要求します。ローカル実行器が固定ファイルを読み、Project: Sketchpad を返し、ホストが c1 に観測結果を関連付けます。ローカルは 1 回、外部は 0 回です。

5. 外部呼び出しの経路を選択。 c2 は notes.read_note({"id":"n1"}) を要求します。登録先の Notes クライアントが tools/call を送ります。要求 ID は notes-3、サーバー名は read_note、引数は変更せず {"id":"n1"} です。

6. 実行して返す。 Notes は自分のデータから n1 を探し、Retry policy: Retry temporary failures up to three times. を返します。完全な結果は isError: false、応答 ID は notes-3。ホストが待機中の c2 と対応付け、観測を追加します。最終値はローカル 1 回、外部 1 回です。

通信上の要求 ID と c1、c2 は別の層に属し、ホストが対応を管理します。MCP の基本プロトコル は要求と応答の対応を定義し、c1、c2 はホストの帳簿用 ID です。最後のモデル回答は生成しません。

一覧にあるツールが失敗する理由

統合を有効のまま、ノート ID を missing に変えます。検出と登録は同じ 3 件のプールを作ります。経路も見つかり、サーバーは read_note を 1 回実行しますが、結果は Note not found: missing、isError: true です。

可用性は「呼び出しを送れるか」、検索は「要求データがあるか」を答えます。検出成功は後者を保証しません。MCP は実行失敗をツール結果内で返し、不明なサーバーツール名などのプロトコルエラーを JSON-RPC error 応答で返します。ツール仕様 が区別を定義します。

統合を無効にすると、ID にかかわらず read_file だけが残ります。c1 は成功し、固定の c2 探査は notes.read_note を見つけられません。ホストがローカル可用性エラーを作り、MCP 通信は送りません。接触していないサーバーからの応答と呼んではいけません。

連携を無効にするとツールは有効、ノートは不在 は c2 の経路選択前で止まります。サーバー実行回数が増えるか予測してから再生してください。

引数を変える前に失敗場所を調べる

同じ Notes サーバーへ別ツールを追加するなら、説明とサーバー経路を登録します。既存クライアントで運べるため、ディスパッチャーは従来どおり名前から実行先を探します。ツールごとに別の配送手順を作る必要はありません。

境界条件

• 統合なし。 内蔵ツールは残ります。引数変更で外部経路を補えません。
• ノートなし。 実行済みのツールが失敗を返します。届いたエラーはパケット損失ではありません。
• 検索結果なし。 公開済みの search_notes は空検索のメッセージを返し、実行エラーにはしません。検出には含めますが、2 件のデモ呼び出しは read_note だけを使います。
• 検出と権限。 検出したツールにもホストのポリシーが適用されます。本例の読み取り専用ポリシーは許可します。権限 でこの別判断を扱います。

よくある間違い

• 説明を実行コードと考える。 名前の先に実装か経路が必要です。スキーマは引数の形を検証してもノートを読みません。
• ホスト別名をそのまま送る。 ホスト項目は notes.read_note、サーバーが期待するのは read_note です。
• 検出をツール実行に数える。 能力の検出と一覧取得では両実行回数は増えません。
• エラーフラグを捨てる。 読める文章があっても、次の処理には明示的な失敗信号が必要です。
• モデルが未公開ツールを選んだと断定する。 無効化シナリオは固定の可用性探査を注入します。実モデルの選択を説明するものではありません。

この教材のプロトコル版

MCP 2026-07-28 を使います。要求はプロトコル版とクライアントメタデータを含みます。ホストは最初に server/discover で対応版と能力を尋ねる設計です。クライアントによる呼び出しは任意で、必須のセッションハンドシェイクではありません。以前の版は initialize、続いて notifications/initialized を使いました。比較時は検出契約と版管理の説明を参照してください。

モデルの簡略化

メモリ上のホスト、模擬サーバー 1 台、固定呼び出し 2 件、小さなデータ集合を使います。仕様や正式な訓練の代わりではありません。トランスポート、認証、権限交渉、モデル判断、ストリーミング、再試行、ページ分割、キャッシュ、購読、resources、prompts は省略します。

プラグイン形式と別名は教材用のホスト規則です。インスペクターはペイロードの抜粋を示しますが、生成記録には必要な要求メタデータと応答フィールドを残します。再生秒数は説明の時間で、MCP の遅延測定値ではありません。