PRACTICAL FIELD GUIDE
Response count is not always the full table total
A returned count must be interpreted according to the API's response contract. Do not assume the number of returned records represents every matching row in the database.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Inspect the generated response shape and the request's limit and offset.
- Compare a full page with a shorter final page using controlled data.
- Label UI totals only when the API supplies the required total or your application calculates it reliably.
What this looks like
ILLUSTRATIVE EXAMPLE
A response contains 25 records and count 25 because that page has 25 rows. The table may contain many more.
A boundary to keep clear
Do not build a last-page calculation from a page count without verifying that it is a total count.
MCPBackend context
Use get_project_api or the dashboard's generated OpenAPI contract for your project's exact data-plane routes. Machine keys and end-user tokens have different access models. Treat error status and JSON code together, keep credentials out of URLs, and test against disposable records before changing real data.
Take the next step
Inspect the current project contract, try the change with disposable data, and verify the result through the same credentials your app will use. Record the expected response and one denied-access case before release.
Sources and further reading
These references explain the underlying protocols and design principles. For supported MCPBackend operations and exact request shapes, inspect your project’s generated API contract.