Describe the bug
GitHub Copilot CLI does not follow MCP pagination when the server returns a nextCursor in the tools/list response. Only the first page of tools is loaded; subsequent pages are silently ignored. This violates the MCP specification which defines cursor-based pagination for tool listing.
Affected version
v1.0.68
Steps to reproduce the behavior
Reproduction
- Connect to an MCP server that returns more tools than fit in a single page
- The server returns page 1 with a
nextCursor field indicating more tools are available
- GitHub Copilot CLI never requests the next page, tools from page 2+ are missing
Evidence
MCP gateway returns a valid nextCursor (opaque) in the first tools/list response:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"tools": [
/* ... 30 tools ... */
],
"nextCursor": "AQICAHj..."
}
}
Per the MCP specification, the client MUST send a subsequent tools/list request with cursor set to the nextCursor value to retrieve remaining tools.
Expected behavior
GitHub Copilot CLI should follow pagination by sending additional tools/list requests with the cursor parameter until the server returns a response without nextCursor, then merge all pages into the complete tool set.
Additional context
MCP Specification Reference
From the MCP spec:(https://modelcontextprotocol.io/specification/draft/server/utilities/pagination):
Operations Supporting Pagination:
tools/list - List available tools
Implementation Guidelines:
- Clients SHOULD treat a missing
nextCursor as the end of results
- Clients SHOULD support both paginated and non-paginated flows
- Clients MUST treat cursors as opaque tokens
The spec defines that when a response includes nextCursor, the client continues paginating by issuing a request with "cursor": "<value>" until no nextCursor is returned. Not doing so results in an incomplete tool set.
Impact
Any MCP server that paginates its tool list will have tools silently missing in GitHub Copilot CLI.
Describe the bug
GitHub Copilot CLI does not follow MCP pagination when the server returns a
nextCursorin thetools/listresponse. Only the first page of tools is loaded; subsequent pages are silently ignored. This violates the MCP specification which defines cursor-based pagination for tool listing.Affected version
v1.0.68
Steps to reproduce the behavior
Reproduction
nextCursorfield indicating more tools are availableEvidence
MCP gateway returns a valid
nextCursor(opaque) in the firsttools/listresponse:{ "jsonrpc": "2.0", "id": 1, "result": { "tools": [ /* ... 30 tools ... */ ], "nextCursor": "AQICAHj..." } }Per the MCP specification, the client MUST send a subsequent
tools/listrequest withcursorset to thenextCursorvalue to retrieve remaining tools.Expected behavior
GitHub Copilot CLI should follow pagination by sending additional
tools/listrequests with thecursorparameter until the server returns a response withoutnextCursor, then merge all pages into the complete tool set.Additional context
MCP Specification Reference
From the MCP spec:(https://modelcontextprotocol.io/specification/draft/server/utilities/pagination):
The spec defines that when a response includes
nextCursor, the client continues paginating by issuing a request with"cursor": "<value>"until nonextCursoris returned. Not doing so results in an incomplete tool set.Impact
Any MCP server that paginates its tool list will have tools silently missing in GitHub Copilot CLI.