v0.9.0 tools/list pagination (page size 8) truncates non-paginating MCP clients (Cursor) to 8 of 14 tools — regression from v0.8.1

[davidwwu]

Version

codebase-memory-mcp 0.9.0

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

ui

What happened, and what did you expect?

After upgrading v0.8.1 → v0.9.0, my MCP client (Cursor) exposes only 8 of the 14 tools.

Cause: v0.9.0 made tools/list cursor-paginated at page size 8 (added in #657; confirmed in #826: "tools/list is cursor-paginated (page size 8 + nextCursor)"). Cursor doesn't follow nextCursor, so it registers only page 1. The 6 tools on page 2 — list_projects, delete_project, index_status, detect_changes, manage_adr, ingest_traces — never appear.

v0.8.1 returned all 14 tools in a single tools/list response, so the same client showed 14. So this is a regression for any MCP client that doesn't paginate tools/list.

Expected: all 14 registered tools available to the client, as in 0.8.1.

I understand the paginating server is spec-compliant and the strictly-correct fix is client-side (reporting to Cursor separately). But the page size (8) is below the tool count (14), and there's no local override (config list exposes only auto_index, auto_index_limit, auto_watch, ui-lang; no flag/env). Directions for discussion: make the tools/list page size configurable (e.g. config set tools_page_size N / CBM_TOOLS_PAGE_SIZE), or default it to ≥ the registered-tool count so a single page carries them all while keeping pagination for compliant clients.

Reproduction

printf '%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"probe","version":"0"}}}' \
  '{"jsonrpc":"2.0","method":"notifications/initialized"}' \
  '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' \
  '{"jsonrpc":"2.0","id":3,"method":"tools/list","params":{"cursor":"8"}}' \
  | codebase-memory-mcp

or on Windows PowerShell:

$env:CBM_CACHE_DIR = Join-Path $env:TEMP "cbm-probe"   # throwaway store; leaves your real data untouched
@'
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"probe","version":"0"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}
{"jsonrpc":"2.0","id":3,"method":"tools/list","params":{"cursor":"8"}}
'@ | & "$env:USERPROFILE\.local\bin\codebase-memory-mcp.exe" --ui=false
Remove-Item Env:\CBM_CACHE_DIR

Observed:

• id 2 → 8 tools + "nextCursor":"8": index_repository, search_graph, query_graph, trace_path, get_code_snippet, get_graph_schema, get_architecture, search_code
• id 3 → remaining 6, no nextCursor: list_projects, delete_project, index_status, detect_changes, manage_adr, ingest_traces
• Total unique = 14. A client reading only page 1 (Cursor) exposes 8; one following nextCursor gets 14.

Logs

N/A (protocol-level). Startup stderr shows msg=server.start version=0.9.0.

Diagnostics trajectory (memory / performance / leak issues)

N/A (not a memory/perf or indexing issue).

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[DeusData]

Thanks for the clear regression report. I am treating this as a 0.9.1-rc integration compatibility bug: the server can remain spec-compliant while still returning the full tool list for clients that do not paginate tools/list. PR #980 is linked as the current fix candidate, and review should focus on preserving explicit cursor pagination while restoring the default no-cursor behavior.