Skip to main content
Glama
ianderso

familysearch-mcp

by ianderso
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

search_records

Read-only

Search historical records by name, dates, relatives, record type, or collection to locate ancestors when names are misindexed or spelled differently.

Instructions

Search historical records by name, events, relatives, type or collection.

Beyond a person's own name and dates, two kinds of criteria matter:

Relationship criteria. Searching for a man by his wife's or his father's name is how you find him when his own name was misindexed, mis-spelled or abbreviated to an initial. An indexer who mangled "Chesebrough" often got the wife's "Mary" right.

Scoping. Restricting to a record type or a single collection turns a search of the whole archive into a search of one register, which is what you want once you know which register should hold the entry.

Pass at least one name. Everything else narrows.

Requires an access token.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoMaximum results to return (1-100).
exactNoRequire names and places to match exactly. Off by default, because indexed spellings vary and fuzzy matching is usually what you want. Turn it on when a common name returns noise.
givenNoGiven name(s) of the person sought.
looseNoRank by similarity instead of requiring every criterion to match. Off by default: FamilySearch treats a search term as a scoring hint unless told otherwise, so a filter that does not filter is the surprising behaviour.
offsetNoResults to skip, for paging.
surnameNoSurname of the person sought.
birth_yearNoApproximate birth year.
death_yearNoApproximate death year.
birth_placeNoBirth place, free text.
death_placeNoDeath place, free text.
record_typeNoRestrict to one kind of record: birth, marriage, death, census, immigration, military, probate or other.
father_givenNoFather's given name(s).
mother_givenNoMother's given name(s).
spouse_givenNoSpouse's given name(s).
collection_idNoRestrict to one collection, by the id search_collections returns. Scoping to a collection is how you search a specific register rather than the whole archive.
marriage_yearNoApproximate marriage year.
father_surnameNoFather's surname.
marriage_placeNoMarriage place, free text.
mother_surnameNoMother's surname, usually her maiden name.
spouse_surnameNoSpouse's surname.
residence_placeNoA place the person is known to have lived.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly, openWorld), so the description adds context beyond them: it discloses the access-token requirement and explains why fuzzy matching is the default and when exact becomes necessary. It does not describe result ordering or paging behavior, but the auth and matching-behavior disclosures are meaningful additions.

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 purpose, then splits into named sections (Relationship criteria, Scoping) with the mandatory rule last. The 'Chesebrough'/'Mary' anecdote is slightly padded but illustrates a real edge case. Overall tight for the amount of guidance conveyed.

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?

For a 21-parameter, zero-required search with no output schema, the description supplies the missing decision framework and the auth prerequisite. It leaves pagination and result shape unstated, but those are minor against the strategic guidance it does provide.

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 parameter docs already carry the load; baseline would be 3. The description adds strategic meaning on top by framing two whole parameter families — relationship criteria (spouse/father/mother names) and scoping (record_type, collection_id) — explaining why an agent would use them rather than just what they are.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search historical records') and enumerates the criteria axes (name, events, relatives, type, collection). It distinguishes itself from get_record by being a search, but does not explicitly differentiate from sibling searches like search_collections or search_places, which is where an agent could plausibly misfire.

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?

Gives real strategic guidance: use relationship criteria when the subject's own name was misindexed, and scope by type/collection to narrow to a single register. 'Pass at least one name. Everything else narrows.' is a clear usage rule. It stops short of naming alternative sibling tools to prefer in other cases.

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