A client paginating tools/list sends a nextCursor it cached yesterday. The server no longer recognizes that cursor and returns an error. How should both sides behave according to the pagination and caching rules?
Select an answer to reveal the explanation.
Short Explanation
A stale bookmark is like a page number in last year's edition — the pages have moved. Throw away what you copied and start reading from page one. The trap is treating the error as "no more pages."
Full Explanation
Pagination in MCP uses opaque cursors. Invalid cursors should result in error -32602, Invalid params, and servers should handle invalid cursors gracefully. The caching rules add the client side: if a cursor becomes invalid, for example when the server returns an error for a previously valid cursor, the client should discard all cached pages and re-fetch from the beginning, without a cursor. That avoids stitching together pages from different snapshots, since there is no cross-page consistency guarantee. Treating the error as the end of the list leaves the client with a stale, possibly incomplete set of tools; only a missing nextCursor signals the end of results. Editing the cursor violates the rule that clients must treat cursors as opaque tokens and must not parse or modify them or assume a format. Waiting for ttlMs and retrying the same cursor misunderstands TTL, which is a freshness hint for cached results and has no power to revive a cursor the server has discarded. Exam caveat: an empty-string cursor is still a valid cursor and must not be read as the end of the list. Operational check: simulate an invalid cursor and confirm the client clears every cached page of that list and issues a fresh tools/list with no cursor parameter.