Pagination

Every list read is bounded. A collection grows without limit over a project's life, so data_query and the REST list endpoints return at most limit rows. Always pass a limit; an unbounded list read is never the right call.

Paging is limit + offset. There is no cursor: next_cursor was deleted on 2026-07-24 because no endpoint in the platform ever produced one, while this page used to instruct callers to "follow next_cursor until has_more is false" — a loop that could never advance. Do not send a cursor; it is ignored.

{
  "name": "data_query",
  "arguments": {
    "project_id": "pr_acme",
    "collection": "learnings",
    "limit": 50,
    "offset": 50
  }
}

limit and offset are the same two query parameters on REST. The real path, rendered from the live resource spec rather than restated here, is on API Quickstart and each resource's own page under API reference.

The contract

• limit defaults to 20 and is clamped to 50. offset defaults to 0. Both are clamped server-side, so an out-of-range value is corrected, never an error.
• The response is { "items": [...], "has_more": <bool>, "request_id": "…" }.
• has_more is required on every list response and is the only signal that another page exists. Advance by adding limit to offset while has_more is true.
• where filters and a properties projection narrow a page before it is returned, which keeps each page small and cheap — prefer them to paging through everything.

data_query counts its own truncation

An unprojected data_query is additionally bounded by a byte budget, so a page can be shorter than limit. It always reports page_objects (how many rows the query fetched for this page) and returned_objects (how many are in this payload), plus limit_reached when the page filled its limit. Every one of these is a PAGE number — a floor, never a collection total. For a total, use the counting engine (metrics_list, or a /counts REST read) — never count a page.

See Reference / Conventions for ids, time, and money.