エージェント構成を変更する前に、特にツールスキーマの割り当てについて、プロンプトトークン使用量を理解することが重要です。著者は、ほとんどのチームが所有権の欠如により、これらの基本的な質問に答えることができないと強調しています。Pi 1.0は、ツールスキーマの可視性をツールごとの設定に移行する、大きな変更である遅延ツールロードとCodemodeを導入しました。以前は、PiはMCPに抵抗していましたが、バージョン1.0では、ツール露出に関するメタデータの必要性からネイティブサポートが追加されました。このメタデータは、ツールがモデルに直接表示されるか、オンデマンドでロードされるか、またはCodemodeからのみ呼び出し可能かを決定します。ツールスキーマはコストがかかり、関連性に関係なく、すべてのリクエストでシステムプロンプトまたはツールブロックのトークンを消費します。このコストは、金銭的費用、モデルの注意力の低下、および再現性の低下として現れます。ベンダーの例では、これらの変更により、リクエストのプロンプトトークンが約40％減少することが示されています。Piの新しいメタデータにより、ツールは直接公開、遅延、またはCodemodeのみにすることができます。直接公開は頻繁に使用されるツール用、遅延はめったに使用されないツール用、Codemodeは出力のフィルタリングが必要な場合やツールを組み合わせる場合用です。モデルがサンドボックス内でツールを呼び出すコードを記述するCodemodeアプローチは、コンテキストウィンドウに入るものを変更するため、特に興味深いものです。しかし、著者は、サーバーが構造化データではなく非効率的にテキストブロブを返す場合、Codemodeはサーバー側の問題を解決しないと警告しています。チューニングの前に、ツールがロードされた状態とロードされていない状態でのコールドスタートプロンプトトークンを測定する監査が推奨されます。ツールを3つの公開カテゴリに分類すると、使用パターンが明確になり、不要なスキーマの肥大化が特定されます。ツールが名前で選択される必要があるかどうかの決定は、その配置を決定します。そうでない場合は、Codemodeまたは遅延に属します。使用頻度は、直接（頻繁）と遅延（まれ）の間を決定します。Codemodeはトークン数を減らすことができますが、サーバー側の効率は依然として懸念事項です。著者は、プロバイダーのトークナイザーを使用してトークン数を測定し、固定タスクの前後比較を実行することを強調しています。可視性は安全対策であり、モデルが見ることができないツールは誤って選択されることはありません。最後に、監査は、プロンプトサイズを増大させる利用されていないコネクタを特定するのに役立ちます。