Is 500 rows a bug or is it deliberate?

Deliberate. It's a safety cap on raw SQL results (execute_sql), not a mistake. Without one, a forgotten LIMIT on a large table could pull hundreds of thousands of rows into the response — expensive in tokens, and often more than the AI or you actually needed.

Does this mean I can never see more than 500 rows?

You can see the full picture, just not as one giant row dump. Ask for a COUNT, a GROUP BY breakdown, or a specific LIMIT and ORDER BY (e.g. 'the 50 most recent') — those give you the real answer within the cap because they don't need every row returned to be correct.

Why isn't this a problem for query_table?

query_table is meant for browsing a slice of a table with simple filters, not full-table exports — it's a different tool with a different job. The row-cap concern is specifically about execute_sql, where the AI writes arbitrary SQL and could omit a LIMIT entirely.

If I actually need all 50,000 rows, what do I do?

That's usually not a chat-with-AI use case anymore — it's an export. Use your database client, a BI tool, or a scheduled job for full extracts. AI chat is for questions with an answer, not for moving bulk data.

How do I know a result was truncated and not just small?

A well-built gateway returns a notice alongside a truncated result — something like 'truncated to 500 of N rows, add a LIMIT or use an aggregate.' If you got exactly 500 rows back with no notice at all, ask your gateway whether it's telling the model when this happens.

AI Database Query Returns Only 500 Rows | Why

You asked for "all cancellations this year." You got back exactly 500 rows, no more, no explanation — and now you're wondering if that's genuinely all of them, or if something got cut off.

It got cut off. Most managed MCP gateways cap the rows returned by raw SQL at some fixed number — often 500 — and this is a deliberate safety feature, not a bug in your setup.

Why a cap exists at all

When the AI writes SQL itself (execute_sql, as opposed to query_table), nothing stops it from writing SELECT * FROM cancellations with no LIMIT clause. Against a table with a few hundred rows, that's harmless. Against a table with a few hundred thousand, that single query pulls the entire table into the response.

That's expensive in a way that's easy to underestimate: every one of those rows becomes tokens the model has to process to generate its next reply, on a plan that's very possibly metered by usage (see why your AI connector hit a daily limit for the sibling problem this same discipline helps avoid). A capped, truncated result with a clear notice is a far better failure mode than a technically-successful query that silently costs ten times what the question warranted.

What a good cap actually does

The row limit itself is the blunt part. The important part is what happens around it — a gateway that's doing this well doesn't just chop the result silently. It should:

Return the first N rows (500, in Synra's case) rather than erroring out entirely
Attach a clear notice: this was truncated, here's how many rows actually matched, and what to do instead
Leave the model able to act on that notice in the same conversation — retry with a LIMIT, or switch to an aggregate

Silent truncation with no notice is the actual failure mode to worry about — that's the version where you genuinely can't tell "500 rows because that's all there are" from "500 rows because that's the cap." A notice removes the ambiguity entirely.

How to actually get the answer you wanted

The fix isn't raising the cap — it's asking a question that doesn't need every row to be correct:

"How many cancellations this year?" → a COUNT, one row, no cap ever touched
"Cancellations by month" → a GROUP BY, a handful of rows, the real shape of the data
"The 50 most recent cancellations" → an explicit LIMIT 50 ORDER BY date DESC, exactly what you asked for, well under the cap
"All cancellations this year" → the request that hits the cap, because it's asking for a row dump instead of an answer

Most business questions are actually the first three shapes, even when phrased like the fourth. "Show me all the cancellations" usually means "help me understand cancellations," which an aggregate answers better than a 500-row table you'd have to read through anyway.

When you genuinely need all the rows

Sometimes you do want a real export — every row, no aggregation, for a report or a handoff. That's a legitimate need, but it's not really a chat-with-AI task anymore; it's a data export. Use a proper database client, a BI tool connected directly, or a scheduled job built for bulk extraction. Asking an AI chat interface to be your CSV export pipeline is fighting the tool's actual job, which is answering questions, not moving bulk data.

The short version

500 rows (or whatever your gateway's cap is) isn't the ceiling on what you can learn from your data — it's the ceiling on how much raw data a single chat answer will drag along with it. Ask for the count, the breakdown, or a bounded slice, and the cap never becomes a problem you notice.

Read-only MCP gateway with row caps and clear truncation notices on raw SQL: mcpserver.design.

Related reading: