Skip to main content
Glama
ianderso
by ianderso

query_records

Read-only

Query Gramps collections server-side with columns, filters, sorting and relationship paths. Filter events by type and audit records with counts and cursor paging.

Instructions

Query any collection server-side, with columns, filters and sorting.

More capable than query_objects and the tool to reach for on an audit. It reads indexed columns, reaches arbitrary paths inside the stored object, and follows relationships — so "families where the mother died before the father" or "events whose place is in Ohio" are single queries.

It is the only way to filter events by type. GrampsQL cannot: the word is shadowed, so type = "Birth" silently matches nothing. Pass event_type here instead.

Returns rows plus a total count and a next_after cursor. Private records, living people and families with a living parent come back as redacted stubs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
afterNoCursor from a previous response's next_after, for paging past the first page.
limitNoMaximum rows (1-500).
whereNoConditions combined with AND. Each is {"column": <name or json_path>, "op": <op>, "value": ...}. Operators: eq, ne, lt, lte, gt, gte, like, regex, contains, in. Use "value_column" instead of "value" to compare two columns.
selectNoColumns to return. A plain column name, or {"json_path": [...], "as": "label"} to reach into the stored object. A path may cross a relationship: person->birth/death, family->father/mother, event->place. Omit for the default columns.
order_byNoSort keys, each {"column": ..., "direction": "asc" or "desc"}. json_path is not usable here.
event_typeNoEvents only. Filter by type name such as 'Birth' or 'Census'. Translated to the integer the tree stores, which is the only way event type is filterable at all.
where_exprNoAn expression instead of `where`, e.g. "surname == 'Smith'".
object_typeYesCollection to query: person, family, event, place, source, citation, repository, media, note, or tag.
include_privateNoShow living people and private records in full. Only when the user asks for them; they are withheld by default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-structured behavior: returns rows plus a total count and a `next_after` cursor, and that private records, living people and families with a living parent come back as redacted stubs. It does not cover permissions/rate limits, but the redaction and paging disclosures are substantive.

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?

Front-loads what the tool is and its key differentiator, then layers capability, the event_type gotcha, and return/redaction behavior. Every sentence carries an operational fact; none is filler.

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 9-parameter read tool with no output schema, the description compensates by describing the return shape (rows, total count, next_after cursor) and the redaction behavior. An agent has enough to call it correctly and interpret results reasonably.

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 the baseline is 3. The description adds meaning beyond the schema by explaining why `event_type` exists (the word is shadowed in GrampsQL, so plain filtering silently matches nothing) and constraining `include_private` to 'only when the user asks for them.' That is more than a restatement of the schema text.

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 ('Query any collection server-side') and immediately distinguishes itself from the sibling `query_objects` by capability. It also names the collection scope (person, family, event, etc.), so the agent can differentiate it from get_* and search_people 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?

Explicitly routes the agent: 'More capable than query_objects and the tool to reach for on an audit,' plus the when-to-use-for-events rule and the alternative (GrampsQL) that fails. Both the positive case and the substitution case are stated.

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