A transit-ops citation-lookup tool can match tens of thousands of records for a busy route and currently has no way to request results in pages, so every query either times out or silently returns an arbitrary small slice. What schema addition fixes this?
Select an answer to reveal the explanation.
Short Explanation
A phone book with no page numbers gives you some names and no way to see the rest. limit and cursor let the agent page through deliberately, batch by batch.
Full Explanation
When a query can match far more records than any single response should carry, the schema needs a way to express how much and from where. Without those parameters the tool has only bad options: attempt everything and time out, or return an arbitrary slice whose boundaries the caller can neither see nor control.
A limit parameter bounds the size of each response so the call completes predictably, and a cursor lets the caller resume exactly where the previous page ended. Together they turn an unbounded citation lookup into a sequence of bounded, resumable steps, and the agent can stop paging as soon as it has what the busy route actually requires.
Hardcoding the first ten matches with no continuation preserves the silent-discard behavior and merely fixes how much is discarded; removing filtering so the tool always returns the complete dataset makes the timeout strictly worse for exactly the high-volume routes in question; refusing to run whenever a query might match more than a hundred records makes the tool unusable for its main case, treating a scale problem as grounds for abstention.
Exam caveat: pagination bounds how many records return, which is a different problem from how much detail each record carries—a tool that matches many records and returns rich per-record payloads needs both controls. Operational check: run a high-volume route query, confirm the first page respects limit and returns a cursor, and that following the cursor yields the next distinct page with no overlap or gap.