Codex只看到MCP第一页工具，检查nextCursor是否被继续请求

服务器注册了几十个工具，Codex却只能调用前面一部分。第一份 tools/list 响应已有 nextCursor，服务端日志却没有第二次带游标的请求，就要检查客户端发现工具时是否读完分页。

已核对的具体实现是Codex CLI 0.140.0，以及0.155.0的旧协议模式。前者工具发现路径只请求一次；后者虽然使用分页收集函数，却在 Legacy 分支把返回游标置为空。不能据此认定所有后来版本或所有MCP客户端都有同样行为。

工具少了，与游标无效分别判断

第一响应有工具列表和 nextCursor，只表示本页成功。后续请求要把那个字符串原样放到 params.cursor 中。下面是第二页请求的形状，page-2 是示例，应替换为本次服务器返回的真实值：

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {
    "cursor": "page-2"
  }
}

MCP 2025-11-25把游标定义为不透明字符串。客户端不能假定它就是偏移量，不能解析、修改，也不应跨会话保存后复用。页面大小由服务器决定，不能用“返回数量小于100”推断已经结束。

先用已有的受控连接记录确认三件事：第一页确实有游标；第二页能在相同连接条件下按游标返回；Codex建立可调用目录时没有请求这一页。若第二次请求实际已经发出而服务器返回 -32602 Invalid params，就另查游标、会话与服务端分页实现，不能继续按“客户端没有跟随”处理。

有的界面能浏览全部工具，最终模型工具目录却受另一条发现路径影响。应同时比较服务端分页结果和当前客户端的可调用目录，不能仅凭配置中列出了服务器，或者初始化成功，就推断所有工具已加载。

在0.140.0中，读取第一页之后就映射为工具定义；0.155.0的旧协议分支则丢弃 response.next_cursor。因此重启服务器、给工具换名字或改工具参数schema，都不会改变这一条分页逻辑。

如果自己维护客户端，应将页结果逐次合并，直到没有下一游标，并保留总超时、目录数量限制和重复游标保护。每页都重新给足完整超时，可能把一次工具发现拖成无界等待；服务器重复返回同一游标时也不能无限循环。

对工具总量已知且可控的服务器，可以暂时把页容量调整到足以容纳这份列表，再核对客户端的目录预算。这个办法依赖具体服务器支持，也不适合无限放大页面或把大量无关工具一次塞给模型。

开启新的MCP协议功能可能进入另一分页分支，但协议切换还会影响其他配置服务器。不能为了修复一个列表，全局开启2026-07-28功能而不检查其余服务器是否支持。版本升级也应以正式包和对应旧协议分页实现为准，目前这里没有据此确定一个普遍适用的修复版号。

验收时选择原先在后页、且不会修改业务数据的工具，确认它进入目录并可按权限调用，同时检查其他服务器没有失去连接。只有工具总数增加，仍不足以证明原来的目标工具可用。若工具列表请求因旧会话404而中断，可以接着查失效会话恢复；退出时跨Task报错则查连接上下文清理顺序，这两种故障不由增大页容量解决。