Page through large results
Every list tool that can return an unbounded number of rows is paginated the same way: ask for a
page size with first, and walk forward with after.
Read the first page
Section titled “Read the first page”list_pages(project_id, first: 20)The response carries the rows plus two things you need for the next call:
{ "totalCount": 214, "pageInfo": { "hasNextPage": true, "endCursor": "YXJyYXljb25uZ…" }, "pages": [ … ]}Read the next one
Section titled “Read the next one”Pass the previous response’s endCursor back as after:
list_pages(project_id, first: 20, after: "YXJyYXljb25uZ…")Repeat while pageInfo.hasNextPage is true.
The rules
Section titled “The rules”afteris an opaque cursor, not a page number and not an offset. It only means “continue after this row”. Do not construct one, do not increment one.totalCountis the size of the whole result set, not of the page you got.- There is no backward pagination. Forward only.
Which tools paginate
Section titled “Which tools paginate”| Tool | Default first |
|---|---|
list_projects | 20 |
list_pages | 20 |
list_project_run_history | 20 |
list_agentic_tickets | 20 (max 100) |
list_journeys and list_journey_groups return the project’s full set.
Run history gets long fast
Section titled “Run history gets long fast”list_project_run_history includes every scan your CI reports through b8e ci, which is one entry
per push. On an active repository that is thousands of entries. Take the first page and only walk
back if the answer is not in it.