Every production MCP server for PostgreSQL needs result limits.
The dangerous part is not the limit.
It is returning the first 1,000 rows without making truncation impossible to miss. The query succeeded, the model received data, and a bounded sample becomes a confident claim about the full population.
Use independent budgets for:
- rows
- bytes
- statement and end-to-end time
- query cost
- concurrency
- total pages per logical request
Then make truncation a typed result state: completeness, reason, observed rows and bytes, stable ordering, and whether continuation is available.
Continuation tokens are also authorization artifacts. Bind them to the principal, tenant, approved operation, query digest, policy version, stable-order keys, snapshot, and expiry.
And choose semantics before adding LIMIT. A request for “top customers” cannot be answered from the first 1,000 invoice rows. It needs an approved aggregate operation over the complete scoped population.
The rule is simple: if the operation is incomplete, the model must not infer totals, rankings, maxima, or absence as if every row was examined.
Full guide: PostgreSQL MCP result limits and truncation
Top comments (0)