familysearch-mcp

An MCP server for genealogical research on FamilySearch: a historical place gazetteer, indexed record search, the page images behind the records, and reads of the shared family tree.

Nothing here writes to FamilySearch. The shared tree is community-edited and conflations of same-named people are common, so a tree result is a hint: follow it to the underlying record and cite that.

This is an independent project. It is not made, endorsed or supported by FamilySearch.

Credentials

This package ships no client id and never handles a FamilySearch password. Records, images and the tree need an access token from your own registered FamilySearch application; docs/AUTH.md explains why, and how to get one.

The gazetteer, the collection catalogue and the film browser answer without a token, so they work on a fresh install with no setup at all.

Install

uvx familysearch-mcp

That runs the server over stdio, which is how an MCP client starts it. You normally put it in the client's configuration rather than running it yourself.

Claude Desktop

{
  "mcpServers": {
    "familysearch": {
      "command": "uvx",
      "args": ["familysearch-mcp"],
      "env": { "FS_ENV_FILE": "/path/to/familysearch.env" }
    }
  }
}

Point at an env file rather than pasting the token into env. A token that lives in the client's config can only be replaced by editing it and restarting; a token in the file is picked up mid-session. With no token at all, leave env out and the anonymous tools still work.

Claude Code

claude mcp add familysearch -e FS_ENV_FILE=/path/to/familysearch.env -- uvx familysearch-mcp

Configuration

.env.example lists them with comments.

Tools

Twenty-eight tools. All of them read; download_image also writes the page it fetches to a local file.

Places

FamilySearch's Places API answers anonymously.

Records and collections

Page images

Shared tree — a lead, never a source

Every tool here reads a community-edited profile, and says so in its own description.

Setup

How it behaves

• The tree is not evidence. The tree tools read profiles anyone can edit. Use them to find records. get_person_sources is the most useful of them because it leads out of the tree towards a document.
• A comparison proposes; it never changes. compare_person takes your own names, events, relatives and sources for one person, reads the profile, and reports what agrees, what the profile lacks and what differs. Each proposed change comes as a packet: the source, the facts to tag it to, a draft reason with gaps for you to fill, and where on the website to make it. You make the change yourself, one at a time, after reading the record. It refuses anyone who may be living, and it never proposes combining profiles, removing anything, replacing a relationship or changing living status. See docs/COMPARE.md.
• A persona is not the record. A search returns one person's summary of what a record said; get_record returns the indexed fields behind it, and get_record_image the document itself. Read down that chain before citing.
• Jurisdictions move. search_places_at_date resolves a place as it was in a given year. Filing an 1820 record under the county that covers the ground today is a common and hard-to-spot error.
• Record search uses the website's search service. The API's own record search answers from a partial index that is almost all immigration records. search_records asks the service the FamilySearch website uses instead, with your token and a browser User-Agent, which that service requires. It is undocumented and FamilySearch can change or close it; docs/API-NOTES.md has the comparison.
• Full-text search is a machine reading. fulltext_search asks the website's full-text service, on the same footing as record search: your token, a browser User-Agent, and an undocumented route. Its text is handwriting recognition, so names and numbers are often misread; each hit gives the passages that matched and the page's image ark, and the page is what to read and cite. Only some collections and volumes have been machine-read, so no result proves nothing. Every word must match unless you write OR, because the service otherwise matches any one of them.
• The Catalog describes holdings, not records. get_catalog_entry reads the entry the website's catalog page reads, on the same footing as record search. For each film it reports the DGS number, which get_film_image and fulltext_search take, and asks the image store whether your account may view it and how many images it holds. A DGS is not the microfilm number; a film may be restricted or never digitised; and a description is a cataloguer's summary, so read the images and cite them.
• Search criteria filter, loosely unless exact. FamilySearch treats a search term as a ranking hint unless told otherwise, so adding a death year to a name search only reorders it. This server asks for every criterion to match; loose=True goes back to ranking. Even required, a criterion leaves out only a record that contradicts it: a record giving no birth year still matches "born 1850", and a year matches five either side. exact=True makes each one present and matching, and holds a place to the county or state named. Every result's filters says how each criterion was applied, so a nil result can be read as the negative it is, or is not.
• Tokens expire, and a refreshed one is picked up. A token lasts about an hour. On a 401 the server re-reads FS_ACCESS_TOKEN from the env file and retries once, so refreshing the file is enough. auth_status reports token_accepted: false when it is not.
• Throttling is retried once. A 429 asking for a wait of up to 15 seconds is waited out and retried. A longer wait, or a second 429, comes back as rate_limited with the server's Retry-After.
• Unknown parameters are refused. A misspelt or invented argument is an error that lists the parameters the tool does take. It is not silently dropped, which would make a filtered search quietly return unfiltered results.
• download_image is careful with what it is given. It fetches only HTTPS URLs on FamilySearch hosts, because the request carries your token. It creates only image and PDF files, and never overwrites one.
• Some routes are not publicly documented. FamilySearch's Historical Records API is behind a login wall, so those routes and response shapes were confirmed by live probing instead. A comment beside the code says when, and docs/API-NOTES.md records what was found. tests/live_check.py asks again.

Development

git clone https://github.com/ianderso/familysearch-mcp
cd familysearch-mcp
uv sync --extra dev
uv run pytest                  # mocked with respx; no token, no network
uv run ruff check .
uv run ruff format --check .

uv run python -m tests.live_check re-asks FamilySearch the questions only the live API can answer, with the token from your env file. See CONTRIBUTING.md for what a change is expected to carry.

License

MIT.