MCPは最初から悪いアイデアだった、もう終わらせる時だ

記事の前提は、Model Context Protocol（核心的な目的を強調するためにフルスペルで書く）が現在の形では非効率だというものだ。それには同意できる。

では、エージェントがサーバーに接続し、その機能、ツール、分散スキルを発見するためのプロトコルは不要だということになるだろうか？ 私は反対だ。

> ターミナルアクセスを持つエージェントはほとんどのMCPサーバーを置き換えられる

ターミナルアクセスを持たない他のすべてのエージェントは何をすべきなのか？

「[...] LLMがあまり賢くなかった時代に作られた」、それはおよそ1年半前のこと——信じられないほどの進歩だ。

MCPが勝っているのは、ChatGPTやClaudeのアプリ内にプラグインストアがあるからだ。これらのプラグインはワンクリックでインストールできるMCPサーバーで、認証もサポートしている。これがビジネスユーザーが使っているものだ。

タイトルはクリックベイトに感じる。直接API、CLI、MCPにはそれぞれ用途がある。

直接アクセス（Curlや自作の小さな関数）：これにはエージェントがAPI仕様を完全に理解している必要がある。そう、プログレッシブディスクロージャーを使ってコンテキストを保護できるが、これは本質的にエージェントが使用前に毎回APIを理解し直す必要があることを意味する。また、典型的なAPI仕様がエージェントフレンドリーであるとは限らない。エンドポイントを呼び出す際にニュアンスがある場合、それをどこに置くのか？ OASの説明に？ 動くが、不格好だ。

CLI：これは美しく機能する。特に複雑なバックエンド向けのサードパーティCLIがすでに存在する場合は。ただし、よく文書化されエージェントフレンドリーなCLIを前提とするが、ほとんどのCLIは人間やCI/CDでの利用を想定して設計されている。MCPがコンテキストを取りすぎると言うなら、エージェントがmy_cli --helpから始めて、スイッチやパラメータを一つずつ辿ってCLIの呼び出し方を理解することを考えてみてほしい。よく知られたCLI（例：aws）を呼ぶ場合は問題は少ないが、よりニッチな（あるいはカスタムの）ものは最終的なCLIコマンドを組み立てるのに何ターンも必要とする。

MCP：問題はあるが、エージェントネイティブなソリューションを提供する。ツールについてエージェントが知る必要のあるすべてが一度に利用可能になる。エンタープライズ環境では、MCPはMCP Gatewayを通じて提供でき、ガバナンスと権限管理を提供する。これは、エージェントがシェルで実行権限を持つ必要があるCLIを動かすのとはかなり対照的だ。

これは私の経験とは合わない。昨日、MicrosoftのPower BI Authoring MCPを使って、SQLやCSVファイルからセマンティックモデルを作っていた。魔法のようだった。

MicrosoftはMCPでその方法を定義している。MCPをマシンに追加するのは簡単で、実行も信頼できる。

代替案は、モデルが彼らのドキュメントサイトから直接ドキュメントを取得しなければならないということだろう。もしそうなら、MSはおそらく素晴らしいドキュメントを用意し、そのmarkdownヘッダーもサポートするだろう…しかしすべてはインターネット上の特定のウェブページを見つけることにかかっている？ 私にはMCPよりあらゆる面で劣るように思える。

エージェントがAPIを理解することだけでなく、彼らが持つアクセスを制限することも重要だ。APIが制限しない特定の方法で内部サービスへのアクセスを与えたいなら、保護的な制御と変換を備えた非常に具体的なクエリを提供するMCPは非常に有用だ。

MCPのモノリシックな設計はいつもヒュドラと戦っているように感じられた。一箇所を修正すると、別の場所で5つの新しいバグが生まれる。なぜこれが普及したのか理解できなかった。