MCPが出たとき、これは過剰設計のクソだと思って、全然時間をかけなかった。今でもその決断を後悔してないよ。同じことがLangChainにも言える。経験豊富な開発者とそうでない人の大きな違いは、何かがクソに見えたら、たいていクソだってこと。流行ってるからって、無理に何かを真似するのはやめよう。

MCPはAIアプリ間の通信のための固定仕様/プロトコル（HTTP CRUDアプリの上に構築されている）。AIアプリと相互運用したいなら、これが絶対に正しい方法だよ。長い間、ソフトウェアエンジニアたちは、異なるアプリケーションをつなぐ唯一の方法は「統合」（他のアプリの特注APIにアプリを密結合させること）だと考え込まされていたみたいだ。誰かがプロトコルの本来の目的を思い出してくれて本当に嬉しい。再利用可能な通信の抽象化で、アプリケーションに依存しないものなんだ。MCPの目的は、HTTPやFTP、SMTP、IMAPのような共通の通信言語になること。AIはさまざまなことに使われるけど、特定の考慮が必要な特定の種類のものと通信したいと思うから、これは絶対に必要だよ。まだ読んでないなら、仕様を読んでみてね：https://modelcontextprotocol.io/specification/2025-11-25

MCPはいいけど、特にリモートMCPは、認証を自動で処理してくれるホスティングサービスにアクセスするための最も低い摩擦の方法だね。ただ、MCPはコンテキストの膨張があって、CLI + スキルと比べるとあまり良くない。CLIを使えば、毎回ツールコール全体を展開しなくても、フィルターやパイプ（通常のUnix bash）ができるし、複雑な入力をエスケープしにくい場合でもheredocが使える。CLIは、—help出力から簡単にスキルを生成したり、エージェント特有の指示を追加したりできる。つまり、エージェントにツールの使い方や存在するツール、レイジーロードの情報を教えるためのすべての指示を与えられるってこと。これで、すべてのツールを最初からコンテキストウィンドウに詰め込むことなく、必要な情報を提供できる（そう、Claudeのツール検索が部分的にこれを解決してるのは知ってる）。CLIはMCPのように常駐プロセスを実行する必要はないけど、必要なら実行できるよ。

今見ているAI周りの最高のツールの多くは、確定的なゲートを追加して、確率的なAIエージェントがそれを使っているんだ。だから、私はhttpよりもMCPを使ってる。エージェントが問題解決のために知性や創造性を使うのは嬉しいけど、いくつかの操作に関しては、普通のソフトウェア機能のように確実に動作するゲートが欲しいんだ。NanoClawは、エージェントがWhatsAppメッセージを見る前に確定的なフィルタリングを使うことで自分を売り込んでるし、APIキーをプロキシしてエージェントがそれを見ないようにしてる。これは、AIと作業する際にもっと自信を持てるようにするための似たような確定的なゲートなんだ。

どのAI統合も、ちゃんと設計されてない（トークンスロップの場合は設計すらされてない）感じがする。クリエイターたちは、まるで「あなたは絶対正しい、$TOOLはあなたの問題を解決する素晴らしいソリューションだ！」っていうのを吐き出すのに、$LLMOFTHEWEEKと同じくらいの考えを注いでるみたい。基本的なコマンドのヘルプテキストすら、真剣に標準化されてない（-hはホスト名を設定するのか、それともヘルプテキストを表示するのか？それとも-Hなのか？--helpは存在するのか？）。マニュアルページを書くのは、今や失われた技術のように思える。みんな$WEBSITE/docsを指さすけど、そこには予想通りLLMのスロップドキュメントが含まれてる。結局「AIの現代的標準」→「AIの標準」→「標準ですらない」→「過去のもの」っていう同じループを見続けることになる。すべてが根本的に間違ってるから。LLMは文脈的に純粋にテキストで、ネットワークプロトコルは本質的にもっと複雑だから。LLMは/api/v1/pingエンドポイントを過剰にスペックすることになるけど、ICMP pingはビット内でそれを実現できる。テキストベースのエンジニアリングは見えるけど（技術に疎い人でも解釈しやすいという意味で）、常にコアの上に抽象を形成することになる。$LLMモデルのエンコーディングが変わった瞬間に、揺らいだピラミッドが崩れ落ちることになるよ。

メンテナンスの負担が、誰も話さない本当のMCPキラーだよ。エージェントがGitHubを必要とする？そしたら、すでに良いドキュメントがあるAPIをラップしたnpmパッケージに依存することになる。俺はgh cliとcurlを使うだけで、APIが変更されたらエージェントは更新されたドキュメントを読んで適応する。MCPだと、ミドルマンがラッパーを更新するのを待つことになる。tptacekが言った通り、エージェントがbashを実行するようになったら、MCPはオーバーヘッドになる。セキュリティの議論も変だよ、認証なしで出荷されて、今はセキュリティが主な利点だって主張してる。chrootジャイルとスコープ付きトークンが数十年前にこれを解決してる。MCPが勝つのは、ターミナルを開かない非技術的ユーザーのためのOAuthフローだけ。開発ツールに関しては？もっと良いCLIを書けばいいだけだよ。

資格情報プロキシパターン（エージェントはキーを見ず、ゲートウェイがそれを所有する）は、人間が主役でエージェントがその代理として行動する時にはうまく機能する。でも、エージェントが主役になる必要がある時には壁にぶつかる。人間のアカウントからエージェントの名義で送信されたメールは、エージェント自身のアドレスから送信されたメールとは異なる法的および評判上の問題になる。エージェントが間違いを犯したり、行動を取ったり、関係を結んだりした場合、誰の名前がそれに載るの？今のところ、その答えはほぼ常に「人間の名前」になってるから、エージェントは実体として責任を持てないことになる。MCPが解決していない深い問題は、認証がユーザーのために作られたものであって、エージェントのためではないってこと。OAuthはエージェントに委任されたアクセスを与える。でも、委任はアイデンティティじゃない。委任されたGmailアクセスを持つエージェントは、代理として行動している。一方、自分のメールアドレスと電話番号を持つエージェントは、一級の参加者として行動している。ウェブをブラウジングしたりカレンダーを読むようなことには代理モデルが必要だけど、アウトリーチやコミットメント、帰属が重要なものには明確なアイデンティティが必要だ。これらの二つのケースには異なるインフラが必要なんだ。

俺は今でもMCPは完全に不要だと思ってるし、最初からそう思ってた。記事ではCLIがMCPより優れてる点を指摘してるけど、2つのポイントで足りてないんだよね。1つ目は、MCPなしでインターフェースを文書化すること。これは、CLIやAPI（他の統合も含む）の指示を含められるスキルを使うことで一番うまく解決できる。エージェントは必要な詳細だけを読み込むから、特定のケースに合わせてドキュメントをカスタマイズしやすいし、ツールのサブセットを使ったスキルを構築するのも簡単。2つ目は、リモートMCPに帰属する中央集権の利点について。従来の中央集権型プロキシでも同じ利点を得られるよ。MCPは本質的にそれらの利点を与えてくれるわけじゃない。CLI経由でAWS SSOを使えば、すぐに俺のアカウントにすべての権限が紐づくし、中央管理の利点も得られるし、観測可能性の利点もある。俺の考えでは、スキルを使って何をすべきかを文書化し、ターゲットを絞ったプログレッシブディスclosureの利点を享受し、サービスとの実際のやり取りにはCLIやREST APIを使うべきだと思う。

俺は数ヶ月間MCPを使って、デスクトップ自動化のためのアダプターを作ってる（ブラウザ、CLIツール、Officeアプリ）。プロトコル自体はしっかりしてるし、JSON-RPCのトランスポートとツール/リソースの抽象化もうまく機能してる。ただ、使えるアダプターのエコシステムが欠けてるんだ。ほとんどの開発者は、カスタム統合コードを書くことなくAIを既存のツールに接続したいと思ってる。これが今の本当のギャップだと思う。「MCPは死んだ」というフレームは早すぎると思う。むしろ「MCPはより良いツールとアダプターが必要」って感じで、これは解決可能な問題だよ。

最後に、これを数ヶ月言ってきたけど、一般的に大きな反発を受けてる。欠けてるのは中央MCPゲートウェイの役割とコードモードの2つだけ。これらが最適に使われる方法は100%わからないけど、90%のユースケースでは未来はこんな感じになると思う。簡単なケース、例えばcatやls、rg、grepみたいな一般的なコマンドをパイプするためのbashからjsへのコンパイラを誰かが作る必要があるんじゃないかな。そうすれば、すべてのRLやトレーニングデータを使えて、そっちに逸れるオーバーヘッドを節約できる。ローカルツールがほとんど残らなくなったら、エージェントサーバーをopencode serveみたいにスケールアップして、ウェブサーバーのようにエージェントを提供できるようになると思う。