Pagination
There is no pagination. No cursor, no offset, no page token and no next link exists on any endpoint — a request returns one bounded set and that is all of it. Search caps at 25 results whatever you ask for; listing caps at 1,000. To read everything, filter into slices or take the manifest.
What limit actually does#
| Call | limit | Hard cap | Order |
|---|---|---|---|
/api/public/docs/search | 1–25, default 10 | 25 results, always | Relevance descending, ties broken by path |
/api/public/docs/list | 1–1,000, default 100 | 1,000 items | Path ascending |
MCP search_public_docs | 1–25, default 8 | 25 results | Relevance descending, ties broken by path |
MCP list_capabilities | 1–400, default 200 | 1,000 items | Path ascending |
limit truncates a finished result set; it does not select a page of one. Asking for a limit above the hard cap is not an error and does not get you more — the index refuses to return more than 25 search hits whatever the parameter says. The count field in a response is the number of items in *that* response, not a total for the corpus, so it is the wrong number to print as a headline.
Does Connect use a cursor model?#
No, and the reason is the size of the thing being paged. The corpus is around a thousand short documents. A cursor exists to walk a set too large to hand over at once; here the entire index fits in memory, is built in well under a second and is served as one file if you want it. Adding cursors would mean state to encode, invalidate and version, in exchange for nothing a filter cannot already do.
So the fields a paging client looks for are absent: no next, no next_cursor, no has_more, no offset, no page, and no Link header with rel="next". There is nothing to loop on, and a client written to loop until an empty page will loop forever on a full one.
Reading the whole corpus, two ways#
Take
https://connectbyjbrh.com/docs-manifest.jsonin one request.Result You have every public page — id, URL, title, summary, status — with no walk and no limit to work around. This is the right answer for anything bulk.
Or partition with the filters:
kind,status,channelandaudienceon/docs/list.Result Each slice is well under the cap, ordered by path and stable between calls, so slices concatenate into a complete set without overlap.
Fetch page bodies only for the ones you need, by
urlorid.Result Bodies are the expensive part; metadata for a thousand pages is cheaper than bodies for fifty.
For search specifically, the fix for *not enough results* is a better query rather than a deeper page. The index prefix-matches, so a stem finds its longer forms, and a term nothing contains is skipped rather than excluding everything — a two-word query with one unknown word still answers on the word it knows.
The ordering guarantee#
Listing is ordered by path, ascending, and that order is stable: the same filter returns the same sequence until the corpus itself changes. It is safe to diff two listings taken days apart.
Search is ordered by score, descending, with the page path as the tie-break so equal scores never wobble between calls. Scores are not comparable across queries and are not a percentage — treat one as a sort key and nothing else. A rebuilt index after a deploy can reorder results, which is why anything you need to return to should be pinned by url or id, never by position.
Questions#
How do I get results 26 to 50 of a search?
You cannot, and it is usually the wrong goal. Narrow the query, add a kind or status filter, or walk the listing endpoint, which is ordered and goes much deeper.
Is there a total count of pages anywhere?
Yes — /api/public/docs/status reports the corpus size and a breakdown by kind. That is a corpus total, not a match total for your query; no endpoint reports the latter.
Do the MCP tools paginate differently?
No. They call the same functions with the same caps, so the numbers in the table above hold there too. The defaults differ slightly, which changes how much comes back by default and nothing else.