A client paging through tools/list stops when it receives a result whose nextCursor is an empty string, and it later finds that some tools are missing. What went wrong?
Select an answer to reveal the explanation.
Short Explanation
A cursor is a sealed envelope; you don't judge it by how thin it looks. Even an empty string means 'there's more.' You stop only when nextCursor isn't there at all.
Full Explanation
MCP pagination uses opaque cursors rather than numbered pages. A response includes nextCursor only if more results exist, and clients SHOULD treat a missing nextCursor as the end of results. Clients MUST treat cursors as opaque tokens: they must not assume a format, must not parse or modify cursors, and must not make any determination based on the cursor value other than whether a non-null value was provided. The specification gives the exact example that an empty string is a valid cursor and MUST NOT be treated as the end of results. The client should have sent the next request with the empty-string cursor. Blaming the server assumes a base64 format and a minimum length that the specification never imposes; the server is free to encode position however it likes. Decoding the cursor to read a page count breaks the opacity rule and would fail as soon as the server changed its encoding. Page size is determined by the server, and clients must not assume a fixed page size, so there is no request parameter to enlarge it. Exam caveat: invalid cursors SHOULD produce error -32602, and when a previously valid cursor fails, caching guidance says the client should discard cached pages and restart from the beginning. Operational check: confirm the paging loop terminates only when nextCursor is absent and that an empty-string cursor triggers another request.