`mcp2cli` calls `session.list_tools()` with no cursor and never loops on `nextCursor`, so on any MCP server whose tool count exceeds one page, everything past page 1 is silently missing from `--list` and from the generated CLI subcommands. No error, no warning — the tools just don't exist as far as the CLI is concerned.
This is normal MCP behavior, not a quirk of one server. The spec lists `tools/list` as a paginated operation, says page size is entirely up to the server, and says clients should loop until `nextCursor` is absent:
Page size is determined by the server, and clients MUST NOT assume a fixed page size.
Clients SHOULD: Treat a missing `nextCursor` as the end of results. Support both paginated and non-paginated flows.
Real example: stimmt/craft-mcp (a Craft CMS MCP server) pages `tools/list` at ~50 tools per response. A content-scope token against it exposes 54 tools total. `mcp2cli --list` shows 50 and stops — the missing 4 happen to be `get_entry`, `create_entry`, `update_entry`, `describe_entry_schema`, i.e. the core read/write tools most agents would reach for first. Calling one of them directly by name still works fine; they're just invisible to discovery. Confirmed by hand-paginating with `cursor` against the raw JSON-RPC endpoint — page 2 contains exactly those 4.
Where it happens: every `session.list_tools()` call in `mcp2cli/init.py` (at least the ones backing `--list` and the `list_tools` dispatch) passes no cursor and doesn't inspect `result.nextCursor`.
Suggested fix: wrap each of those call sites in a loop — call `list_tools(cursor=...)`, accumulate `result.tools`, keep going while `result.nextCursor` is set. Probably worth one shared helper (`_list_all_tools(session)`) rather than fixing each call site separately, since there look to be at least three.
`mcp2cli` calls `session.list_tools()` with no cursor and never loops on `nextCursor`, so on any MCP server whose tool count exceeds one page, everything past page 1 is silently missing from `--list` and from the generated CLI subcommands. No error, no warning — the tools just don't exist as far as the CLI is concerned.
This is normal MCP behavior, not a quirk of one server. The spec lists `tools/list` as a paginated operation, says page size is entirely up to the server, and says clients should loop until `nextCursor` is absent:
Real example: stimmt/craft-mcp (a Craft CMS MCP server) pages `tools/list` at ~50 tools per response. A content-scope token against it exposes 54 tools total. `mcp2cli --list` shows 50 and stops — the missing 4 happen to be `get_entry`, `create_entry`, `update_entry`, `describe_entry_schema`, i.e. the core read/write tools most agents would reach for first. Calling one of them directly by name still works fine; they're just invisible to discovery. Confirmed by hand-paginating with `cursor` against the raw JSON-RPC endpoint — page 2 contains exactly those 4.
Where it happens: every `session.list_tools()` call in `mcp2cli/init.py` (at least the ones backing `--list` and the `list_tools` dispatch) passes no cursor and doesn't inspect `result.nextCursor`.
Suggested fix: wrap each of those call sites in a loop — call `list_tools(cursor=...)`, accumulate `result.tools`, keep going while `result.nextCursor` is set. Probably worth one shared helper (`_list_all_tools(session)`) rather than fixing each call site separately, since there look to be at least three.