Skip to main content
Glama
Sign In
Scormave

Gramps Web MCP

by Scormave
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Get Relations

get_relations
Read-only

Explain how two people in a Gramps family tree are related by naming person 2's relationship to person 1, including closest and all found relationships with common ancestors.

Instructions

Explain how two people are related, read as 'person 2 is the X of person 1' (e.g. 'third cousin twice removed', 'husband'); the order matters, and swapping handle1 and handle2 gives the inverse term, such as 'wife' instead of 'husband'. Returns both people with Gramps IDs, the closest relationship with the generations from each person to the common ancestor, then every relationship found, closest first, with its common ancestors (up to 10 by name, any more by handle), all in one response without paging. Searches blood relatives up to 15 generations plus spouses, a fixed depth. Unrelated people get a 'Not related' message, the same person twice is reported as such, and a missing person returns a not-found message. Find both people first with search. To list a whole line of ancestors or descendants use get_person_tree.

Input Schema

NameRequiredDescriptionDefault
handle1YesPerson 1, the one the relationship is told from. Handle or Gramps ID (e.g. I0001), resolved automatically; find it with search or list_objects.
handle2YesPerson 2, the one whose relationship to person 1 is named. Handle or Gramps ID (e.g. I0001), resolved automatically; find it with search or list_objects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.3.0
    • changedInput schema / properties / handle1 / description
      Previous value: -"First person handle. 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: +"Person 1, the one the relationship is told from. Handle or Gramps ID (e.g. I0001), resolved automatically; find it with search or list_objects."
    • changedInput schema / properties / handle2 / description
      Previous value: -"Second person handle. 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: +"Person 2, the one whose relationship to person 1 is named. 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 only declare a safe read; the description goes well beyond by disclosing the 15-generation search depth, the 10-common-ancestor naming cap with handle fallback, no paging, and ordered results. It also enumerates edge-case behaviors (unrelated, same person twice, missing person) so the agent can interpret non-happy-path responses.

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 the direction rule, the most error-prone part, and every sentence carries information. It is a dense single block that would scan better as short clauses, but nothing is wasted.

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 carries the return-value burden and does so: both people with Gramps IDs, the closest relationship with generation counts, then all relationships closest-first with common ancestors. Nothing an agent needs to call or interpret it correctly is missing.

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 both handles are already documented, but the description adds real meaning beyond it: the order-dependence and the fact that swapping handle1/handle2 yields the inverse term ('wife' instead of 'husband'). That is genuinely useful semantics not spelled out as clearly in the schema.

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 ('explain how two people are related') and immediately pins down the directional semantics with a concrete example ('third cousin twice removed', 'husband'). It is clearly distinguishable from lineage siblings like get_person_tree, which it explicitly names.

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?

Gives a prerequisite ('Find both people first with search') and an explicit alternative with its selecting condition ('To list a whole line of ancestors or descendants use get_person_tree'). An agent knows both when to reach for this tool and when not to.

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