DifyコミュニティがMCPのページネーション修正を提案、ツール探索で2ページ目以降が気づかれず欠落する可能性

Difyコミュニティは10月10日、MCPのツール探索に関する不具合を報告した。MCPClient.list_tools() は最初のページを取得した後、そのままツール一覧を返し、レスポンス内の nextCursor を使用していない。報告者は、バージョン1.17.1と当時のmainブランチのソースコードで再現した。サーバーがツールを複数ページに分けて提供すると、後続ページのツールが気づかれずに欠落する可能性がある。これはローカルのバックエンドモジュールテストであり、Dify全体をデプロイしたエンドツーエンド検証ではない。不具合報告

最小再現ケースでは、Difyのネイティブクライアント、セッション、JSON-RPC型と、メモリ上のモックサーバーを使用している。1ページ目には alpha とカーソルがあり、2ページ目には beta を返すよう準備されているが、実際にはリクエストは1回しか送信されず、結果には alpha しか含まれなかった。1ページ目が空で、次ページが存在する場合も、返される一覧は空になる。報告によると、クライアントは response.tools だけを読み取り、基盤となるセッションメソッドにはカーソルを渡すパラメーターがない。再現の詳細

MCPのページネーション仕様では、tools/list はページネーション対応の操作として定義されている。1ページあたりのサイズはサーバーが決定し、クライアントはページネーションあり・なしの両方のフローに対応する必要がある。また、nextCursor を変更せず、次のリクエストの params.cursor に渡す必要がある。カーソルは不透明な文字列として扱い、解析や変更をしてはならない。そのため、接続に成功し、最初のページが正常に返ってきただけでは、ツール一覧が完全であるとは確認できない。MCPページネーション仕様

修正提案 #43842 では、セッションに任意のカーソルを渡せるようにし、クライアントがページごとにツールを蓄積して順序を保つ。また、カーソルの重複やループを検出した場合はエラーを送出する。提案者によると、新たに追加した7件のテストと既存の29件のテストが通過した。後続ページで認証に失敗した後に再接続し、1ページ目から再取得するケースも対象に含まれる。ただし、認証とトランスポートの境界はモックを使用しており、バックエンド全体、Docker、データベースとの統合は未検証だ。提案はまだレビュー待ちとなっている。修正とテスト

エンジニアリングチームにとっては、エージェントが利用できる候補ツールがサーバーのページネーション方式に左右され、タスクで使える能力が制限される可能性がある。これは探索フローに基づく推論であり、タスク成功率の公開測定値はない。大規模なツールカタログを接続する際は、サーバー側の一覧とDifyが取得したツール名を照合し、空の先頭ページや再接続のケースをテストできる。今後は、修正のマージ、正式リリース、実際のページネーション対応サービスとの統合結果を追跡する必要がある。