「MCPはやらない」と言っていたPiが、MCPをコアに取り込んだ理由
Pi.dev: You Said No MCP
PiはかつてMCP非対応を公言していたが、最新版ではMCPがコア機能としてサポートされる。背景にはMCP自体の進化と、Codemodeの導入がある。MCPをJavaScriptサンドボックス上で動かすことで、ツール呼び出しの合成やコンテキスト効率が改善。MCPをOpenAPIに近い知的ツール発見の仕組みとして捉え直し、小さなハーネスでも活用できるよう関与していく狙いだ。
我々は、何かにポジティブな影響を与える最善の方法は、それを受け入れることだと考えている。
HNでの議論
344- alin23
最近、MCPはコーディングツールというよりずっと大きなものだと気づいた。たとえば、rcmd、Clop、Lunar のような自分の複雑な macOS アプリ [0] に実装して、自然言語で設定できるようにしている。
だからローカルの Qwen と Pi でも、こんなことが言えるようになった：
Clop を設定して、ウェブサイトの assets フォルダにドロップした PNG を最適化し、その近くに同じ名前の webp として変換して
HDD を接続したらすぐに Crank で Time Machine バックアップを開始し、バックアップが完了したら通知して
rcmd を押しながらファジー検索して cmux のエージェントペインにフォーカスできるようにしたい
BetterTouchTool には優れた MCP があり、ネイティブの SwiftUI ビューを作成してホットキーやトラックパッドジェスチャーなどにバインドできる。その膨大な macOS 自動化ツールとプライベート API を活用して、エージェントに Computer Use をさせられる。
そうしたツールをゼロからコーディングして、アプリが長年かけて磨いてきたのと同じフェイルセーフなロジックを実現するには、もっとずっと高性能なコーディングモデルが必要だろう。
たとえば MCP 以降、Crank [1] は crontab や launchd、週に一度実行する散らばったスクリプトの使用を完全に置き換えてくれた。以前にそれができなかったわけではないが、今は自動化を記述するだけで、確実に実行され UI で見える形になるのでずっと簡単だ。摩擦がなくなった。
[0] https://reddit.com/r/macapps/comments/1wkv0dy/mcp_in_macos_a...
- gk1
強く信じていた意見を単に変えただけでなく、それを非常に公にして、方針転換であることを隠さなかったチームに敬意を表する。
Armin のリンクされた投稿は金言だ：
「…ある話題について非常に強い意見に直面したとき、その話題に関する合理的な議論は、とっくに時代遅れになった、あるいはもはや厳密には会話に関係しない論拠を含んでいることがよくある。」
(https://lucumr.pocoo.org/2016/11/5/be-careful-about-what-you...)
しかもこれは2016年のものだ！ 今日では、たとえ一週間前に取った立場から議論していても、すでに時代遅れになっているかもしれない。
- CharlieDigital
これは最も簡単な判断で、私を含む多くの人が3月に下した[0]。MCPは死んだと主張する反MCPのインフルエンサーの波（Garry Tan を含む、テック界の非常に多くの著名人たち）の中でね。3月にはあらゆるソーシャルフィードのあらゆるテックインフルエンサーがMCPは死んだと叫び、CLIを勝者と戴冠していた（セキュリティ、可観測性／テレメトリ、デプロイと運用の容易さなどに関するあらゆる合理的な議論を完全に無視して）。
2026年3月の直接の引用[1]：
> この[MCPの死に関する]言説の多くがニュアンスを欠き、ただの誇大広告にすぎないとまだ納得していないなら、現在のAIインフルエンサーのFOMOヒップサイクルに乗せられたことをおめでとう。インフルエンサーが関連性を保ち、君の目と金を稼ぐために次なる瞬間の啓示へと移る6か月後にまた会おう。
AIエンジニアリングと普及が、ソロ開発者と単一ハーネスのスタック、つまり「自分にとって何がうまくいくか」対「自分のチームにとって何がうまくいくか」を超えて進めば、特にエンタープライズの文脈でMCPが必要になる理由はかなり明白だった。人々が犯した主な過ちは、チームのワークフローとチームの運用スタックではなく、自分自身のワークフローとローカルスタックの観点で考えたことだった。また、MCPのステートレスHTTPモード（そう、3月にはすでに存在していた。2026-07-28の仕様改訂で、今後は主要な焦点として優先されるようになっただけだ）とローカルの `stdio` に関する無知もあった。
今の私の最大の不満は、OpenAIが依然としてMCP Prompts仕様[2]の実装を拒否していることと、g […]
- _fw
彼らのMCPへの消極姿勢には共感するが、/何か/ は何もないよりはましだ。
著者が挙げる理由で最適ではない。しかしUSB-Cもそうだ。NVMEもそうだ。HDMIもそうだ。
これらの非常に成功した技術は、その欠陥にもかかわらず使われている。広く互換性があり、エンドユーザーにとって簡単だからだ。
だからMCPはどこにでもある。高性能でも堅牢でも均一でもないかもしれないが、時間とともに必ず良くなる。
そして、今ある広範なMCPエコシステムのほうが、LLMを何か役立つものにつなぐ7つか8つの異なる「最適な」方法よりもずっと欲しい。
- KronisLV
サブエージェントのサポートが必要だという点には同じ思いだ。それらはかなり基礎的だと感じる。
賢いモデルが複数の愚かなモデルを動かして作業し、その後、同じ賢いモデルでサブエージェントを使い敵対的レビューを行う、というのがかなり一般的なパターンになるだろうと推測している。
個人的には、Piがそうしたもののほとんどをプラグインとして持っていることに少し混乱した。Eclipseがどれほど酷いものだったか、多くのものが緩く噛み合うプラグインにすぎなかったかを覚えているからだ。結局、ほとんどのニーズを箱から出してすぐに満たしてくれるOpenCodeにした。これは自分が年を取ってきた兆しかもしれない。IDEやデスクトップ環境もどれもより素の状態に近いからね。
- abtinf
> 現時点でMCPをどう捉えたいかというと、インテリジェントなツールディスカバリーを備えたOpenAPIにはるかに近いものであるべきだ。つまり、ツールは構造化データを返すべきで、ツールはそのドキュメントと説明によって発見可能であるべきだ。
OpenAPIは「インテリジェントなツールディスカバリー」（それが何であれ）だ。OpenAPIは文字通り「構造化データを返し」、「そのドキュメントと説明によって発見可能」だ。
一度でいいから、自分が何を話しているのか分かっていると感じさせる言葉でMCPを説明する人を見てみたい。
- statenjason
適切なCLIが利用できないときにMCPを利用するためにmcporter[0]を使っている。MCPをシェルコマンドとして公開してくれる。エージェントは標準的なシェルプリミティブを使って組み立てる。ツールがjsonを返す？ jqにパイプすればいい。
もう一つの利点は、MCPをサービスを呼び出す特別な方法として扱うのではなく、エージェントとまったく同じ方法でツールを実行できることだ。デバッグ時に非常に価値がある。
- CamilleScholtz
MCPがまだ理解できない？ スキル＋CLIでできないことでMCPにできることは何？ hax（https://usehax.dev）を使っているけど、正直スキルが恋しいと思ったことは一度もない。
- NichoPaolucci
piがMCPをサポートしていないなんて知らなかった！ 新規ユーザーで、いじり始めたばかりだ。ツールを立ち上げていて、データベースのMCPの一つを動かそうとした（振り返ると少し面倒に思えたが、そうした接続を構築・維持するのは自分の責任だと思い込んでいたのだろう）。
もう一つの振り返りとして、「No MCP」がフロントページの最初のアイコンらしい。どうして見逃したのか分からない。
これを読んだときの驚きを想像してほしい！
- raincole
このcodemodeが何なのかまだ混乱している。モデルはbashや他の典型的なunixツールをうまく連鎖させるように訓練されている。不気味なほど上手い。なぜこの能力を活用しないようにしたいのか？ モデルにシェルを直接使わせたくない場合の権限管理の問題なだけなのか？