What it does
The `tasks/list` method is a Requestor-initiated JSON-RPC call that asks the Receiver to return all Task objects the caller is authorized to see. The Requestor sends a `tasks/list` request, optionally including a `cursor` parameter for paginated traversal. The Receiver checks the caller's authorization context, filters the task set accordingly, serializes the matching Task objects into a `tasks` array, and returns an optional `nextCursor` string if more results exist beyond the current page. A missing or null `nextCursor` signals the final page.
Before issuing this call, the Requestor must confirm the Receiver advertised the `tasks` capability during the `initialize` handshake. If the capability is absent, the call must not be sent — the Receiver is permitted to return a `-32601 Method not found` error or simply never register the handler. Authorization is enforced server-side, so the returned array may be a strict subset of all tasks in the system; callers should never assume completeness.
Ordering of results is not guaranteed by the specification unless the Receiver documents a stable sort. Callers that cache task lists must treat any mutation notification (such as `notifications/tasks/updated`) as a signal to invalidate or refresh, because a stale cursor from a previous page walk may skip or duplicate tasks if the underlying set changes mid-pagination.
When to use
For task management UIs.
When NOT to use
In hot paths — use targeted tasks/get when you have the id.
Notes
Capability gate is mandatory
Check that the server's `capabilities.tasks` object is present in the `initialize` response before calling `tasks/list`. Sending the request to a server that did not advertise this capability will result in a `-32601 Method not found` error, which is not retryable — the feature is simply unavailable.
Pagination with cursor is opaque
The `cursor` value returned in `nextCursor` is an opaque string; never parse, increment, or construct it manually. Pass it verbatim as the `cursor` param in the next request. When the field is absent or null in the response, you have reached the last page and must stop iterating.
Authorization silently filters results
The Receiver returns only tasks the caller is authorized to view — it does not error on inaccessible tasks. If your integration expects a specific task to appear and it is missing, verify the session's authorization scope rather than assuming the task does not exist.
Race conditions during pagination
Task creation, deletion, or status changes between page fetches can cause a task to appear on multiple pages or be skipped entirely. If consistency is critical, record the task IDs seen and de-duplicate client-side, or re-fetch from the first page after any `notifications/tasks/updated` notification arrives mid-walk.
SDK list helpers may auto-paginate
Several MCP SDK wrappers expose a higher-level list helper that internally follows `nextCursor` until exhausted, returning a flat array. Check whether your SDK does this before writing your own loop — double-paginating will either error or silently return only the first page depending on how the SDK handles a missing cursor argument.
Request parameters
| Name | Type | Purpose |
|---|---|---|
| cursor | string? | Pagination cursor. |
Response fields
| Name | Type | Purpose |
|---|---|---|
| tasks | Task[] | Tasks visible to the caller. |
| nextCursor | string? | Pagination. |
Examples
List tasks
{ "method": "tasks/list" }Common mistakes
❌ Returning other users' tasks
✅ Enforce auth-context filtering.