Databricks SQL MCP Row Limits and Query Timeouts for AI Agents

Why agent-issued SQL needs explicit limits

A person writing SQL usually knows roughly how much data to expect and notices when a query runs too long. An agent does neither. It can generate a query without a filter, request every column of a wide table, or retry a slow query several times. Three problems follow. A very large result set can fill the model's context window and degrade later reasoning. A long-running query can hold warehouse resources that other workloads need. And an agent workflow can stall while it waits on a call that never returns in a useful time.

These are different problems, and they are not solved at the same layer. A row limit mainly protects the model context. A timeout mainly protects warehouse capacity and workflow progress. Treating both as a single setting in one place tends to leave one of them unaddressed.

Row limits: where they are enforced matters

A row limit can be applied in three ways: by rewriting or constraining the query before it runs, by instructing the platform to stop returning rows past a threshold, or by trimming the result after it arrives at the tool. These differ in reliability. A limit applied inside the query or by the platform reduces the work done and the data moved. A limit applied only in the tool wrapper bounds what the agent sees but does nothing about the cost of producing the full result.

The second question is whether the caller can override the limit. If the tool accepts a limit argument from the model, the model can raise it. Treat any limit the agent can set as a request, not as a control. The enforced ceiling should live in configuration the agent cannot modify.

The third question is how truncation is communicated. A result that is cut off silently looks like a complete answer, and an agent may draw conclusions from a partial sample. The tool response should state plainly that rows were omitted, how many were returned, and that the data is incomplete.

Timeouts: client cancellation is not query cancellation

Timeouts also exist at several layers, and the important distinction is whether the query stops running when the timer fires. A timeout enforced where the query executes ends the work and frees resources. A timeout enforced only in the client or tool can end the wait while the query continues to run. For agents, this gap is costly because a retry can start a second copy of an expensive query while the first is still consuming capacity.

Set the tool-side wait shorter than or equal to the execution-side limit, and make sure a tool-side timeout triggers an explicit cancellation request rather than simply abandoning the call. Then confirm by testing that a cancelled call leaves nothing running.

Agent-side limiters are a related and well-documented pattern. Research on agent behavior describes limits expressed as maximum rounds, parallel query limits, maximum thinking time or token budgets. Parallel query limits and round limits are particularly relevant here, because they bound how many statements an agent can have in flight at once.

Handling truncated and timed-out results in the agent

The following are design suggestions rather than fixed standards. They address the most common failure modes.

Return structured status with every response: whether the result is complete, the number of rows returned, and a reason code if it is not. Keep the message the model reads short and unambiguous, such as "result truncated at the configured limit; refine the filter or aggregate." Avoid returning partial rows without that marker.

On a timeout, do not let the agent retry the same statement unchanged. Prefer a message that suggests narrowing the query, and cap the number of retries in the runtime. For large questions, steer the agent toward aggregation, sampling or a pre-built view instead of raw row retrieval.

On identity and audit, platform-native permissions and query records show which identity ran a statement, but they describe the query, not the agent's decision to call the tool. NIST's NCCoE has published a concept paper on software and AI agent identity and authorization, which reflects how much attention agent identity is receiving. Teams should decide early what evidence they need at the tool-call layer, such as which agent requested what, and what the outcome was.

Runtime policy on individual MCP tool calls

Native settings define limits, but they are configured per layer and rely on each layer being set correctly. A runtime policy applied in the execution path adds a consistent decision point for every tool call. Trussed enforces policy in the execution path across models, agents, tools and MCP servers. For individual tool calls, the available actions are allow, redact, block, rate limit and escalate for human approval. In the context of SQL access, that means a call can be allowed within agreed bounds, blocked when it falls outside them, rate limited when an agent issues too many statements, or escalated when a request needs a person to approve it.

The second contribution is evidence. Enforcement generates audit-ready evidence of what the agent was allowed to do and what was decided on each call. This complements platform query records rather than replacing them. It is enforced at runtime, not reviewed after the fact, and it is scoped to individual interactions and tool calls. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency, which matters for a regulated enterprise with data location requirements.

A useful evaluation test is simple: for any query an agent ran last week, can you show which policy applied, what the decision was, and who approved it if approval was required?