Skip to main content
Glama
Sign In

datatomcp

by com.datatomcp
OverviewDiscussionsAdmin

Query rows

query_rows
Read-onlyIdempotent

Return matching rows. Filter with where, choose columns with select, sort with order_by. Columns of linked datasets work as alias.column. At most 1,000 rows; page with offset.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "dataset_id": "<dataset_id>"
    },
    "name": "query_rows"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
whereNo
offsetNo
selectNo
versionNoThe dataset version from an earlier result's meta (or one listed in describe_dataset's versions). Pass it when you chain calls (distinct_values, then aggregate): the answer stays on that version even if the data was refreshed in between (meta then has stale: true and current_version). If that version is no longer kept, the call fails with source_changed.
order_byNo
dataset_idYesDataset id from list_datasets, e.g. ds_ab12cd34ef56

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety burden is lifted; the description still contributes real behavior by disclosing the 1,000-row ceiling and that paging is done with offset. It also discloses the alias.column syntax for linked datasets, which is a genuine capability hint not present in the schema. It stops short of describing the response envelope (rows plus meta, stale flags), which matters given there is no output schema.

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?

Three short sentences, each carrying a distinct clause, front-loaded with the outcome before the mechanics. Nothing is repeated from the title and no sentence is wasted.

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

Completeness3/5

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

For a seven-parameter read tool with no output schema, the description covers filtering, projection, sorting and paging adequately for a straightforward call. It omits the return shape (rows plus meta) and the source_changed failure mode when a stale version is requested, both of which an agent chaining calls would benefit from knowing.

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

Parameters3/5

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

Schema coverage is only 29%, so the description must compensate, and it partially does: where, select, order_by and offset are all given one-line semantics, and alias.column is explained nowhere else. But limit is never mentioned in prose even though the cap is the most important constraint, and version — the most subtle parameter, fully documented in the schema — is untouched here. This is above baseline but not full compensation for the coverage gap.

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?

The description opens with a specific verb and resource ('Return matching rows') and immediately enumerates the shaping operations (where, select, order_by), so the agent knows this is a filtered row-read. It does not name the sibling it is not — aggregate and distinct_values are the obvious alternatives for computed or de-duplicated results, and neither is referenced.

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

Usage Guidelines3/5

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

Usage is implied by the enumerated clauses: reach for where when you want to filter, select when you want fewer columns, order_by to sort. There is no explicit when-to-use or when-not statement, and no routing to aggregate for grouped results or distinct_values for unique values, which is the main ambiguity with this sibling set.

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

All datatomcp toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources