Skip to main content
Glama

Query bounded rows from a staged statistical dataset

query_dataset
Read-onlyIdempotent

Return only bounded selected rows using literal equality filters.

There is no SQL, shell, filesystem, network-function, extension, or mutation surface. A safe default limit applies when limit is omitted.

Page with offset: rows come back in the dataset's stored order, and next_offset in the response is the absolute offset to pass as the next call's offset.

next_offset is null when there is no next page to ask for, which is not the same as having received everything. Check truncated too: null with truncated: false means the matches are exhausted; null with truncated: true means rows remain that this byte budget cannot reach, and min_bytes_required says what budget would.

Args: dataset_id: Id returned by stage_url select: Optional list of columns to return (defaults to all columns) where: Optional {column: value | [values]} literal-equality row filters limit: Optional max rows to return (a safe default applies when omitted) offset: Optional absolute zero-based row offset; pass back next_offset max_bytes: Optional smaller byte budget for this response; it can only lower the server ceiling, never raise it response_format: Which channel carries the rows. "auto" (default) means no preference and lets the server decide; "text" sends them as CSV in the text channel only, "structured" as typed rows only, "both" in both. If you got a summary but no rows, call again with response_format="text".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
whereNo
offsetNo
selectNo
max_bytesNo
dataset_idYes
response_formatNoauto

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsNo
columnsNo
truncatedYes
next_offsetYes
limit_sourceYes
matched_rowsYes
applied_limitYes
returned_rowsYes
max_bytes_ceilingNo
min_bytes_requiredNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses detailed behavioral nuances: there is no mutation or extension surface, pagination uses absolute offsets, next_offset null does not mean all rows were received, truncated and min_bytes_required clarify byte-budget limits, and max_bytes can only lower the server ceiling. This is rich and accurate.

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

Conciseness5/5

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

The description is relatively long but every sentence earns its place: it front-loads the core behavior, then covers safety constraints, pagination, byte-budget semantics, and parameter meanings in a well-organized format. The structure makes the complexity navigable without redundancy.

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

Completeness5/5

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

Given the tool's complexity, seven parameters, and pagination edge cases, the description is complete. It covers invocation semantics, response interpretation, error recovery guidance, and behavioral constraints. The existence of an output schema does not undercut the value of the pagination and truncation context provided.

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

Parameters5/5

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

The schema description coverage is 0%, so the description carries the full burden for parameter meaning. The Args section explains all seven parameters, including subtle semantics like select defaults, literal-equality where filters, safe default limits, offset passing, max_bytes constraints, and the response_format channel behavior. This fully compensates for the schema gap.

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

Purpose5/5

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

The description states a clear verb and resource: return bounded, selected rows using literal equality filters. It also explicitly separates itself from broader execution surfaces ('no SQL, shell, filesystem...'), making its scope unambiguous relative to sibling tools.

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

Usage Guidelines4/5

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

The description provides clear practical guidance on pagination with offset/next_offset, safe default limits, byte budgets, and response_format recovery tips. It does not explicitly name sibling alternatives or state when to prefer this tool over them, but the usage context is strong enough to guide correct invocation.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources