Dify 社群提出 MCP 分頁修補，工具探索可能無聲漏掉第二頁以後的工具

Dify 社群於 10 月 10 日回報一項 MCP 工具探索缺陷：MCPClient.list_tools() 取得第一頁後直接回傳工具清單，未使用回應中的 nextCursor。回報者以 1.17.1 與當時 main 的原始碼重現；若伺服器將工具分頁提供，後續工具便可能無聲消失。這是本地後端模組測試，尚非完整 Dify 部署的端到端驗證。問題回報

最小案例使用 Dify 原生用戶端、工作階段與 JSON-RPC 型別，搭配記憶體內的模擬伺服器。第一頁提供 alpha 與游標，第二頁預備提供 beta；實際只收到一次請求，結果僅有 alpha。若第一頁為空但仍有下一頁，回傳清單也會是空的。回報指出，用戶端只讀取 response.tools，底層工作階段方法則沒有游標參數。重現細節

MCP 分頁規範將 tools/list 列為支援分頁的操作。伺服器決定每頁大小，用戶端應支援分頁與非分頁流程，並將 nextCursor 原樣放入下一次請求的 params.cursor；游標必須視為不透明字串，不應解析或修改。因此，連線成功與第一頁正常回應，仍不足以證明工具清單完整。MCP 分頁規範

修補提案 #43842 為工作階段加入可選游標，讓用戶端逐頁累積工具並保留順序；遇到重複或循環游標時拋出錯誤。作者回報七項新增測試及二十九項既有測試通過，也涵蓋後續頁認證失敗後重新連線、從第一頁重取的情況。不過認證與傳輸邊界使用模擬，完整後端、Docker 與資料庫整合尚未驗證，提案仍等待審查。修補與測試

對工程團隊而言，這代表代理可見的候選工具可能取決於伺服器分頁方式，進而限制任務可用能力；此影響是依探索流程作出的推論，尚無公開任務成功率量測。接入大型工具目錄時，可先比對伺服器清單與 Dify 取得的名稱，並測試空白首頁及重新連線情境。後續應追蹤修補合併、正式版本，以及真實分頁服務的整合結果。