Repository navigation
Server should handle paginated requests #967
Description
Activity
I’d like to work on this, but wanted to check the scope first per
CONTRIBUTING.The approach I have in mind is to honor
params.cursorin the server-side list handlers that currently return the full list:tools/list,resources/list,resources/templates/list, andprompts/list.For the cursor, I’d use an opaque base64 token over a stable snapshot of the registration list, with invalid cursors returning JSON-RPC
-32602. Page size would be configurable on the server builder and default to the current behavior, so existing clients won’t see pagination unless it’s explicitly enabled.I’d also add tests following the record-evolution rules in
CONTRIBUTING.Does that match what you had in mind for the 2.1.0 milestone? If so, I’m happy to open a PR.
Hello @Zhuoxi2000 ,
You can check the following PR which implements a solution for the pagination: #140
Thanks @denniskawurek . I hadn't found #140 from the issue, since the PR predates it. I won't duplicate the work.
- marked Server list handlers ignore
cursorand never setnextCursor, and cannot be replaced #1128 as a duplicate of this issueon Sep 10, 2026
Expected Behavior
The server should handle paginated requests per specification.
Current Behavior
Currently, the whole list is returned on list requests.
Context
When a server contains big lists of tools, prompts, etc. the requests may put too much load on the server or take too long.
The code has TODOs at some of the affected places.