Skip to main content
Glama

Read next SQLite query batch

db_query_next
Read-only

Fetch the next batch of rows from a retained SQLite streaming query iterator to continue processing large result sets without re-running the query.

Instructions

Read the next rows from a retained SQLite streaming query iterator.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
maxRowsNo
deviceIdNo
sessionIdYes
deviceNameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.0

TDQS

C2.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The phrase 'retained streaming query iterator' usefully signals server-side session state that persists across calls, but the description does not disclose drain/termination behavior or lifecycle coupling to db_query_close.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the key qualifiers ('next', 'retained', 'streaming') front-loaded. It is not padded, though it is arguably too terse for a 4-parameter stateful tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a stateful iteration tool with no output schema and 0% schema description coverage, the description leaves critical gaps: how batches are bounded, how completion is signaled, and how the sessionId relates to db_query_start/db_query_close. Annotations cover only the safety profile, not the iteration contract.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 4 parameters, so the description must carry the load, and it adds nothing: sessionId's required-ness and origin, maxRows' default of 500 and max of 100000, and the deviceId/deviceName roles are all unexplained. An agent must guess that sessionId comes from db_query_start.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Read) and resource (next rows from a retained SQLite streaming query iterator), which clearly distinguishes it from db_query_start, db_query_sessions, and db_query_close among the siblings. It does not explicitly name which sibling precedes it, but the 'next' framing makes the pagination role inferable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description never says when to call this versus db_query_start, db_query_close, or db_execute, nor that a prior db_query_start session must exist. Nothing states termination conditions or what to do when the iterator is exhausted.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools