Skip to main content
Glama
ianderso
by ianderso

get_ancestry

Read-only

Walk a person's pedigree back through generations using Ahnentafel positions to reveal ancestors and gaps in the community-edited FamilySearch tree.

Instructions

Walk a tree person's pedigree back through the generations.

Each person carries an Ahnentafel position: 1 is the person asked about, 2 and 3 their father and mother, 4 to 7 their grandparents, and so on -- so a flat list reads as a tree, and a gap is visible as a missing number.

The further back a pedigree runs the less of it is sourced. Lines beyond about five generations are frequently copied rather than researched, and a long unbroken pedigree is a reason for more suspicion rather than less.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
person_idYesFamilySearch person id to walk back from.
generationsNoGenerations to return, 1 to 8. The person is generation 1, their parents 2, grandparents 3.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover readOnlyHint and openWorldHint, but the description adds substantial context beyond them: it discloses the access-token requirement, warns that lines beyond ~5 generations are frequently copied rather than researched, and flags that the shared tree is community-edited with common same-named conflations. These are material behavioral traits an agent cannot get from structured fields.

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-loads the core action, then uses each following paragraph for a distinct purpose: output interpretation, sourcing caveats, and data-quality warnings. It is on the longer side and the sourcing-warning sentences could be tightened, but every sentence carries information rather than 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?

With no output schema, the description correctly compensates by explaining that the flat list is an Ahnentafel-ordered pedigree where a gap shows as a missing number, and it states the access-token prerequisite. Nothing essential for calling or interpreting the result appears to be missing.

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 both person_id and generations are already documented in the schema, including the generation numbering (person=1, parents=2, grandparents=3). The description's Ahnentafel explanation restates and elaborates the same numbering, adding little param-level meaning beyond what the schema provides, so the baseline 3 is appropriate.

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 with unambiguous direction: 'Walk a tree person's pedigree back through the generations.' The direction 'back' cleanly separates it from the descendant-oriented sibling get_descendancy, and the Ahnentafel explanation pins the exact scope without the agent needing the schema.

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?

It gives strong context for how to treat the result — 'a hint where to look, not evidence: follow it to a record and cite that' — which frames appropriate use. However, it never explicitly names alternatives such as get_descendancy (downward) or get_person_relatives (immediate family), so the routing decision is left to inference from the wording rather than spelled out.

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