Skip to main content
Glama
rush-db

RushDB MCP Server

Official
by rush-db

findRecords

Read-only

Search and filter records with structured queries, including metrics, grouping, and relationship traversal. Use for listing or answering data questions in RushDB MCP Server.

Instructions

Primary read/query/list/search tool for records. Use findRecords to find records, search records, list records, retrieve matching records, filter records, or answer questions from data. Use this instead of exportRecords unless the user explicitly asks for CSV/export/download. Search records with a structured SearchQuery. BEFORE building any query with dates, metrics, groupBy, relationship traversal, or vector search — call getSearchQuerySpec to load the complete syntax reference. INTENT: metrics/analytics request (count/total/sum/avg/breakdown/top N by metric) → MUST include select + groupBy. NEVER fetch raw records to count/sum manually. RESPONSE: { data:[...records], total:N } — for simple "how many" read total directly; no count select needed. HARD RULES: (1) NEVER set limit when select is present — restricts the record scan and produces mathematically wrong results. Omit limit for all metrics queries. (2) labels contains root records only; put related labels inside where traversal blocks with $alias when referenced. (3) groupBy never accepts alias-only values like "$record"; use "$record.name" or a select key. (4) Ambiguous/incomplete named references should use $contains on a display property confirmed via schema discovery, not exact equality. (5) Related-count rankings keep the requested parent/entity as root; count the related alias and order desc for most/more or asc for least/less/fewer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skipNoNumber of records to skip
limitNoMax records for listing queries (default 10, max 1000). NEVER set when select is present — restricts the scan and produces wrong results.
whereNoFilter conditions. Field names must match exactly what findProperties/getSchemaMarkdown returns. Exact match can be field: value or field: { $eq: value }. For incomplete named references, prefer $contains on a display property confirmed via schema discovery instead of exact equality. For the complete operator reference (string/number/boolean/datetime/vector/$eq/$exists/$type/logical/$alias/$relation incl. multihop hops/$cycle/$id) call getSearchQuerySpec.
labelsNoFilter by record labels
selectNoMap of output-key → select expression. Supports: $sum, $avg, $min, $max, $count, $collect, $timeBucket, math, and references. See getSearchQuerySpec for full select/groupBy/collect/timeBucket reference.
groupByNoTwo modes: (A) Dimensional — "$alias.propertyName" strings, one row per distinct value; (B) Self-group — select key names, collapses to one row. Do not use alias-only values such as "$record" or "$related". Call getSearchQuerySpec for full reference.
orderByNoSorting configuration: key = field, value = asc|desc

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes
totalYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.0.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, non-destructive), and the description goes well beyond it: documents the response shape { data, total }, the metric-vs-listing distinction, the limit-with-select hazard, label/traversal scoping semantics, and the groupBy alias restriction. These are non-obvious behavioral traps an agent could not infer from annotations or schema.

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?

Front-loaded with purpose and the routing decision, then organized into INTENT/RESPONSE/HARD RULES blocks that are easy to scan. Slightly bloated by the synonym list ('find records, search records, list records, retrieve matching records, filter records') and some overlap between the description's response shape and the existing output schema.

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?

For a 7-parameter query tool with nested objects, rich annotations, and an output schema, the description covers everything needed to call it correctly — intent routing, prerequisite spec lookup, response shape, and five failure-mode rules. Nothing material is left to inference.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds cross-parameter rules the schema cannot express: never set limit when select is present, labels contain root records only with related labels nested via $alias, and groupBy rejects alias-only values. It stops short of 5 because much of the per-parameter operator detail merely points back to getSearchQuerySpec.

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?

States a specific verb and resource ('Primary read/query/list/search tool for records') and enumerates the query intents it serves. It explicitly names the sibling it is not (exportRecords) and the prerequisite sibling (getSearchQuerySpec), so an agent can route without opening a schema.

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

Usage Guidelines5/5

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

Explicit when-to-use rules: use this rather than exportRecords unless the user explicitly asks for CSV/export/download, and call getSearchQuerySpec before building date/metric/groupBy/traversal/vector queries. Also gives intent-based routing (metrics request → select + groupBy) with a negative instruction ('NEVER fetch raw records to count/sum manually').

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