エンジニアは、馴染みのないAPIに対してコーディングエージェントを使用する際に、手動でのコンテキスト組み立てがすぐに陳腐化するという問題に繰り返し直面しています。根本的な問題は、APIコントラクトの伝達メカニズムとしてプロセドキュメンテーションを使用していることにあり、これが陳腐化、繰り返しのトークンコスト、強制力の欠如といった問題を引き起こしています。プロセドキュメンテーションはすぐに時代遅れになるスナップショットを提供し、すべての会話で同じ情報を再アップロードすることを強制し、実行時エラーが発生するまで呼び出しを検証できません。構造的な解決策としては、OpenAPIドキュメントから直接生成されたMCP（Microservice Contract Protocol）サーバー経由で、APIコントラクトを呼び出し可能なツールとしてエージェントに提供することが含まれます。このアプローチは、各API操作を定義された入力スキーマを持つツールに変換し、構造化された発見と事前検証を可能にします。プロセとは異なり、MCPツールはエージェントによる即時のエラー修正を可能にし、認証を一元化し、接続されているすべてのエージェントに対してコントラクトが1つの場所で更新されることを保証します。ツールがストリームを開き、イベントを収集するため、ストリーミング操作も使用可能になります。ローカル開発では、スペックファイル上のローカルMCPサーバーを利用し、共有環境では、バージョン固定とユーザーごとのトークンを備えたホスト型MCPエンドポイントを使用でき、最小限のアクセスを目的としたトークンスコープを強調します。MCPは、内部APIに対する繰り返し統合作業、多数の小規模操作を持つ環境、請求のような強制力の高いドメイン、および急速に変化する仕様を伴うシナリオで真に優位性を発揮します。しかし、これは物語形式のドキュメントや高性能SDKの普遍的な代替品ではありません。MCPは、一度限りの探索、パフォーマンスが重要なクライアントまたはバッチクライアント、およびOpenAPIスペックで明示的に定義されていない操作にはあまり適していません。適切に維持されたOpenAPIドキュメントが不可欠です。なぜなら、ツールはスペック自体と同じくらい正確であるからです。理想的なセットアップは、単一のOpenAPIドキュメントを維持することを含み、そこから3つの異なるレンダリングが派生します。人間の学習のためのレンダリングされたドキュメント、本番コードのための生成されたSDK、およびエージェントの統合と探索のためのMCPサーバーです。このアプローチは、異なるチームやツール間での冗長な説明を防ぎます。