著者は当初、MCPとCLIのどちらが安価かを疑問に思っていましたが、それは間違った質問であることに気づきました。真の問いは、実際に生き残るアーキテクチャ要素は何かということになりました。初期分析では、MCPは生のCLIよりも1回の呼び出しあたりのトークンコストが大幅に低いことが明らかになりましたが、大規模なモノリスのスキーマオーバーヘッドは天文学的なものでした。重要な洞察は、無駄なスキーマ注入であり、これは実際の使用状況に基づいてスキーマをフィルタリングするゲートウェイによって解決できるということでした。著者は、プラグインとは異なり、MCPサーバーはライフサイクルから独立しており、自身の状態を回復できることを学びました。この認識により、サーバーはクライアントの終了を生き延びるのに対し、プラグインはその親の寿命を継承するという理解に至りました。コンテナ化は、環境固有のセットアップのための費用対効果の高いソリューションとして登場し、ターゲットごとの設定なしにさまざまなクライアントにデプロイ可能な単一イメージを提供しました。長いプルリクエストのライフサイクルは、アーキテクチャの選択のための決定木の重要性を浮き彫りにし、MCPサーバーの生存はクライアントから独立しているという認識につながりました。元の93ツールのモノリス、WSLごとのインストールスクリプト、および特定のgit-push MCPツールは破棄されました。著者は、アーキテクチャの決定は早期に行われ、失敗からは迅速に学ぶ必要があると結論付けました。改訂された戦略は、型付きスキーマを持つ構造にはMCPを、低オーバーヘッドの実行にはCLIを優先します。独立してデプロイ可能なように、ツールの数が限られた集中型サーバーが好まれます。コンテナは現在、クライアント間で一貫したスタックを提供するデフォルトのデプロイメント方法です。生き残ったアーキテクチャには、ライフサイクル管理のためのMCPゲートウェイ、実行のためのCLIブリッジ、および複数の集中型MCPサーバーが含まれます。