思い出せなくて自分を叱りたいけど、すごく良い記事があったんだ。MCPは、統一された安全な内部ユーティリティAPIへのアクセスが、内部のエージェントツールを使う非技術者に与えられると、組織レベルで機能するって提案してたんだよ。ワークフローをスキルとしてコード化して、インスタンス間で共有するべきだし、コンテキストに応じたAPIアクセスが必要なものはMCPを使うべきだね。

記事には日付が書いてないけど、遅延ツール読み込みが最近の更新だって書いてある。遅延ツール読み込みは2025年11月に追加されたんだって：https://www.anthropic.com/engineering/advanced-tool-use だから、この数字は少なくとも7ヶ月古いよ。なんで今これが投稿されてるの？

これAIが書いたの？MCPは基本的に特定のフィールドがいくつか必要なJSON RPCに過ぎないと思う。JSON RPCには懸念があるけど、LLMがインターフェースするための「サービス発見」レイヤーが必要だよね。それはウェブサイトやデスクトップアプリ、バックエンドサービスなどで利用できる必要がある。CLIはこれらのシステムがインターフェースする場所の一つに過ぎない。MCPを何に置き換えても、異なる通信プロトコルやツール発見のための異なるフィールドを指定しても、似たような形になると思うよ。

私はOpenAIでChatGPTアプリストアやCodexプラグイン、MCPに関するチームを運営してるんだ。この「MCPは死んだ」って投稿が見落としてるのは、MCPがトランスポートプロトコルとして使われるかどうかは実際には全く関係ないってこと。MCPが死んでない理由は、実際に地球上のほぼすべての会社がMCPサーバーを構築してるからなんだ。私たちはそれらの会社とやり取りしてるから知ってるよ。ほとんどの会社にはCLIがないし、外部APIすら持ってないところも多い！それでも、みんなMCPサーバーを作ってるんだ。だからMCPは死んでないどころか、今まで以上に重要なんだよ。もしかしたら、すべてのMCPサーバーを内部でCLIに変えるかもしれないし、コードモードを使うかもしれないし、ツール検索を実装するかもしれない。どれも重要なポイントに対する実装の詳細に過ぎないんだ。私たちのAIエージェントが、そうでなければアクセスできなかったサービスにアクセスできるようになることが大事なんだよ。それが重要なんだ。だから、MCPはモデルが直接コミュニケーションするためのレイヤーとして死んでるのか？もしかしたら、そうかもしれないし、そうじゃないかもしれない。MCPはプロトコルとして死んでるのか？全然そんなことないよ、真実からは程遠い。 [0]: ただ、Codexアプリのコンピュータとブラウザの使用機能が、この発言を以前よりもかなり弱くしてるのは確かだね。まだ試してないなら、ぜひ試してみて。驚くほどすごいから。

レストランの例え: > あなたは座って、テーブルの上に10個のメニュー（MCPツールの定義）が広がっている > 実際の料理（あなたの仕事）を置くスペースがない > 注文するたびに、メニューをまた引っ張り出さなきゃいけない これはあまり良い例えじゃないね。何度も注文するのはタパスレストラン以外ではあまりないし。メニューの上に料理を置くことは簡単だけど、普通は注文したらメニューを片付けて、料理のためにテーブルを空けるよね（文脈は？）。例えで説明するなら、もっと関連性のあるものにする努力をした方がいいよ。

MCPはCLIアプローチの約65倍のトークンを消費する。この例では、LLMがこのcurlコマンドをいつ使うかを知る理由がないみたい。リニアAPIはすでにLLMの重みの中で知られているから、「マニュアル」をコンテキストウィンドウに含める必要がないって考えなの？そうなら、かなり狭い勝利だね。

問題1: コンテキストウィンドウをむさぼるように消費する linearcli --help を実行してから notioncli --help、それから slackcli --help みたいにするの？それとも何か見落としてる？少なくともMCPを使えば、ハーネスは各ツールのタイトルだけをコンテキストに追加して、必要に応じて完全なドキュメントを追加できる。MCPサーバーごと、ツールごとにね。CLIが「--short-descr」コマンドを持つのと同じことだよ。 > 問題2: 運用の信頼性が低い ツールがREST APIを使っているなら、MCPが遅くなる理由はないと思う。プロトコルが非常に近いのに。そうなるのは、MCPがAPIの上に追加されたからで、もしかしたら遠くのデータセンターにホストされている下請け業者によるものかも？ほとんどのMCPサーバーはひどいだろうけど、それはプロトコルではなく業界に対する批判だよ。 > 問題3: 既存のCLI/APIと重複する そう、CLIツールがすでに存在する場合ね。SQLのMCPサーバーは馬鹿げてるし、トークンの無駄だと思う。curlのMCPにすればいいのに。でもほとんどのショップではCLIツールは存在しない。せいぜいAPIがあるけど、それはプログラムが使うために設計されてるもので、LLM用じゃない（言いたいこと分かるよね）。 > CLI -> API -> ドキュメントの順で提供する もちろん、遅くて無駄なウェブサイトの代わりに、企業はまずデスクトップ用のネイティブクライアントを提供し、その後に電話用のネイティブクライアントを提供すべきだね。

MCPって、エージェントにツールを与えるための方法じゃないの？自分のエージェントを作るときは、ツールを手動で定義できるけど、opencodeみたいな既存のものを使ってる場合、ユーザーとして新しいツールをどうやって追加するの？それにはAPIを使うんだけど、今はそれがMCPなんだ。MCPが死んでるって言うのは、ツールが死んでるって言ってるのと同じで、そんなことは絶対にないよ。だって、現代のLLMエージェントはツールの使用に特化して訓練されてるし、ツールがなければエージェントも存在しないからね。記事に書かれてる問題は、特定のツールに関するもので、ツールの説明が長すぎることが原因なんだ。これはMCPとは関係ないよ。MCPには、ツールの説明が他のものよりも多くのコンテキストを使う原因になるようなものは何もないから。

わからないけど、うちの会社では結構MCPを使ったエージェントを作ってるよ。Jira、Confluence、Gitlab、ログ＆メトリクスプラットフォーム（社内ソリューション）、QA（これが何をするのかはよくわからない）、Context7、Mattermost。最近のトレンドとかは全然知らないけど、MCPが死んでるとは言わないな。最新のホットなものではないけどね。

スキル/CLIアプローチが好きだけど、Claudeを使ってみて、CLIツールや外部APIに接続した特注コードでスキルやプラグインを作ると、特にCo-Workのロックダウンされたサンドボックス内でClaudeが許可することに問題が出てくることがわかった。サンドボックスから出る唯一の方法はMCPみたいだけど、それでもタイムアウトの問題があるね。