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

記事の前提は、Model Context Protocol（核心的な目的を強調するために綴りを明記した）が現状の形では非効率だというものだ。それには同意できる。

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

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

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

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の実行とはかなり対照的だ。

多くの開発者はソロモードで作業しているため、MCPを誤解していると思う。ソロモードでは、秘密情報はローカルにあるだけだ。アクセスの監査など気にしない。インフラやサードパーティの秘密情報を管理するIT部門もない。異なるハーネスやツールを考慮する必要もなく、自分のハーネスを使ってツールをそれに適応させるだけだ。チームメンバーが退職したときに秘密情報を無効化・ローテーションすることも考えない。多くの異なるランタイムやスタックに機能を提供する必要もない。

3月の時点で、すでに誰もがMCPは死んだと宣言していた[0]が、実際にはエージェントツールがエンタープライズにゆっくりと浸透するにつれて、サードパーティシステムとプラットフォームレベルの機能の両方にとって、MCPは増殖し、さらに不可欠になっている[1]。当時から、エンタープライズがMCPを必要とすることは明らかだった。

チームの文脈では？エンタープライズでは？Webサーバーをバックエンドにした、あるいはインプロセスのエージェントを構築する場合？MCP over HTTPSで得られる制御、監査可能性、アクセシビリティ、コンポーザビリティ、セキュリティ境界を、多くの特注のポイントソリューションなしに再現する方法は思いつかない。結局のところ、プロトコルがほぼ常に勝つ。

REST APIだけでできるか？つまり、MCPは標準化された認証、スキーマ、エージェント固有の交換フロー（ツール、プロンプト、リソースなど）を備えたHTTP上のJSON-RPCにすぎない。CLIだけでできるか？MCPが提供する制御メカニズム（監査、セキュリティ、集中認証など）の多くを失う。コンテキストの節約は誇張されている、ただし[…]

MCPに対する技術的またはクリーンさの議論（それらは妥当だが）には本当に興味がない。

私が気にしているのは、多くの企業がAPIを持っておらず、持つ理由も見いだせなかったことだ（ニッチ、開発者向けのユースケース、あるいは競合するフロントエンド/アプリを生み出す可能性があるなど）…

しかし今、それらの企業には理由がある（エージェント的だが、顧客のエージェントにデータへのアクセスを許可する！）。そして私にとって、それはより多くの企業が自社プラットフォーム上の自分のデータへのアクセスを許可するようになったことを意味する。これは純粋な勝利だ！

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

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

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

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

最も興味深い中間地点の選択肢は、エージェントを念頭に置いて特別に作られたCLIの出現だと思う。

例えば、grafanaにはgcxという新しいCLIがあり、grafanactlを置き換えた https://grafana.com/docs/grafana/latest/as-code/observabilit...

私は元々MCPサーバーを使っていたが、コンテキストの肥大化とMCPの限界に遭遇した後、これを探して見つけた。エージェントにとって素晴らしいインターフェースのようで、これを使えばo11yタスクをすいすいこなす。

MCPは一つの良いことをもたらした

多くのウェブサイトが、これまでREST APIを提供する気がなかったのに、人気が出たためにMCPサーバーを公開するようになった。そして、それらのサーバーを使って、LLMなどを接続することなく、自分のために通常の自動化を書くことができる。