ツールインターフェースと MCP

関数を呼べる実行器に複数の外部サービスをどう接続するでしょうか。MCP が能力交換を標準化しても、Host はモデルの形式と各 Server を対応付け、識別・版・結果を管理します。ここでは呼び出し契約、次の記事では Skills による手順の再利用を扱います。

Host、Client と Server

MCP（Model Context Protocol）は、アプリケーションとサービスがコンテキストと能力を交換するためのプロトコルを定義します。Host はモデルを使用するアプリケーションであり、Client は Host 内で特定の Server に接続するコンポーネント、Server はツール、リソース、またはプロンプトテンプレートを提供します。1つの Host は複数の Server に接続でき、それらは同じビジネス API を使用する必要はなく、同じマシン上にデプロイされている必要もありません。MCP アーキテクチャ

モデルベンダーのツール呼び出し形式と MCP メッセージは同一のプロトコルではありません。Host は通常、MCP ツールの記述をモデルが認識できるツールにマッピングし、モデルの呼び出しを MCP リクエストに変換し、サービスの結果を本轮の観察に戻します。このアダプテーション層は、名前マッピング、パラメータ、結果型、エラー、呼び出し関連処理を処理する必要があり、Server のリストをそのまますべてのモデルが理解できる入力として使用することはできません。

一般的な「M×N が M+N になる」というのは、インターフェースの再利用による恩恵を説明するものです。M 個のアプリケーションがそれぞれ N 個のシステムに接続する場合、多くのアダプテーション処理が重複して実装されます。標準プロトコルにより、アプリケーション側とサービス側の一部の作業を再利用可能にします。ただし、認証、ビジネスセマンティクス、能力の互換性、ユーザー体験については依然として接続が必要であり、実際の統合コストは厳密に M+N にはならず、自動的に消滅することもありません。

伝送と実行場所

ローカルの stdio は通常、サブプロセスの標準入出力を通じてプロトコルメッセージを交換します。ログはプロトコルの出力ストリームに混入させてはいけません。Streamable HTTP は HTTP を介してリクエストとオプションのストリーミング機能を提供します。前者はローカルプロセスでよく使用され、後者はサービス化された接続に適していますが、伝送方式自体はビジネス権限の分離を提供しません。MCP 伝送概要

例えば、ローカルファイル Server がユーザーの広範なファイル権限を継承している場合、モデルがそれを選択するとこれらのファイルにアクセスできる可能性があります。「ローカル」だからといって、アクセス範囲が小さいわけではありません。リモート Server も、リクエスト主体、許可範囲、資格情報の有効性を把握する必要があります。「接続が確立された」だけでは、通信層が成立しただけであることを意味します。

3種類のサーバー側能力

これらは意図によって区別されますが、実際のインターフェースは異なる場合があります。あるリソースがツールによって読み取られることもあれば、ツールがデータのみを読み取ることもあります。重要なのは、呼び出し元が「これはアクションである」「これは資料である」「これはオプションの対話テンプレートである」ことを理解することであり、すべての返却テキストをタスクインストラクションに昇格させないことです。MCP 原語

発見から呼び出しまでの境界

プロトコルバージョンはサンプルコードより優先

プロトコルは進化します。今回確認した 2026-07-28 バージョンでは、server/discover を使用してサポートされているバージョンと能力を発見し、リクエストメタデータにプロトコルバージョンなどの情報を付与します。古いバージョンのステートフル初期化プロセスと、このバージョンのリクエストを混在して送信しないでください。古いクライアントを維持する場合は、実際にサポートされているバージョンに基づいて仕様を確認し、SDK をアップグレードする際にも相手側の互換性を検証する必要があります。バージョン管理されたアーキテクチャの説明

プロトコル層が無状態であっても、サービスがショッピングカート、ブラウザページ、または長時間のタスクを維持できないわけではありません。ビジネスステートは存在し続けることができますが、明示的なリソースハンドルなど、明確なアイデンティティとステート位置決めが必要です。TCP 接続がまだ存在しているからといって、次のツール呼び出しが前のビジネスオブジェクトに自動的にバインドされると想定してはいけません。

発見はすべてをコンテキストに読み込むことを意味しない

Host はツールディレクトリを取得でき、現在のタスクに基づいて露出範囲を選択できます。MCP の能力発見と Host のセマンティックツール検索は別の問題です。MCP に接続したからといって、すべてのツールスキーマがオンデマンドで読み込まれることが自動的に保証されるわけではありません。ツールの選択、キャッシュ、コンテキスト予算は Host の設計に属します。

2つのサービスがどちらも search を提供していると仮定します。Host は、サービスソースを正確に特定できるマッピングを維持する必要があります。同名のツールだけを表示して、呼び出しが誤ったバックエンドに到達することを許してはいけません。また、サービスが自らの名前を名乗ることを信頼して、それが信頼できる元のサービスであると認定してはいけません。マッピングは、Host がすでに設定し確認済みの接続アイデンティティに依存すべきです。

以下は、外側のプロトコルメッセージを省略した MCP ツール定義オブジェクトです。inputSchema を使用していることに注意してください。これは一部のモデル API の input_schema フィールドとは異なります。

{
  "name": "search_tickets",
  "description": "指定されたプロジェクト内のチケットを参照専用で照会します。エントリと次のページネーション位置を返します。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "project": {"type": "string"},
      "query": {"type": "string"}
    },
    "required": ["project", "query"],
    "additionalProperties": false
  }
}

MCP ツールは発見、呼び出し、構造化記述をサポートしています。結果には複数のコンテンツタイプが含まれる可能性があり、実行エラーは isError によって示されます。スキーマや注釈はセキュリティ証明ではありません。サーバー側は依然としてパラメータとアクセス権限を検証する必要があり、Host も信頼できないサービスが参照専用であると自称することを盲目的に信じてはいけません。MCP Tools 仕様

接続成功後も複数の失敗箇所が存在する

この階層型のトラブルシューティングにより、伝送が確立されていない場合にプロンプトを繰り返し修正することを避け、モデルが「より多くのツールを見る」ためにビジネス権限を無条件に拡大することを避けることができます。

2 つの search、どちらを呼ぶか

2サーバーを接続しても、各サーバー内の一意性は全体の一意性になりません。接続を識別してモデル向けの名前を実ツールへ対応付けます。名前解決と JSON-RPC の関連付けは別の責務です。

タスク手順との接続

ツール一覧は呼べる能力を示し、Host が選択と対応付けを担います。報告手順・項目定義・テンプレートは Skills とタスク手順の再利用 で扱います。名前・引数・結果構造でつなぎ、インターフェース更新後に依存する呼び出しの存在と意味を再確認します。

次に読む：Skills とタスク手順の再利用。