Skip to main content
Glama
Sign In
Scormave

Gramps Web MCP

by Scormave
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Get Person Tree

get_person_tree
Read-only

Retrieve a person's ancestors or descendants up to 10 generations deep, including names, kinship labels, and birth/death places. Use for genealogy research and family tree exploration.

Instructions

List a person's ancestors or descendants up to 10 generations deep: one row per relative with the generation, an optional kinship label (Father's mother, Granddaughter), name, Gramps ID, birth and death with places, and handle. Ancestors follow every parent family, adoptive ones included; descendants follow the children of every family where the person is a parent, so relatives not linked that way are missing, and someone reached by two lines is listed once. generations counts steps from the person (1 = parents or children); each extra one costs another round of reads, so start with the default 3. For how two given people are related use get_relations; for dated events around one person use get_timeline; for one full record use get_object. A missing person returns a not-found message.

Input Schema

NameRequiredDescriptionDefault
personYesThe person to start from. Handle or Gramps ID (e.g. I0001), resolved automatically; find it with search or list_objects.
directionYesancestors (parents, grandparents, …) or descendants (children, grandchildren, …).
generationsNoHow many generations to walk, 1–10 (default 3); other values are clamped.
kinshipLabelsNoWhen true (default), add kinship text such as Father's mother or Granddaughter. When false, show only generation numbers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.3.0
    • changedInput schema / properties / direction / description
      Previous value: -"Tree direction: ancestors | descendants."New value: +"ancestors (parents, grandparents, …) or descendants (children, grandchildren, …)."
    • changedInput schema / properties / generations / description
      Previous value: -"Number of generations to include (default: 3, max: 10)"New value: +"How many generations to walk, 1–10 (default 3); other values are clamped."
    • changedInput schema / properties / person / description
      Previous value: -"Root person handle or Gramps ID. Handle or Gramps ID (e.g. I0001). Handles are opaque strings from the API. Gramps IDs (like I0001, F0023) are auto-resolved to handles. Find handles with search() or list_objects()."New value: +"The person to start from. Handle or Gramps ID (e.g. I0001), resolved automatically; find it with search or list_objects."
  2. First observedv2.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, non-destructive, closed-world), and the description goes well beyond them: it explains which lines are traversed, that ancestors include adoptive parent families, that relatives unlinked that way are omitted, that a person reached twice is listed once, and that each extra generation costs another round of reads. The documented not-found message is a useful error-behavior disclosure.

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?

Information-dense and front-loaded with purpose, traversal semantics, and alternatives in that order. The first sentence is a long compound run-on, which slightly hurts readability, but no clause 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?

With no output schema, the description takes on the full burden and does so: it enumerates the row fields (generation, kinship label, name, Gramps ID, birth/death with places, handle), documents traversal edge cases, cost per generation, and the missing-person response. Nothing an agent needs to call it correctly is absent.

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, but the description adds real interpretation: 'generations counts steps from the person (1 = parents or children)' clarifies what the number means, and it explains the cost implication of raising it. kinshipLabels is also described in semantic terms beyond the schema's mechanical default note.

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 ('List a person's ancestors or descendants'), including the depth cap and the row-level output shape. It explicitly separates itself from get_relations, get_timeline, and get_object, so an agent can pick it without opening any 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?

Names three sibling tools with the exact condition that selects each ('for how two given people are related', 'for dated events around one person', 'for one full record'). It also recommends starting with the default 3 generations, giving concrete usage advice rather than just coverage.

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

Deploy Server

Other Tools