Skip to main content
Glama
ianderso
by ianderso

query_objects

Read-only

Run server-side filters on Gramps collections for audits, such as finding uncited high-confidence claims or media with no description. Return just the fields you need, not whole records.

Instructions

Query any collection with a server-side filter. The workhorse for audits.

Use this instead of fetching a collection and filtering it yourself: whole-collection pulls are slow on any real tree, and the filter runs in the database. Typical audit questions it answers directly:

  • uncited high-confidence claims: citations where confidence >= 3 AND page = ""

  • documents with no image: sources where media_list.length = 0

  • anonymous media: media where desc = ""

To ask "what cites this source?" use get_backlinks -- a source has no citation_list, because citations point at IT, and reading citation_list on a source reports zero for every source in the tree.

Private records and living people come back as redacted stubs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gqlNoGrampsQL filter, applied server-side over the RAW object JSON. Single '=' for equality (NOT '=='), '~' for substring, '<list>.length' for sizes, combined with AND/OR. Examples: 'confidence >= 3 AND page = ""' (high-confidence citations with no locator), 'media_list.length = 0' (sources with no image), 'desc = ""' (undescribed media), 'description ~ "1871"'. TRAPS: a field the object lacks is not an error, it matches nothing -- event 'type' is one (use query_records). Booleans compare as 0/1: 'private = 1', never 'private = true'.
keysNoComma-separated fields to return, e.g. 'gramps_id,title,media_list'. Strongly recommended -- whole objects are large. NEVER build a write payload from a keys= result: writes replace the whole record.
pageNoPage of results, 1-based.
sortNoSort key; prefix '-' for descending (e.g. '-change').
limitNoMax rows to return.
handlesNoFetch these specific handles in one request.
gramps_idsNoFetch these specific gramps_ids (e.g. ['S0001','S0002']).
object_typeYesOne of: person, family, event, place, source, citation, repository, media, note, 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.5/5.0
Behavior5/5

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

Annotations already mark the operation as read-only, but the description adds important behavior beyond that: private records and living people are returned as redacted stubs unless include_private is requested. It also explains that filtering runs in the database, which sets performance expectations.

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?

The description is front-loaded with the core purpose and then structured with examples and an alternative-tool note. It is slightly redundant because the gql examples are also present in the schema, but the overall length is justified for a complex query tool.

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

Completeness4/5

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

Given the rich schema and read-only annotations, the description covers the most important missing context: server-side filtering, audit use cases, privacy redaction, and the get_backlinks alternative. It does not describe the response shape or pagination behavior, which is a minor gap because no output schema exists.

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 description coverage is 100%, so the schema already documents all parameters, including gql syntax, traps, keys, pagination, sorting, and handle/id lookups. The description reinforces the server-side filter concept and gives audit examples, but it does not add parameter semantics beyond what the schema provides.

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 specific verb and resource: query any collection with a server-side filter. It also differentiates the tool from the common manual approach of fetching and filtering client-side, and names the get_backlinks alternative for reverse-citation questions.

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?

It explicitly says when to use this tool instead of whole-collection pulls and when to use get_backlinks instead. The audit examples further clarify the intended use cases without leaving the agent to infer them.

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