MCPサーバーとAPIの比較：AIエージェントが使うべきインターフェースは？

アプリケーションコードが呼び出す操作をすでに把握している場合は、APIまたはSDKを使います。モデルが実行時に機能を検出して選ぶ必要がある場合は、MCPを使います。本番用MCPツールの多くは内部で既存APIを呼び出すため、二つのインターフェースは通常、互いを補完します。

MCPは検出機能とモデル向けの契約を追加します。バックエンドAPI、認可、データモデル、MCPサーバーを囲む認証境界を置き換えるものではありません。

違いは、誰が操作を選ぶか

開発者がエンドポイントを選び、フィールドを対応付け済みなら、固定コードはPOST /refundsを呼び出せます。サポート事例を調査するエージェントは、証拠を読んだ後にget_invoice、explain_charge、request_refund、escalate_caseから選ぶ必要があるかもしれません。MCPはそれらのタスクとスキーマの現在の一覧をモデルへ提供します。

MCPツール仕様は、ツールの検出と呼び出しをプロトコルの一部にします。OpenAPIはHTTP APIを記述できますが、どのエンドポイントをエージェントのタスクにすべきかまでは決めません。

API、SDK、MCPを並べて比較する

この判断では、GraphQLもAPIに含まれます。スキーマintrospectionは開発者やクライアントがqueryを構築する助けになりますが、制限のないgraphが優れたエージェント用ツールセットになることはほとんどありません。

APIを直接呼ぶ方が明快な場合

次の場合はAPIを直接使います。

• ワークフロー内の同じ地点で必ず呼び出す。
• コードが必要な値をすでに持っている。
• レイテンシが重要で、プロトコルを一段増やしても判断上の価値がない。
• MCPが公開していないプロバイダー固有機能を連携で必要とする。
• 小さな型付きSDKが、アプリケーションに必要な契約をすでに提供している。

たとえばcheckout handlerは、レビュー済みのアプリケーションコードから支払いAPIを呼ぶべきです。ユーザーが決定論的なcheckout formを送信した後、請求を作るかどうかをモデルに選ばせるべきではありません。

MCPを導入する意味がある場合

次の場合はMCPを使います。

• モデルが複数の機能から選ぶ必要がある。
• 複数の互換エージェントクライアントでツールを使う必要がある。
• セッション中にツール一覧や利用可能なリソースが変わる可能性がある。
• ユーザーが標準的なエージェントフローから自分のアカウントを接続する必要がある。
• 構造化content、resource link、サーバー提供のプロンプトがクライアントに役立つ。

REST APIをMCPに変換するチュートリアルでは、一つのタスクから始め、その背後にAPIをラップします。エンドポイントごとに一つのツールを機械的に作る方法を避けています。

MCPはセキュリティ境界ではない

APIエンドポイントをtools/listから隠しても、その背後の認証情報は取り消されません。MCPサーバーはクライアントを認証し、代理対象のユーザーを認可し、対象API向けの上流認証情報を使う必要があります。バックエンドでもリソースを再度認可します。

MCP認可仕様はtoken passthroughも禁止しています。MCPサーバー向けに発行されたtokenを下流サービスへ転送してはいけません。

機械的なラッパーを避ける

RESTエンドポイントごとに一つのMCPツールを生成すると、選択肢が重複し、内部実装の詳細が露出しがちです。ユーザーのタスクから始めます。

User task: "Where is order 1842?"

Weak toolset:
get_order_row
get_shipment_row
translate_status_code

Better tool:
get_order_status

サーバーは内部で複数のAPIを呼び出し、最小限の有用な結果を返せます。その判断がエージェントに属する場合を除き、モデルに内部joinを調整させるべきではありません。

常に同じ手順を監査する

一つのワークフローにあるMCP呼び出しをすべて列挙します。アプリケーションコードがいつも同じ引数mappingで同じツールを選ぶなら、MCPに別の具体的な利点がない限り、そのレイヤーを型付きAPIまたはSDK呼び出しへ置き換えます。

以下のプロンプトは不要なラッパーを見つけ、モデルが実際に選択する箇所にはMCPを残します。