MCPは導入しないと言いましたよね？

Model Context Protocol（MCP）を導入しないと明言していたはずですが、どうなっているのでしょうか？

彼らがMCPに対して慎重な姿勢であることは評価するけれど、何もないよりはマシだよ。

著者が指摘している理由で最適とは言えないかもしれないけれど、USB-CもNVMeもHDMIも同じようなものだよね。

私たちがこれらの技術を欠点がありながらも大成功させているのは、互換性が高く、エンドユーザーにとって使いやすいからだ。

だからこそMCPはどこにでもあるんだ。パフォーマンスや堅牢性、統一感に欠けるかもしれないけれど、時間とともに改善されていくだろう。

それに、LLMを何か有益なものに繋ぐための「最適」な方法が7つも8つもバラバラに存在するよりも、今の広範なMCPエコシステムがある方がずっとマシだよ。

サブエージェントのサポートが必要という意見には同感だ。私にとってもかなり基礎的な要素に感じる。

高性能なモデルが複数の低性能なモデルを指揮して作業を行い、さらに同じ高性能モデルを使って対抗的なレビューをサブエージェントに行わせる、というパターンは今後かなり一般的になるんじゃないかな。

個人的には、Piがそのほとんどをプラグインとして実装していることに少し混乱したよ。Eclipseでプラグインがバラバラに組み合わさって大混乱だった記憶があるからね。結局、自分のニーズのほとんどを最初からカバーしてくれるOpenCodeを使うことにしたよ。IDEやデスクトップ環境を標準構成のまま使うことが増えたのは、自分が年をとったせいかもしれないな。

PiがMCPをサポートしていないなんて全く知らなかった！使い始めたばかりの初心者なんだ。ツール類をセットアップしていて、データベース用のMCPを動かそうとしていたところだったんだ（今思えば少し苦労したけど、それらの接続を構築・維持するのは自分の責任だと思い込んでいたよ）。

あと、振り返ってみると、トップページの最初のアイコンに「No MCP」と書いてあるみたいだね。なぜ見落としたのか自分でも謎だよ。

この記事を読んでどれだけ驚いたことか！

この「codemode」というのが一体何なのか、まだ混乱している。モデルはすでにbashや一般的なUnixツールをチェーンさせる学習を受けていて、それが驚くほど上手い。なぜその能力を使わないようにしたいんだろう？単にモデルに直接シェルを使わせたくない場合の権限管理の問題なのかな？

これは最も簡単な判断だったし、自分を含め多くの人が3月[0]の時点でそうしていたよ。当時、インフルエンサーたちはMCPを「オワコン」と叫んで反MCPの波を作っていたけどね（Garry Tanを含む、テクノロジー界の著名な面々もたくさん）。3月のSNSを見れば、あらゆるテック系インフルエンサーがMCPを死んだものと決めつけ、CLIこそが勝者だと持ち上げていた（セキュリティ、可観測性/テレメトリ、デプロイや運用の容易さといった妥当な議論を完全に無視してね）。

2026年3月の直接の引用[1]：

もしあなたが、この（MCPの死に関する）議論の多くがニュアンスを欠いていて、単なる誇大広告に過ぎないということにまだ納得していないなら、現在のAIインフルエンサーによるFOMO（取り残される不安）のハイサイクルにまんまと乗せられたことにおめでとうと言っておくよ。インフルエンサーたちが注目を集めて金を稼ぐために、次の新しいネタに飛び移ったときにまた会おう。

AIエンジニアリングと導入が、ソロ開発者や「自分にとってうまくいくか」という単一のスタンスを超え、「チームにとって何が機能するか」という段階に進んだとき、なぜMCPが必要になるかはかなり自明だった。特にエンタープライズの文脈ではね。人々が犯した最大のミスは、チームのワークフローや運用のスタックではなく、自分自身のワークフローやローカル環境のスタックで考えてしまったことだ。また、MCPのステートレスなHTTPモード（そう、3月の時点ですでに存在していたんだ。2026年7月28日の仕様改訂で、これが今後の主な焦点として優先されただけだ）が、ローカルのstdioとどう違うのかという理解も欠けていたね。

今の最大の不満は、OpenAIがいまだにMCPのPrompts仕様[2]を実装しておらず、一般的に主要なクライアントが仕様の一部を中途半端にしか実装していないことだ。

自分は適切なCLIがない場合にMCPを利用するためにmcporter[0]を使っている。これはMCPをシェルコマンドとして公開してくれるものだ。エージェントは標準のシェルプリミティブを使って構成される。ツールの戻り値がJSONなら？jqにパイプすればいい。

MCPをサービスを呼び出す特別な手段としてではなく、エージェントと同じ方法でツールを実行できるのも利点だね。デバッグ時には本当に重宝するよ。

まだMCPがよくわからない。skill + CLIでできないことって何があるの？正直、hax (https://usehax.dev) を使っているけど、スキル機能がなくて困ったことは一度もないよ。

最近、MCPは単なるコーディングツール以上のものだと気づいた。例えば、rcmd、Clop、Lunarといった複雑なmacOSアプリ[0]に実装して、自然言語で設定できるようにしたんだ。

だから、ローカルのQwenとPiさえあれば、こんなことができるようになる：

• ウェブサイトの素材フォルダにドロップしたPNGを最適化して、同じ名前のwebpに変換するようにClopを設定して
• HDDを接続したらすぐにCrankでTime Machineバックアップを開始して、完了したら通知して
• rcmdを押しながらファジー検索をして、cmuxエージェントのペインにフォーカスしたい

BetterTouchToolのMCPは素晴らしいよ。ネイティブのSwiftUIビューを作成して、それをホットキーやトラックパッドジェスチャにバインドできる。その膨大なmacOS自動化ツールとプライベートAPIを活用すれば、エージェントに「コンピューター操作（Computer Use）」をさせられるんだ。

これらのツールをゼロからコーディングして、アプリが長年磨き上げてきたのと同じ耐障害性を持たせるには、もっと高性能なコーディングモデルが必要になるだろうね。

MCPのおかげで、Crank[1]がcrontabやlaunchd、週に一度実行するスクリプトの代わりを完全に果たしてくれている。前もできなかったわけじゃないけど、自動化の内容を記述するだけで、信頼性高く、UIで目に見える形で実行できるようになったのは本当に楽になった。面倒な壁がなくなったんだ。

現時点で私たちがMCPについて考えているのは、インテリジェントなツール発見機能を備えたOpenAPIに近いものであるべきだということだ。つまり、ツールは構造化されたデータを返し、そのドキュメントと説明によって発見可能であるべきだ。

OpenAPIこそがすでに「インテリジェントなツール発見」（それが何であれ）そのものだよ。OpenAPIは文字通り「構造化されたデータを返す」し、「ドキュメントと説明によって発見可能」だ。

一度でいいから、何を話しているのかちゃんと理解した上でMCPを説明している人を見てみたいものだ。

強く信じていた考えを改めただけでなく、それを公に隠さずに認めたチームに拍手を送りたいね。

リンクされているArminの投稿は金言だよ：

「…トピックについて非常に強い意見をぶつけられたとき、そのトピックに関する理知的な議論には、すでに時代遅れになったり、今の会話には全く関係ない議論が含まれていることが多い」

(https://lucumr.pocoo.org/2016/11/5/be-careful-about-what-you-dislike/)

これ2016年の記事だぜ！今の時代、たった1週間前の自分の立場を主張し続けているだけで、もう時代に取り残されている可能性があるんだ。