[BUG] Claude Desktop (macOS) ignores MCP tools/list pagination — tools past page 1 never load
What's wrong
The MCP client in Claude Desktop on macOS does not follow tools/list pagination. When an MCP server or gateway returns a paginated tools/list response with a nextCursor, Claude Desktop fetches only the first page and silently discards the cursor. Tools on subsequent pages are never registered, never appear in the session, and cannot be called. No warning is surfaced that tools were dropped.
This is the same MCP protocol non-compliance reported and triaged for the Claude Code CLI in #39586 and #59538 — the Claude Desktop MCP client has the identical defect. A related Desktop symptom was reported earlier in #50088 (Claude Desktop loading only a subset of an MCP server's tools) but was closed without the pagination root cause being identified.
Why I'm filing here
I reported this through the in-app Fin AI support chat in Claude for Desktop, which directed me to file it in this repo:
To help track this alongside the Claude Code fix you referenced, you can also file it on the Claude Code GitHub Issues since the desktop app shares some of the same infrastructure. When filing there, include: - Your desktop app version and macOS version - The exact behavior (single tools/list, nextCursor ignored) - Reference to issue #59538 that fixed this in Claude Code - Your AgentCore gateway setup details
So this is the Claude Desktop counterpart of the already-triaged Code-side bug: #59538 was closed as completed (fix shipped for Claude Code), but Claude Desktop still exhibits the same defect.
What should happen
Per the MCP specification, clients SHOULD support paginated list flows, and tools/list is a paginated endpoint. Claude Desktop should follow nextCursor until it is exhausted and register every tool:
cursor = None
all_tools = []
while True:
response = list_tools(cursor)
all_tools.extend(response.tools)
if not response.nextCursor:
break
cursor = response.nextCursor
Steps to reproduce
- Connect Claude Desktop to an MCP server (or gateway) that exposes more tools than fit on a single
tools/listpage, so the server returns page 1 with anextCursor. - Start a new chat.
- Only the page-1 tools are available. Tools on page 2+ are absent from the session and return "no such tool" if invoked.
- No follow-up
tools/listrequest carrying the cursor is ever sent.
Concrete example: An AWS Bedrock AgentCore gateway paginates tools/list at 30 tools/page and returns a nextCursor. Exposing more than 30 tools across the gateway's targets, only the first 30 register; tools 31+ are invisible and uncallable. The gateway's built-in search tool can see the page-2 tools, but invoking them fails because the client never registered them.
Impact
- Any MCP server or gateway that paginates
tools/listhas tools silently dropped, with no indication to the user that more exist. - It forces server authors to cap tool counts below the page size purely to keep everything on one page — a real constraint on tool design. This is especially painful in Desktop, where users connect managed remote connectors and don't control the page size, and don't want to wire up and re-authenticate a dozen small connectors just to stay under the limit.
- It breaks the multi-target gateway aggregation pattern, whose whole purpose is exposing many tools across targets behind one endpoint.
Environment
- Claude Desktop: 1.11187.4 (584005), build 2026-06-05
- OS: macOS 26 (Tahoe), Darwin 25.4.0
- MCP transport: remote (HTTP/SSE) connector
Related
- #39586 — Claude Code does not follow MCP tools/list pagination (nextCursor)
- #59538 — MCP tools on page 2+ of paginated tools/list dropped (closed as completed)
- #50088 — Claude Desktop loads only a partial MCP tool set (same symptom, closed without diagnosis)
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗