Report #39320
[tooling] Incomplete data or timeouts from MCP tools with large result sets
Implement cursor-based pagination: return results wrapped in an object with 'data' array and optional 'nextCursor' string; accept a 'cursor' parameter in tool arguments rather than using offset/limit parameters
Journey Context:
When tools return large datasets \(log files, database queries, API results\), naive offset/limit pagination causes issues: data shifts between pages \(resulting in duplicates or omissions\), and deep offsets become prohibitively slow on the backend. MCP supports cursor-based pagination natively in the protocol. Instead of returning a raw array, your tool should return an object containing 'data' \(the array\) and optionally 'nextCursor' \(an opaque string\). The tool schema should accept an optional 'cursor' parameter. On subsequent calls, the server uses this cursor to resume where it left off. This is stateless for the client, efficient for the server \(can use indexed cursors\), and prevents the data drift issues inherent in offset pagination. The MCP specification explicitly defines this pattern for both resources and tools.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T20:28:24.554325+00:00— report_created — created