Piは、従来公に示していたMCPへの否定的な姿勢を転換し、Model Context Protocolへの対応を中核機能に追加した。この統合は、エージェント実行基盤がツールを読み込み、連携させる仕組み全体の再設計と結び付いている。開発者らは、MCPの改善に加え、Piがそれとは別に必要としていた機能も、この変更に反映されていると説明した。

Piでは以前から拡張機能を通じてMCPを利用できたが、新しい実装では製品本体の正式な対応機能となった。チームは、会話中のツールの遅延読み込みや推論設定の変更など、新しいモデル機能を管理するには、拡張機能だけでは十分な情報を得られなかったと説明した。中核機能に取り込むことで、Piは、モデルが直接利用できるツールと、連携処理を担う層を通じて使うことを想定したツールを区別できるようになった。

この連携層はCodemodeと呼ばれる。Piはこれを、エージェントがツール呼び出しを発見し、実行順序を決め、組み合わせることのできるJavaScriptサンドボックスと説明している。利用可能な操作をすべて一度にモデルに提示する代わりに、プログラム可能な環境を通じてツールを公開し、連携処理の状態をセッションの会話記録に保持できる。PiはMCPが設定されるとCodemodeを自動的に読み込み、ユーザーはこれとは別に、既定のツールとして有効にすることもできる。

この設計は、異なるツールをまたいだ組み合わせが依然として扱いにくい場合があるという、チームがMCPに対して抱き続けてきた問題意識に応えるものだ。Piの開発者らによると、多くのMCPサーバーは、大量のツール一覧をモデルのコンテキストに直接入れ、主としてテキストの結果を返すシステム向けに設計されている。同チームが望む方向性は、構造化された出力と、ツールの説明や文書に基づく賢い探索を備えた、APIのエコシステムに近いものだ。

この構成では、MCPが機能を公開するための標準的な方法を提供し、Codemodeがそれらの機能をつなぎ合わせる実行空間を提供する。Piは、小型のランタイムをWebAssemblyとして配布し、サンドボックスで制約を設けられることがJavaScriptの利点だとしている。チームはまた、構造化されたMCPツールが将来提供すべき組み合わせやすさの基準として、よく知られたコマンドラインユーティリティーの連携性を挙げている。

開発者らは、今回の統合によってすべての制約が解消されるとは主張していない。サーバー側の慣行や実行基盤ごとの手法の違いが、依然として信頼できる組み合わせを妨げているという。そのためMCPをサポートする決定は、プロトコルを完成済みの解決策とみなすものではなく、小規模なエージェントシステムに向けて、こうした慣行の形成に参加しようとする試みでもある。

ユーザーにとって直近の変更点は明快だ。更新したPiでは、正式な対応機能としてMCPツールに接続できる。より大きな意味を持つのは、それに伴うツールの構成だ。Piは、ツール探索、構造化データ、サンドボックス内での連携処理により、すべてのツール定義や中間結果で作業用コンテキストを埋め尽くすことなく、エージェントが幅広いツール群を使えるようになると見込んでいる。