最近のエッセイは、Model Context Protocolは前の世代のAIアシスタント向けに設計されたものであり、今後は直接のHTTP APIやコマンドラインツールに道を譲るべきだと論じている。この主張で最も重要な技術的指摘は、幅広いターミナル権限を持つエージェントであれば、ドキュメントを確認し、スクリプトを作成し、複数のAPIを呼び出し、専用のMCPサーバーを使わずにワークフローを調整できるという点だ。これは確かに意味のある能力だが、それだけで、MCPがあらゆるエージェントや導入環境において不要になったと結論づけることはできない。
検討対象となっているエッセイは、MCPは最初から悪い考えだったと主張している。この画像は、それに対するこの記事の反論が出発する初期の立場を捉えている。
意見の相違は範囲に関するものだ。Anthropicは2024年11月、AIアプリケーションと外部データソースの間で双方向の接続を確立するためのオープン標準としてMCPを発表した。その目的は、個別に作られたコネクタを共通のアーキテクチャに置き換えることだった。すなわち、サーバーが機能を公開し、クライアントがそれを検出して呼び出す。この説明は、MCPが統合とガバナンスの層としてなぜ有用なのかを示している。一方で、あらゆる実装が効率的であること、あるいはこのプロトコルがあらゆるエージェントにとって最良のインターフェースであることを証明するものではない。
直接アクセスの利点が最も大きくなるのは、エージェントがすでに信頼できる実行環境を持ち、APIを理解するのに十分なコンテキストと、そのAPIに到達する権限を備えている場合だ。適切に文書化されたRESTエンドポイントや成熟したCLIは、固定されたMCPツールの集合よりも柔軟に対応できる。エージェントはリクエストを構成し、複数のサービスを組み合わせ、エンドポイントの変更にも適応できる。ただし、この比較は、多くの本番環境用エージェントが意図的に持たないようにしている能力を前提としている。ターミナルへのアクセスは、単なるもう一つの転送手段ではない。そこには認証情報、ローカルファイル、ネットワークリソース、そして本来のサービス範囲を超える操作が露出される可能性がある。
この違いは、セキュリティと運用において重要だ。 narrowly scopedとすべき箇所を自然に訳す: 権限を限定したMCPサーバーは、ネットワークやシェルへの無制限のアクセスではなく、厳選されたツールだけを提示できる。また、管理者が管理する境界上で、認証、認可、取り消し、監査ログを一元的に処理できる。これらはMCPが持ち得るアーキテクチャ上の利点であり、すべてのMCP導入がそれらを安全に実装していることを保証するものではない。ここで示された証拠には、MCPがプロキシを介したAPI設計よりも安全、高速、低コストであることを示す、比較セキュリティ監査、性能評価、インシデントデータは含まれていない。
このエッセイはまた、実際のスケール上の問題も指摘している。多数のサーバーと冗長なツールスキーマはモデルのコンテキストを消費し、ツールの選択を難しくする可能性がある。ツールの検出、検索、プログラムによる呼び出しは、この問題への対応策だ。Anthropicは2025年12月時点で公開MCPサーバーが1万を超えて稼働していると報告し、同社のAPIには、大規模なツールセットへの対応と複雑なワークフローにおける遅延の削減を目的として、Tool SearchとProgrammatic Tool Callingが追加されたと述べた。これらはAnthropicによるエコシステムと製品に関する主張であり、独立した測定結果ではない。ただし、エコシステムがコンテキストの肥大化を単に受け入れるのではなく、エンジニアリング上の問題として扱っていることは示している。
直接APIは、問題の別の側面に対応する。すべての操作を個別の宣言済みツールへ変換しなくても幅広い機能を提供でき、標準的なコンテンツネゴシエーションによって、エージェントが簡潔なテキストやMarkdownを要求できるようにもなる。しかし、API仕様は依然として、検出可能で、理解しやすく、バージョン管理され、エージェントの実行環境と互換性がなければならない。CLIも、それが存在し、文書化され、機械可読な出力を提供し、自律的に安全に呼び出せる場合に限り、安定したインターフェースを提供できる。ここで参照された資料は、MCPが現在接続しているサービス全体で、これらの条件が満たされていることを示してはいない。
ガバナンスの歴史も、MCPが時代遅れのモデルに結びついたAnthropic単独の実験にすぎないという主張を複雑にする。Anthropicは2025年12月、MCPをLinux Foundation傘下のDirected FundであるAgentic AI Foundationへ寄贈すると発表し、プロジェクトのガバナンスモデルは変更されないと述べた。この動きは、より広い範囲の管理主体を支える根拠にはなり得るが、報告された導入実績の数字を確認したり、技術的なトレードオフに決着をつけたりするものではない。少なくとも、このプロトコルの将来を、一社のベンダーが提供するアシスタントの機能という観点だけで評価することはできなくなる。
したがって、開発者にとって実用的な選択は条件によって異なる。権限を慎重に管理されたターミナルエージェントであれば、MCPラッパーを減らし、直接APIやCLIへのアクセスから恩恵を受けられるかもしれない。一方、複数ユーザー向けアプリケーション、管理されたデスクトップアシスタント、企業向けワークフローでは、機能を制限された境界、委任された認証情報、一貫したユーザーの同意、一元化されたログが必要になる場合がある。MCPはそのような境界を公開するための共通手段を提供できるが、適切に設計されたAPIゲートウェイやサービスプロキシでも、このプロトコルを使わずに同じ管理機能の一部を実現できる。
証拠が裏づけるのは、「MCPは最初から悪い考えだった」という広い結論ではない。直接インターフェースは能力の高いエージェントにとって表現力が高く、大規模なMCP導入には検出とコンテキスト管理の課題が生じる、という観察を支えるものにすぎない。また、ターミナルを利用できるエージェントが本番環境の標準であること、直接アクセスによって認証リスクがなくなることを示すものではなく、無制限の実行権限を持たせるのが適切でない場面でMCPに価値がないことも示していない。エンジニアリング上の有用な問いは、エージェントがAPIを呼び出せるかどうかではない。必要な機能を、最小限のアクセス権、運用上の複雑さ、露出面で提供できるインターフェースはどれか、ということだ。