Skip to main content
Glama
Sign In
Scormave

Gramps Web MCP

by Scormave
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Find Duplicates

find_duplicates
Read-only

Find possible duplicate people in a Gramps Web family tree by matching names across spellings and gender forms, then review returned pairs before merging.

Instructions

Find people entered twice in the tree: pairs with the same given name (the first word of one's among the other's, so Мария pairs with Анна Мария) and surname in any spelling (Cyrillic or Latin letters, so Мария, Марья and Maria, or Kowalski written in Cyrillic; ё and pre-reform letters, Latin accents, Polish w, sz and cz) and in the male, female or daughter's form (Kowalski and Kowalska, Novák and Nováková, Hájek and Hájková, Kazlauskas, Kazlauskienė and Kazlauskaitė, Ozols and Ozola, Papadopoulos and Papadopoulou, Kovács and Kovácsné), not of the other gender, without different patronymics, born and dead at most five years apart, and neither dead before the other was born. People with a patronymic but no surname pair by given name and patronymic when their birth years or parents can be compared. Spouses, and a person and their parent, grandparent or earlier ancestor, are never paired. Pairs born at most two years apart, or children of the same parents without two years to compare, are possible duplicates; the others are similar pairs. Each call reads every person of the tree, up to 20000, so a tree of a few thousand people takes 10 to 20 seconds. Returns how many people were compared and the pairs, possible duplicates first and then by how close the births are, numbered across pages; each person with Gramps ID, handle, birth, death and parents. Nothing changes: compare a pair with get_object, and merge it with merge_objects only after the user confirmed they are one person. create_person and create_records run the same check on the people they create; to find one name, use search.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many pairs to show, 1–100 (default 20); other values are clamped.
offsetNoHow many pairs to skip, to show the next ones (default 0).
surnameNoOnly pairs where one of the people has this surname, in any spelling or form: Kowalski also finds Kowalska and Kowalski in Cyrillic letters, and Novák also finds Nováková.
personHandleNoOnly pairs with this person. 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. Addedv2.9.1

TDQS

A4.5/5.0
Behavior5/5

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

Beyond readOnlyHint/destructiveHint=false, it states 'Nothing changes', quantifies cost (reads every person up to 20000, 10-20s on a few-thousand-person tree), and explains the result ordering (possible duplicates first, then by birth proximity) and pagination. That is exactly the operational context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and cost are front-loaded and the closing routing sentences earn their place, but the middle is one sprawling sentence padded with redundant exemplification (six-plus gendered surname pairs, multiple transliteration edge cases). Fewer examples would convey the same rule.

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 read-only scan tool with no output schema, the description covers what is compared, how results are ordered and paged, the performance ceiling, and the required follow-up workflow (verify, then merge). An agent has everything needed to call it and act on the output.

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 coverage is 100%, so limit, offset, surname and personHandle are already fully documented, and the description adds little beyond 'numbered across pages'. The surname filter's spelling-tolerance is explained in the schema itself, so the description's long surname exposition is mostly duplicated rather than additive.

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 opens with a specific verb and resource ('Find people entered twice in the tree') and immediately defines the matching semantics: given name containment, surname spelling variants, gendered surname forms, birth/death date windows, and exclusion of spouses and ancestors. It is unmistakably distinct from search, list_objects, and the create_* siblings that reuse the same check.

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 gives explicit routing: use search to find a single name, compare a pair with get_object, and merge with merge_objects only after the user confirms. It also discloses that create_person and create_records run the same duplicate check, which tells the agent when this tool is redundant.

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