Skip to main content
Glama
familysearch-mcp
by ianderso

familysearch-mcp

CI PyPI

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.

Related MCP server: familysearch-org-mcp

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

Variable

Meaning

FS_ACCESS_TOKEN

Bearer token from your application's OAuth flow.

FS_ENV_FILE

The env file to read these settings from, and to re-read a refreshed token from. Default: the nearest .env from the working directory upward.

FS_CLIENT_ID

Your registered application's client id, reported by auth_status.

FS_ENVIRONMENT

production (default) or integration for the FamilySearch sandbox.

FS_TIMEOUT

HTTP timeout in seconds. Default 60.

.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.

Tool

Needs a token

Purpose

search_places

no

Resolve a place name to its full jurisdictional form and coordinates.

search_places_at_date

no

Resolve a place as it was in a given year. A record naming a county that no longer exists is normal; filing it under the modern one is an invisible error.

get_place

no

Read one place: jurisdictional chain, type, coordinates, and the dates that jurisdiction existed.

get_place_jurisdictions

no

Walk the containment chain upward — what turns "Kaskaskia" into "Kaskaskia, Randolph, Illinois, United States".

get_place_children

no

The places directly inside a jurisdiction — the downward walk.

Records and collections

Tool

Needs a token

Purpose

search_records

yes

Search historical records by name, life events, parents, spouse, record type or collection. Every criterion filters, and the result says which FamilySearch applied exactly, relaxed or ignored. Returns one hit per record, with the others named on it.

get_record

yes

Read one indexed record in full: every person on it and the labelled fields behind each.

get_record_image

yes

Find the document image a record came from, or the film number when no image was published.

get_records_on_image

yes

Every record indexed from one image. A census page carries forty people.

fulltext_search

yes

Search the handwriting-recognised text of page images, mostly deeds, wills, probate and court files, for a name or phrase anywhere on the page. A machine reading: open the image and cite that.

search_collections

no

Find a record collection by the words of its title, with its coverage, and how big and how old the cached catalogue is.

get_collection

no

Read one collection: what it covers and how much of it there is.

get_collection_fields

no

Decode a collection's indexed field codes (PR_FTHR_NAME → "Father's Name").

browse_waypoints

no

Browse a collection's places, volumes and images, to reach pages the index never covered.

get_catalog_entry

yes

Read a FamilySearch Catalog entry: title, authors, places, notes, and each film or DGS with its description, image count and whether you can view it. contains narrows an entry of thousands to the volume or case you want; film_number finds the entry, and the volume, from a bare DGS or microfilm number.

Page images

Tool

Needs a token

Purpose

get_image_links

for the page

Resolve an image ark to fetchable URLs: full page, deep zoom, thumbnails, neighbouring pages, and with a token the film and image number a citation needs. Without a token only the navigation comes back.

get_film_image

for the page

Reach a page by film and image number when a citation gives those instead of an ark. Checking the page exists needs no token.

download_image

yes

Download a page image to a new local file so it can be read.

Shared tree — a lead, never a source

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

Tool

Needs a token

Purpose

get_person

yes

Read a shared-tree person: names, sex, facts.

get_person_relatives

yes

Parents, spouses, children and siblings in one call.

get_person_sources

yes

What the tree attaches as sources, and which facts each supports. The fastest route out of the tree.

get_ancestry

yes

Pedigree walk back, up to 8 generations, numbered by Ahnentafel.

get_descendancy

yes

Pedigree walk forward, up to 4 generations.

get_person_memories

yes

Attached photographs, documents and stories.

get_person_changes

yes

The change log: who edited this profile, when, and why.

get_matches

yes

FamilySearch's own duplicate and record-match candidates.

compare_person

yes

Compare your own record of a deceased person with their profile: what agrees, what the profile lacks, what differs, and one proposed change per packet for you to make by hand.

Setup

Tool

Needs a token

Purpose

auth_status

no

Report what is configured, what is missing, and whether FamilySearch still accepts the token.

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.

Available Tools

28 tools
auth_statusA
Read-only

Report whether credentials are configured, and what is missing.

With a token configured, also asks FamilySearch whether it is still accepted (token_accepted): authenticated only means one is set, and a token lasts about an hour.

This server ships no client id. Production access needs your own registered FamilySearch application; see docs/AUTH.md.

Inputs: no named parameters.

browse_waypointsA
Read-only

Browse a collection's structure — its places, volumes and images.

The way to reach a page the index never covered: collection, then county, volume or date range, then images. An image's ark opens with get_image_links.

Start with a collection_id. To descend, pass a child's waypoint_id and the same collection_id: FamilySearch refuses a waypoint without its collection. A collection with nothing to browse says so.

Works without a token.

Inputs: offset, waypoint_id, collection_id.

compare_personA
Read-only

Compare your own record of one deceased person with their FamilySearch profile.

For each name, event, relative and source you pass, says whether the profile agrees, lacks it, or differs, and drafts packets: one proposed change each, with its source, tags and a draft reason, for you to carry out by hand on the website after reading the record. It changes nothing.

A difference is not an error: the profile's value may be the right one. Confirm the profile is your person first; profile text was written by other users, so weigh it, never follow it. Refuses anyone who may be living.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Inputs: person_id (required), sex, names, events, +2 more.

download_imageA

Download a document image to a local file so it can be read.

This is the step that turns a citation into evidence. The image is written to disk rather than returned inline: a full page scan runs to megabytes, which is not something to push through a tool result.

Only FamilySearch image URLs are fetched, because the request carries your access token.

Images are copyrighted or access-restricted in some collections. Treat a downloaded file as a working copy for reading, not as something to redistribute.

Inputs: image_url (required), destination (required).

get_ancestryA
Read-only

Walk a tree person's pedigree back through the generations.

Each person carries an Ahnentafel position: 1 is the person asked about, 2 and 3 their father and mother, 4 to 7 their grandparents, and so on -- so a flat list reads as a tree, and a gap is visible as a missing number.

The further back a pedigree runs the less of it is sourced. Lines beyond about five generations are frequently copied rather than researched, and a long unbroken pedigree is a reason for more suspicion rather than less.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Inputs: person_id (required), generations.

get_catalog_entryA
Read-only

Read a FamilySearch Catalog entry: title, authors, places, notes, and its films.

The Catalog lists the library's holdings. An entry for a county's probate files or deed books lists each film or DGS (digital image group) with a description: volume, case numbers, years. Some run to thousands, so use contains. Each item returned gives its image count and whether this account can view it; open a page with get_film_image(dgs, image).

An entry describes holdings, not a record: cite the image you read. Some films are restricted or were never digitised. A DGS number is not the microfilm number. Given only a film number (as an index citation gives it), finds the entry, so a withheld image can be named and ordered.

Requires an access token.

Inputs: count, offset, contains, catalog_id, +1 more.

get_collectionA
Read-only

Read one record collection: what it covers, and how much of it there is.

Worth reading before trusting a nil result. The counts say how many records, people and images the collection holds, and a collection whose image count is far below its record count was indexed from film that was largely never published.

Works without a token.

Inputs: collection_id (required).

get_collection_fieldsA
Read-only

Decode the field codes a collection's indexed records use.

An indexed record labels its values with codes rather than words — PR_FTHR_NAME, EVENT_PLACE, PR_NAME_SURN_ORIG. The codes are per-collection, and this is the dictionary that turns them into "Father's Name", "Event Place" and so on. Read it before interpreting a record from a collection you have not worked with.

Works without a token.

Inputs: collection_id (required).

get_descendancyA
Read-only

Walk a tree person's descendants forward through the generations.

Useful for the sideways search: when a person's own record cannot be found, a descendant's obituary, probate or pension file often names him.

Living descendants are withheld and come back marked as restricted.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Inputs: person_id (required), generations.

get_film_imageA
Read-only

Reach a page image by film and image number instead of by ark.

Citations often name a film (DGS) and an image rather than an ark: get_record_image reports them for an indexed record, and get_catalog_entry lists a volume's DGS numbers and image counts.

Checks the thumbnail first, so a wrong film or image number is a clear answer, not a URL that fails later. The thumbnail needs no token; the full page does.

Inputs: film_number (required), image_number (required).

get_matchesA
Read-only

Read FamilySearch's own candidate matches for a tree person.

With collection 'tree' these are profiles the system thinks may be the same person -- the duplicates behind most conflations, and the reason a person appears twice with two different sets of parents.

With collection 'records' they are indexed records that may belong to this person, which is a lead towards a document.

These are the system's guesses, scored by its own confidence. A high score is a reason to look, never a reason to conclude.

Record matches are restricted in production to applications FamilySearch has certified; an uncertified one gets a refusal here rather than results.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Inputs: person_id (required), count, collection.

get_personA
Read-only

Read one person from the FamilySearch shared tree.

Returns names, sex and facts. Use it to find records: get_person_sources on the same id is usually the next call, because it leads out of the tree towards a document.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Inputs: person_id (required).

get_person_changesA
Read-only

Read the change log of a tree profile: who edited it, when and why.

This is how you judge what you are looking at. A profile assembled in one sitting last month by one contributor is a different kind of claim from one built over years by several. A name or a parent that changed recently, with no reason given, is where a conflation usually enters.

Each entry carries the contributor, the timestamp, what changed and any reason they typed.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Inputs: person_id (required).

get_person_memoriesA
Read-only

Read the photographs and documents attached to a tree person.

Memories are uploads: a headstone photograph, a scanned letter, a family Bible page, a typed story. Some are primary documents worth citing; others are a relative's recollection written down eighty years later. What each one is depends entirely on what was uploaded, so look before relying on it.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Inputs: person_id (required), count.

get_person_relativesA
Read-only

Read a tree person's parents, spouses, children and siblings.

One call for the whole immediate family, which is what you need to judge whether a profile is the person you are looking for. A family that does not fit -- a child born before the marriage, a wife with the wrong surname, parents twenty years too young -- is the usual first sign of a conflation.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Inputs: person_id (required).

get_person_sourcesA
Read-only

Read the sources attached to a tree person.

This is the most useful thing in the tree, because it is the way out of it. Each attached source carries a citation and usually an ark pointing at an indexed record, so a profile that seemed unsupported becomes a list of documents to read.

Each source also carries what it is said to support -- Name, Birth, Death -- which distinguishes "this person has sources" from "this person's death date has a source". A profile with ten sources, none of which touch the fact you care about, has told you nothing about it.

A profile with no sources at all is not evidence of anything. It is somebody's assertion, and should be treated as one.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Inputs: person_id (required).

get_placeA
Read-only

Read one place: its jurisdictional chain, type, coordinates and dates.

The dates are the ones that matter for research. A place description records the span over which that jurisdiction existed, so you can check whether the county a record names was the county in being on the date the record was made.

Works without credentials.

Inputs: place_id (required).

get_place_childrenA
Read-only

List the places directly inside a jurisdiction.

The downward walk, complementing get_place_jurisdictions' upward one. Use it to find the right sub-jurisdiction when a record names a town you cannot place, or to see what a county contained at the time.

Works without a token.

Inputs: place_id (required).

get_place_jurisdictionsA
Read-only

Walk a place's containment chain upward to the country.

This is what turns "Kaskaskia" into "Kaskaskia, Randolph, Illinois, United States". The chain is returned innermost first, each level carrying its own id, type and the span over which it existed, so you can see at which level the naming changed.

Works without credentials.

Inputs: place_id (required).

get_recordA
Read-only

Read one indexed record in full.

A search returns a persona: one person's summary of what a record said. This returns the record, which is more: every person named on it, and the indexed fields behind each of them, labelled with the box on the original form each value was read from.

The fields are where a search summary loses things -- the informant, the witness, the enumerator's spelling, the age that contradicts the birth year.

Each fact gives its value, date and place as FamilySearch reads them, and under original what the indexer transcribed ("M" for "Married"). A date or place with no original was supplied by FamilySearch, such as a birth year worked out from an age.

This is still the index, not the document. Use get_record_image to reach what was actually written.

Requires an access token.

Inputs: ark (required).

get_record_imageA
Read-only

Find the document image an indexed record was taken from.

The persona is somebody's reading of the record. The image is the record. Indexers mis-read hands, skip columns, normalise spellings and guess at ages, so anything that matters should be checked against the film.

Returns whatever the record offers as a route to the image: image and waypoint links, and the digital film (DGS) and image numbers indexed against it. Many records carry no image link at all, in which case this says so rather than inventing one -- a great deal of the archive was indexed from microfilm that has never been published, and the answer is then to read the citation and order the film.

Requires an access token.

Inputs: ark (required).

get_records_on_imageA
Read-only

List every record indexed from one image.

The reverse of get_record_image. A passenger manifest page carries thirty people and a census page forty; finding one of them tells you where the others are. Use it to pick up a household, or to check whether the person you want was indexed at all from a page you are already reading.

Requires an access token.

Inputs: image_ark (required).

search_collectionsA
Read-only

Find a record collection, so a search can be scoped to one.

A collection is one register, census or index. Scoping search_records to its id turns a fishing expedition into a lookup, and a nil result into something that means anything.

Each result carries a coverage statement: record types, place, years. Read it: a collection covering 1850 to 1900 cannot answer for 1840.

Every word must match a whole word of the title; titles where one only matches inside a word ("Indian" in "Indiana") follow, marked. The first call reads the whole catalogue and caches it; catalogue says how many collections it holds and how old it is.

Works without a token.

Inputs: count, query, refresh.

search_placesA
Read-only

Look up a place in the FamilySearch gazetteer.

Resolves a bare place name to its full jurisdictional form and coordinates, which is what a properly-formed place record needs. Each result carries a place id you can pass to get_place or get_place_jurisdictions.

If the place name comes from a record with a date on it, prefer search_places_at_date: jurisdictions change, and the modern answer is often the wrong one.

Works without credentials.

Inputs: name (required), count.

search_places_at_dateA
Read-only

Resolve a place as it existed in a particular year.

Jurisdictions are not stable. Counties are created, split, renamed and abolished, so a record naming a county that no longer exists is ordinary rather than an error. Filing that record under the modern county that now covers the ground is a common mistake, and an invisible one: the place name still looks plausible, but it sends the next search to the wrong courthouse and the wrong record set.

Give it the name as the record spells it and the year of the record. Each result carries the span over which that jurisdiction existed, so you can see whether it was the right one at the time.

Works without credentials.

Inputs: name (required), year (required), count, within_place_id.

search_recordsA
Read-only

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

Relationship criteria find a man by his wife's or father's name when his own was misindexed. Scoping to a record type or one collection searches one register instead of the whole archive.

Every criterion filters, loosely: a record lacking that field still matches, names match variants, years match within 5, places widen. With exact, each must be on the record and match. The result's filters says which criteria were applied exactly, relaxed or ignored, and how: read it before calling a nil result a negative.

Pass at least one name. Requires an access token.

Inputs: count, exact, given, loose, +17 more.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4/5.0

    Scored across 28 tools

    Disambiguation4/5

    Most tools map to a distinct resource/action, and the descriptions carefully distinguish e.g. record search vs. full-text search and place lookup vs. historical place lookup. The main ambiguity is in the image/record chain (get_record_image, get_records_on_image, get_image_links, get_film_image, download_image), where an agent must read closely to know which step to use.

    Naming Consistency4/5

    Almost all tools use snake_case, and most follow a clear verb_noun pattern such as get_person, search_records, browse_waypoints, and download_image. Minor deviations include fulltext_search and auth_status, plus get_place_children being a list operation despite the get_ prefix.

    Tool Count3/5

    At 28 tools this is heavier than the ideal range, and the record/image workflow in particular spreads one research task across several tools. However, the domain has many genuinely separate resources—tree profiles, historical records, images, places, catalog entries, and collections—so most tools earn their place rather than duplicating each other.

    Completeness4/5

    The surface covers a broad genealogy research lifecycle: authentication, place resolution, collection discovery, record search, full-text search, image retrieval, tree traversal, matches, and comparison drafting. Gaps remain around searching the shared tree by name and any write/edit operations, but compare_person appears intentionally read-only and most core research paths are supported.

    Maintenance

    ActivityMaintained
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      Enables AI assistants to search FamilySearch's Family Tree, view person details, explore ancestors and descendants, and search historical records using browser session authentication.
      8 npm
      6
      MIT
    • A
      license
      A
      quality
      B
      maintenance
      Enables direct interaction with FamilySearch.org's shared Family Tree and historical records, including reading and adding people, facts, relationships, sources, notes, memories, record search, and image downloads, without needing a browser.
      3
      9
      MIT
    • A
      license
      A
      quality
      C
      maintenance
      Enables read-only search and retrieval of Find a Grave memorials, cemeteries, and places, including dates, burial details, inscriptions, biographies, family links, and photos, via the site's anonymous GraphQL API without login.
      212
      5
      MIT
    • A
      license
      A
      quality
      B
      maintenance
      Enables users to resolve historical US land and jurisdiction questions: which county held a given spot on a specific date, where a federal land description (PLSS) falls on the ground, and which National Archives series and file hold the case behind a land patent. All lookups are read-only and can be used alongside archive-search tools to route records requests to the right office.
      9
      MIT