familysearch-mcp
A read-only MCP server for FamilySearch genealogical research: resolve places, search records and images, and read the shared tree as leads.
Resolve historical places: search today or as of a year, read jurisdiction chains, coordinates, dates, and children.
Search historical records by name, relatives, events, record type, or collection; read full indexed records and find their source images.
Search collections, decode indexed field codes, browse waypoints for unindexed images, and read catalog holdings.
Search handwriting-recognized full-text page images; treat results as machine readings to verify against the image.
Work with page images: get fetchable links, reach images by film/image number, list records on an image, and download a page locally.
Read the shared family tree: person facts, relatives, ancestry/descendancy, attached sources, memories, change logs, matches, and compare a profile (proposes changes only).
Check auth status and configuration. Place/collection tools work anonymously; records, images, and tree need a token. No FamilySearch writes are made; tree results are hints, not evidence.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@familysearch-mcp find 1880 census records for my great-grandfather in Illinois"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
Related MCP server: familysearch-org-mcp
Install
uvx familysearch-mcpThat 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-mcpConfiguration
Variable | Meaning |
| Bearer token from your application's OAuth flow. |
| The env file to read these settings from, and to re-read a refreshed token from. Default: the nearest |
| Your registered application's client id, reported by |
|
|
| 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 |
| no | Resolve a place name to its full jurisdictional form and coordinates. |
| 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. |
| no | Read one place: jurisdictional chain, type, coordinates, and the dates that jurisdiction existed. |
| no | Walk the containment chain upward — what turns "Kaskaskia" into "Kaskaskia, Randolph, Illinois, United States". |
| no | The places directly inside a jurisdiction — the downward walk. |
Records and collections
Tool | Needs a token | Purpose |
| 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. |
| yes | Read one indexed record in full: every person on it and the labelled fields behind each. |
| yes | Find the document image a record came from, or the film number when no image was published. |
| yes | Every record indexed from one image. A census page carries forty people. |
| 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. |
| no | Find a record collection by the words of its title, with its coverage, and how big and how old the cached catalogue is. |
| no | Read one collection: what it covers and how much of it there is. |
| no | Decode a collection's indexed field codes ( |
| no | Browse a collection's places, volumes and images, to reach pages the index never covered. |
| 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. |
Page images
Tool | Needs a token | Purpose |
| 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. |
| 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. |
| 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 |
| yes | Read a shared-tree person: names, sex, facts. |
| yes | Parents, spouses, children and siblings in one call. |
| yes | What the tree attaches as sources, and which facts each supports. The fastest route out of the tree. |
| yes | Pedigree walk back, up to 8 generations, numbered by Ahnentafel. |
| yes | Pedigree walk forward, up to 4 generations. |
| yes | Attached photographs, documents and stories. |
| yes | The change log: who edited this profile, when, and why. |
| yes | FamilySearch's own duplicate and record-match candidates. |
| 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 |
| 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_sourcesis the most useful of them because it leads out of the tree towards a document.A comparison proposes; it never changes.
compare_persontakes 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_recordreturns the indexed fields behind it, andget_record_imagethe document itself. Read down that chain before citing.Jurisdictions move.
search_places_at_dateresolves 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_recordsasks 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_searchasks 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_entryreads the entry the website's catalog page reads, on the same footing as record search. For each film it reports the DGS number, whichget_film_imageandfulltext_searchtake, 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=Truegoes 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=Truemakes each one present and matching, and holds a place to the county or state named. Every result'sfilterssays 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_TOKENfrom the env file and retries once, so refreshing the file is enough.auth_statusreportstoken_accepted: falsewhen 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_limitedwith the server'sRetry-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_imageis 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.pyasks 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 toolsauth_statusARead-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_waypointsARead-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_personARead-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).
fulltext_searchARead-only
Search the machine-read text of page images: deeds, wills, probate, court files.
Finds a name or phrase anywhere on a page, including the witnesses, heirs and neighbours no index names. Each hit is one page image, with the passages that matched.
The text is handwriting recognition, a machine reading: open the image with get_image_links, read it yourself, and cite the image, never the text. Coverage is partial, so no result proves nothing. Each hit gives the citation path: collection, record title and image ark.
Requires an access token.
Inputs: name, text, count, facets, +4 more.
get_ancestryARead-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_entryARead-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_collectionARead-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_fieldsARead-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_descendancyARead-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_imageARead-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_image_linksARead-only
Resolve a document image to its actual, fetchable URLs.
A record read does not carry image links; the image resource does, and
this is it. Returns the storage node, the deep-zoom descriptor, thumbnails
at several sizes, and dist — the full-resolution page.
Also returns the neighbouring pages. A pension file or a passenger manifest runs to many images, and the entry you want is often not the one the index pointed at. With a token it gives the film (image group) and image number, which a citation to the page needs.
Inputs: image_ark (required).
get_matchesARead-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_personARead-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_changesARead-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_memoriesARead-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_relativesARead-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_sourcesARead-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_placeARead-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_childrenARead-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_jurisdictionsARead-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_recordARead-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_imageARead-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_imageARead-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_collectionsARead-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_placesARead-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_dateARead-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_recordsARead-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
Scored across 28 tools
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.
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.
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.
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
Related MCP Connectors
Read-only OpenHeritage search for genealogy and cultural heritage records.
Read-only search and retrieval of published books, articles and authors, with public catalog links.
Read-only U.S. lab-test catalog, collection-site search, and reference-range context.
Read-only Wikidata tools and identity evidence. Local optional Google KG; bounded public remote.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to search FamilySearch's Family Tree, view person details, explore ancestors and descendants, and search historical records using browser session authentication.8 npm6MIT
- AlicenseAqualityBmaintenanceEnables 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.39MIT
- AlicenseAqualityCmaintenanceEnables 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.2125MIT
- AlicenseAqualityBmaintenanceEnables 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.9MIT