工具清單越長，Agent 就越能完成工作嗎？先看一個具體任務：找出最近七天仍未處理的支援案件，依建立時間由舊到新排序，只回傳前十筆。它需要查詢、分頁、篩選與排序；其中多數步驟不需要模型逐筆閱讀資料。

Earendil 在 2026 年 9 月 29 日發布〈“You Said No MCP!”〉，說明原本不支援 MCP 的 Pi 為何將它納入核心：團隊重新評估了協定與工具組合方式，並引入 JavaScript Codemode。這是產品團隊對自身決策的說明，本文沒有在本機安裝 Pi 驗證。

我的判斷是：評估 Agent 整合時，應把「找到工具」與「組合工具」分開驗收。能連上十個系統，卻仍要讓模型搬運每一筆中間資料，整合成本只是換了一個位置。

把工具接上，還沒有解決資料搬運

假設查詢回傳五百筆案件，Agent 先讀完整結果，再挑出未處理項目，最後重新寫出十筆摘要。這條路徑把模型同時當成查詢規劃者、資料管線與排序器。只要資料增大，輸出截斷與欄位抄錯就值得納入驗收。

Anthropic 在 2025 年 11 月的工程文章區分兩種上下文成本：預先載入大量工具定義，以及讓中間結果反覆經過模型。它提出以程式介面使用 MCP 工具，按需取得定義，並在執行環境先處理資料。

這讓驗收問題變得具體：查詢五百筆後，回到模型的是否只有十筆必要欄位？排序是否由確定性的程式完成？還是只是把原本的完整 JSON 換成一段同樣長的自然語言？

後者可能讓單次輸出比較好讀，卻沒有建立可重用的資料介面。當下一步需要比對案件 ID 或合併另一個來源時，又得重新解析文字。

結構化輸出是組合契約

MCP 的 2025-11-25 Tools 規格提供 structuredContent，以及描述結構化結果的 outputSchema。這些欄位讓工具可以交付機器可處理的結果；並非所有 server 都因此自動回傳相同格式。

對案件查詢而言，我會先約定以下契約。這是本文設計的概念範例，不是 Pi 或 Linear 的實際 API：

{
  "items": [
    {
      "id": "SUP-42",
      "status": "open",
      "createdAt": "2026-09-29T08:00:00Z"
    }
  ],
  "nextCursor": null
}

此範例以固定查詢基準時間計算最近七天，區間為起點含、終點不含；未處理定義為 status = open，建立時間不代表最近一次客戶等待的起點。

這份結果刻意包含穩定 ID、狀態、可解析的時間與分頁游標。顯示文字可以額外提供，但下游排序不應依賴「前天建立」這種人類可讀描述。

我的停止規則是：

缺少必要欄位、時間無法解析或結果不符合 schema，就停止組合並回報契約錯誤。

不要讓模型猜出一個狀態，再把猜測送進下一支工具。介面錯誤越早被拒絕，越容易知道該修 server 還是呼叫端。

按需載入解決發現，Codemode 解決控制流程

Earendil 的說明把工具能否延後載入、能否只供 Codemode 使用，列為 Pi 核心需要處理的 metadata。這也解釋了為何團隊沒有只保留一般 MCP extension：宿主如何呈現能力，會影響整個工具使用體驗。決策原文

我會把這個設計拆成兩個可觀察的步驟：

  • 先依任務搜尋能力，取得需要的輸入、輸出與使用限制。工具名稱存在，不代表模型已理解它的契約。
  • 再用程式組合已確認的能力，處理迴圈、條件、排序與結果裁切。將必要結果交回模型，讓它負責解釋與下一步判斷。

Cloudflare 的 Code Mode 說明也以程式碼組合工具呼叫。這是一種 harness 的執行設計；採用 MCP 本身不會自動取得這種能力。

下面是查詢工作的概念流程，省略 SDK、取消與錯誤處理實作，不能直接當作 Pi 設定貼上執行：

搜尋案件查詢工具，讀取契約
確認唯讀權限、時間範圍與資料欄位
逐頁查詢，最多 5 頁，每頁最多 100 筆
若仍有下一頁：停止，回報資料不完整
驗證每筆資料的 ID、狀態與時間
只保留 status = open 且 createdAt 在最近 7 天內的案件
依 createdAt 由舊到新排序，同時間以 ID 升序排列
取得前 10 筆
只回傳 ID、建立時間與查詢完整性

頁數上限是本文的示範預算。遇到第五頁仍有下一頁時，不能把已取得的資料稱為完整排行榜；應縮小時間範圍，或改由來源端提供排序查詢。這個完成條件比「迴圈執行成功」更有用。

少進上下文，不代表少了資料責任

Earendil 描述的 Codemode 位於 harness 一側，與 shell 工具的執行位置有不同信任條件，且狀態屬於 session transcript。Pi 的 Codemode 說明

因此，評估執行環境時不能只問「有沒有 sandbox」。我會先確認生成的程式可接觸哪些工具、資料是否進入 transcript、結果留存多久，以及中途失敗能否取消後續呼叫。這些是部署需要回答的問題，本文不推定 Pi 已替每種整合完成相同治理。

Anthropic 也提醒，執行模型生成的程式需要隔離環境、資源限制與監控。工程說明中的資料減量方法，降低的是模型看到的內容；上游服務、工具執行環境與紀錄系統仍可能接觸原始資料。

本文先使用唯讀任務，就是讓組合成本與資料流可以單獨量測。若要加入修改案件、發送訊息或退款，應另行定義核准、重試與部分完成的處理方式。站內〈MCP 接得上不等於能放心執行〉專門說明這些授權邊界。

先比較同一條查詢，再決定要不要擴充

導入 Codemode 前，我會固定一份去識別化測試資料，包含多頁結果、相同時間的案件、缺失欄位與來源超時。用同一個問題比較逐次工具呼叫與程式組合，記錄四件事：

  1. 載入了哪些工具定義，實際用了哪些能力。
  2. 回到模型的資料量，以及整個任務的 token 與延遲。
  3. 前十筆結果是否符合預先計算的答案；時間相同時，以 ID 作固定次序。
  4. 分頁超出預算、schema 錯誤與超時時，是否明確標示未完成。

這是我建議的驗證方法，沒有實測數字。若資料量很小、只需一次呼叫，加入程式執行層可能增加維護成本；若任務需要多步篩選與資料串接，才有值得量測的收益。

下一次評估 MCP server，先挑一條唯讀工作，要求它交付可驗證的結構化結果。讓直接呼叫與程式組合跑過同一份資料，再依正確性、上下文成本與失敗行為選擇工具路徑。

當工具開始由多個團隊維護，還需要驗證上架、更新與撤權。〈Uber MCP Gateway 的啟示：把工具上架當成一次受控發布〉提供版本化核准、舊 schema 與撤權傳播的驗收案例。