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., "@findagrave-com-mcp Find the graves of my 4th great-grandparents in Laurel Hill Cemetery, Philadelphia"
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.
An MCP server for Find a Grave. It searches and reads memorials: birth and death dates and places, burial cemetery, plot, inscription, biography, linked parents/spouses/children/siblings, photos and flowers. It also covers cemeteries and Find a Grave's place hierarchy.
It calls the site's own GraphQL API (POST https://www.findagrave.com/orc/graphql). The API answers anonymously, so
no login, cookies or browser are involved. Everything is read-only.
Tool | Actions | What for |
|
| Find people. Read a memorial in full: maiden name kept separate, family grouped by role with each relative's memorial id, photos, the matching Ancestry "Find a Grave Index" record, and a ready citation. |
|
| Find cemeteries by name and/or place, and read one. List a cemetery's burials with |
|
| Place ids ( |
|
| A gravestone, portrait or clipping photo, returned inline (scaled) or written to a file. |
|
| A raw read-only GraphQL query for anything the other tools lack. Mutations are refused. |
What the search defaults do, and why (each was checked against the website's counts; see docs/endpoints.md):
Names match exactly. Find a Grave's own default is a prefix match, so "Hunt" also finds Hunter and Huntley.
nameMatch: "prefix" restores it (useful for initials) and "similar" adds spelling variants.
Maiden names are included, so a married woman is found under her birth surname.
Location text is resolved to one place by name and reported back. The site's typeahead ranks "Newton, Mississippi" as Newton County and "Rijeka, Croatia" as a village in Lika. Text that fits several places is refused with their ids.
relativeName switches names to prefix matching and says so. With exact matching the site finds a relative only
by the relative's whole stored name, maiden name included.
Related MCP server: wikitree-mcp
pnpm install.mcp.json:
{ "mcpServers": { "findagrave": { "command": "node", "args": ["/path/to/findagrave-com-mcp/src/server.ts"] } } }Requirements: Node 26+ (runs TypeScript directly) and pnpm; no browser. sharp scales photos for inline viewing.
FINDAGRAVE_MIN_INTERVAL_MS (default 250) spaces requests, because the site's Cloudflare protection challenges
bursts.
pnpm test: unit tests on recorded responses (test/fixtures, re-recorded with node scripts/record-fixtures.ts).
No network.
pnpm mcp-test: live, over stdio. It calls every action and error path, checks result sizes, and runs a count
comparison for every search filter: a real value must narrow the total and a nonsense value must give about zero.
pnpm typecheck.
Find a Grave is contributor-written. Dates, family links and biographies are claims, often unsourced and sometimes
copied from online trees. Prefer what a stone in a photo shows, and cite the memorial (get returns the citation
the site prints).
A search reaches only its first 10,000 results and returns at most 50 rows per call. Narrow by place, years or cemetery.
A recently deceased person's memorial can be shown with limited details (limitedDisplay).
Find and read Find a Grave cemeteries. Actions:
search: cemeteries by name and/or place (needs name, location or locationId); rows give cemeteryId, name, place, memorial and photographed counts, GPS. A place alone lists every cemetery in it (Giles County, Tennessee has about 450). 100 per page at most.
get: one cemetery (needs cemeteryId): all its names, place, GPS, address, description and history notes, memorial count (the number a memorial search in it returns), photographed and GPS counts. To list or search the people buried in a cemetery use findagrave_memorial search with cemeteryId.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | search: words in the cemetery name, e.g. "Liberty Baptist" | |
| count | No | search: cemeteries per page (default 20, max 100) | |
| start | No | Paging offset: index of the first item to return (default 0) | |
| action | Yes | search · get | |
| orderBy | No | search: sort order (default relevance) | |
| location | No | Place as text, e.g. "Giles County, Tennessee", "Pulaski, Tennessee", "Mississippi", "Mrkopalj, Croatia". Resolved to one Find a Grave place (reported back as `location`); text that fits several places is refused with their ids. Covers the place and everything inside it | |
| cemeteryId | No | get: cemetery id or cemetery URL | |
| locationId | No | Find a Grave place id from findagrave_place search, e.g. county_2452 (Giles County, Tennessee), city_136632, state_45. Use instead of location when the text is ambiguous |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the description only needs to add context beyond those. It does: it discloses pagination limits ('100 per page at most'), the fact that ambiguous location text is refused, the returned row fields, and the semantic nuance that memorial count is the number a memorial search returns. This materially improves an agent's ability to interpret results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but information-dense, organized by action so an agent can quickly map parameters to behavior. The final routing sentence to findagrave_memorial earns its place as it prevents a common misuse. No filler or repetition of schema fields is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly carries the burden of explaining return values. It lists what search rows contain and what get returns, covers pagination, ambiguity handling, and action-specific inputs, and points to the sibling tool for the next step. For a two-action tool with eight parameters, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema. It explains that location text is resolved to one Find a Grave place and can be refused if ambiguous, that cemeteryId accepts either an id or URL, and which parameters apply to which action. The 'Giles County, Tennessee has about 450' example gives an agent a concrete sense of scale for a location-only search.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('Find and read Find a Grave cemeteries') and separates the two actions, search and get, with explicit purposes. It also distinguishes itself from the findagrave_memorial sibling by noting that people buried in a cemetery are handled there. This is specific and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance for both actions: search by name/location/locationId, get by cemeteryId. It also names the alternative tool for memorial searches: 'use findagrave_memorial search with cemeteryId'. It adds a practical caveat about a place alone listing every cemetery, which helps an agent decide whether a search is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a memorial or cemetery photo (a gravestone, portrait, obituary clipping, …). Action photo: needs photoId (from findagrave_memorial get/photos) or url (an images.findagrave.com URL). Without outPath the image is returned inline for reading, scaled so its longer side is at most maxSide (default 1600 px). With outPath the original file is written to disk unscaled (unless maxSide is given) and only metadata is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Photo URL on images.findagrave.com, instead of photoId | |
| action | Yes | photo | |
| maxSide | No | Scale so the longer side is at most this many pixels (inline default 1600; with outPath the default is the original size) | |
| outPath | No | Absolute local path to write the image to (overwritten if it exists) | |
| photoId | No | Photo id from findagrave_memorial get or photos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond annotations: inline responses are scaled to maxSide default 1600 px, while outPath writes the original file unscaled and returns only metadata. This explains the side-effect mode meaningfully despite idempotentHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences convey scope, input requirements, scaling behavior, and return behavior with no filler. The most important distinction (inline vs file output) is front-loaded and clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-action photo fetch tool, the description covers input alternatives, source guidance, output modes, scaling defaults, and return type. There is no output schema, so the description rightly explains what the caller gets in each mode.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents every parameter thoroughly (100% coverage), so baseline is 3. The description adds value by stating that photoId and url are alternatives, clarifying the inline-vs-disk behavior tied to outPath, and noting that only metadata is returned with outPath.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: "Fetch a memorial or cemetery photo," with concrete examples. This clearly distinguishes the tool from its metadata-focused siblings like findagrave_memorial and findagrave_place.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains the two input routes (photoId vs url) and the two output modes (inline reading vs writing to outPath). It references findagrave_memorial get/photos as the source for photoId, but does not explicitly state when to prefer this tool over alternatives or include exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a read-only GraphQL query against Find a Grave's own API (https://www.findagrave.com/orc/graphql) for data the other tools do not return. Mutations are refused. Full schema introspection is disabled, but { __type(name: "Memorial") { fields { name } } } lists a type's fields; docs/endpoints.md lists the useful queries and types (memorialsById, memorialSearch, cemeteries, locationsByTypeahead, browse, flowersForMemorial, getPhotos, virtualCemeterySearch). Prefer the other tools: their results are projected to fit and their filters are checked.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | GraphQL query text, e.g. query($ids:[ID!]!){ memorialsById(ids:$ids){ id plot gravesiteDetails } } | |
| action | Yes | query | |
| variables | No | Variables for the query, e.g. {"ids":["94640355"]} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds value beyond those: it states mutations are refused, full schema introspection is disabled (with a workaround), and that results are raw (since other tools 'projected to fit'). This contextualizes the openWorldHint and readOnlyHint without contradicting them. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but information-dense. It front-loads the core purpose, then packs constraints, introspection workaround, and a pointer to docs into the same sentence. Every clause adds value; there is no fluff. Slightly long, but earned length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic GraphQL tool with no output schema, the description directs to docs/endpoints.md, lists useful queries/types, and gives an introspection workaround. It covers the key pitfalls (mutations, introspection) and provides a path to discover query shapes. Missing error-handling or rate-limit notes are minor for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both 'query' and 'variables' already include concrete examples in the schema. The description adds no new parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Run a read-only GraphQL query against Find a Grave's own API'. It explicitly notes this is for data 'the other tools do not return', clearly distinguishing it from sibling tools like findagrave_memorial and findagrave_cemetery. The purpose is unambiguous and contextually differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Prefer the other tools: their results are projected to fit and their filters are checked.' This tells the agent when to use alternatives and why. It also states mutations are refused, setting a clear boundary. This is model guidance, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and read Find a Grave memorials (grave records: dates, burial place, plot, inscription, biography, linked family, photos). Actions:
search: memorials matching the given criteria; needs at least one of lastName, firstName, location/locationId, cemeteryId, relativeName, text, bio, birthYear, deathYear, famous. Rows give memorialId, name, maidenName, birth/death dates and places, cemetery, plot, veteran/gravePhoto flags, and for text/relativeName/bio searches the passages that matched. Names match exactly by default (nameMatch); women are also found under their maiden name unless includeMaidenName=false. About 360 chars per row, 50 rows per call at most; only the first 10000 results of a search can be reached, so narrow by place or years.
get: one memorial in full (needs memorialId): name with maidenName separate, birth/death with place ids, burial cemetery and GPS, plot, inscription, bio, veteran, family grouped by the relative's role (parents with father/mother, spouses, children, siblings, halfSiblings — each with its own memorialId to read next), the first photos (photos=count), who created/manages it, the matching Ancestry "Find a Grave Index" record (ancestryRecord: collectionId 60525 + recordId, usable with ancestry_record get), and a ready citation. About 2-15K chars.
photos: a memorial's photos with captions and contributors (needs memorialId; type filters grave/person/family/other). Read one with findagrave_download.
flowers: virtual flowers left on the memorial with their notes, which sometimes name relatives (needs memorialId). Find a Grave is user-contributed: dates, family links and bios are a contributor's claims, often without sources; treat them as leads and check the stones in the photos and the records behind them.
| Name | Required | Description | Default |
|---|---|---|---|
| bio | No | search: words in the biography only | |
| plot | No | search: plot text, e.g. "Row 4" | |
| text | No | search: words anywhere on the memorial — biography, relatives' names, maiden name — e.g. "Dearing" with lastName "Lay" finds Lays whose bio or family mentions Dearing. Rows show what matched | |
| type | No | photos: which photos (default all) | |
| count | No | Items per call (default 20): search at most 50, photos and flowers at most 100 | |
| start | No | Paging offset: index of the first item to return (default 0) | |
| action | Yes | search · get · photos · flowers | |
| famous | No | search: true = only famous memorials | |
| photos | No | get: how many photos to list (default 10, 0 = none; the total is always given) | |
| orderBy | No | search: sort order (default: Find a Grave's relevance). birth/death = oldest first; *_desc = newest first | |
| veteran | No | search: true = only memorials flagged as veterans | |
| cenotaph | No | search: true = only cenotaphs (marker without burial) | |
| graveGps | No | search: true = only graves with GPS coordinates, false = only without | |
| lastName | No | search: surname | |
| location | No | Place as text, e.g. "Giles County, Tennessee", "Pulaski, Tennessee", "Mississippi", "Mrkopalj, Croatia". Resolved to one Find a Grave place (reported back as `location`); text that fits several places is refused with their ids. Covers the place and everything inside it | |
| birthYear | No | search: birth year | |
| deathYear | No | search: death year | |
| firstName | No | search: given name(s); "Annie" also matches "Annie Jane" (middle names are part of the first name on Find a Grave) | |
| nameMatch | No | search: exact (default) = whole names, "Hunt" finds Hunt only; prefix = names starting with the text, so initials match ("A." for Annie) but "Hunt" also finds Hunter and Huntley; similar = spelling variants (Lay → Lacy, Lackland), noisy | |
| cemeteryId | No | search: only memorials in this cemetery (id from findagrave_cemetery search or a memorial's burial.cemeteryId); with no name it lists the whole cemetery | |
| gravePhoto | No | search: true = only with a grave photo, false = only without | |
| locationId | No | Find a Grave place id from findagrave_place search, e.g. county_2452 (Giles County, Tennessee), city_136632, state_45. Use instead of location when the text is ambiguous | |
| memorialId | No | Memorial id (e.g. "94640355") or a memorial URL | |
| middleName | No | search: middle name | |
| relativeName | No | search: memorials linked to a relative with this name, e.g. lastName "Davis" + relativeName "Sarah West" finds her husband and children. Switches name matching to prefix (the result says so): Find a Grave matches a relative exactly only by the whole stored name, maiden name included. Loose on its own (thousands of hits); combine with lastName and location | |
| birthYearMode | No | How birthYear is compared: exact (default), before, after. Memorials with no birth year never match a birth-year filter | |
| deathYearMode | No | How deathYear is compared: exact (default), before, after. Memorials with no death year never match a death-year filter | |
| notInCemetery | No | search: true = only people not buried in a cemetery (ashes scattered, lost at sea, …) | |
| birthYearRange | No | Match birthYear ± this many years (1-25); replaces birthYearMode | |
| deathYearRange | No | Match deathYear ± this many years (1-25); replaces deathYearMode | |
| includeNickname | No | search: also match firstName against nicknames (default false) | |
| includeMaidenName | No | search: also match lastName against maiden names (default true), so a married woman is found under her birth surname |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/openWorld/idempotent, so the description carries the behavioral burden. It adds crucial specifics: 50-row call limits, the 10,000-result ceiling, exact-name matching by default, maiden-name fallback, relative-name prefix behavior, and a clear warning that Find a Grave data is user-contributed and often unsourced. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but appropriately so for a tool with 32 parameters and four actions. It is front-loaded with the core purpose, organized into scannable action bullets, and ends with a concise data-quality caveat. Every sentence contributes meaningful operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must disclose return values, and it does: search row fields, get payload components, photos/flowers behavior, pagination, and output size ranges are all described. The user-contributed data caution and first-10000 limit complete the picture needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter guidance beyond the schema: the requirement to provide at least one search filter, row-size and paging constraints, and how name matching modes combine with includeMaidenName and relativeName. This elevates the practical usefulness for selecting and combining parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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—'Search and read Find a Grave memorials'—and then enumerates four distinct actions (search, get, photos, flowers). This clearly differentiates the tool from sibling tools like findagrave_cemetery and findagrave_place, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The action breakdown gives clear context, and the parameter notes reference sibling tools: findagrave_cemetery for cemetery IDs, findagrave_place for place IDs, and findagrave_download for reading photos. It does not explicitly state when NOT to use this tool versus findagrave_graphql or the other siblings, leaving those exclusions implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a Grave's place hierarchy (country → state → county → city), whose ids narrow memorial and cemetery searches. Actions:
search: places and cemeteries whose name starts like the text (needs name), with locationId, type, full place and cemetery count. Find a Grave ranks these by its own relevance, not by the name, so check the place before using an id.
get: one place by locationId.
children: the places directly inside a place (needs locationId): counties of a state, towns of a county.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | search: place name, optionally with its county/state/country, e.g. "Newton, Mississippi" | |
| count | No | search: places to return (default 10, max 50) | |
| action | Yes | search · get · children | |
| locationId | No | get/children: place id, e.g. county_2452 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: search results are ranked by Find a Grave's relevance rather than name, and the place hierarchy structure is explained. It doesn't detail pagination or error behavior, but the annotations plus the ranking warning provide solid transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence overview of the hierarchy, then a bulleted list of the three actions with their requirements and outputs. Every sentence earns its place, and the most important caveat (relevance ranking) is included without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with three simple actions and full schema coverage, the description is nearly complete. It explains the hierarchy, each action's inputs and outputs, and the ranking caveat. It doesn't describe the exact return shape, but there is no output schema and the description gives enough detail (locationId, type, full place, cemetery count) for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds meaning by explaining the role of locationId in narrowing searches, giving an example format (county_2452), and clarifying that name is needed for search while locationId is needed for get/children. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it exposes Find a Grave's place hierarchy (country → state → county → city) and lists three specific actions (search, get, children) with their inputs and outputs. It distinguishes itself from sibling tools by focusing on places and how their ids narrow memorial and cemetery searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use each action: search for places/cemeteries by name, get for one place by locationId, children for direct sub-places. It also warns that search results are ranked by Find a Grave's own relevance, not by name, so the agent should verify the place before using an id. This is clear usage guidance with a caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0findagrave_cemeteryfindagrave_downloadfindagrave_graphqlfindagrave_memorialfindagrave_placeScored across 5 tools
Each tool targets a distinct domain (memorials, cemeteries, places, downloads, GraphQL), but findagrave_place search and findagrave_cemetery search can both return cemeteries by name, creating mild ambiguity about which to use.
All tools share the findagrave_ prefix, but actions mix verb forms (search, get) with plural nouns (photos, flowers), and findagrave_download and findagrave_graphql break the resource-noun pattern of the other tools.
Five top-level tools is well-scoped; each tool covers a logical area, and exposing actions under memorial/cemetery/place keeps the surface clean without bloat.
The server covers the full read-only workflow for Find a Grave: memorial search/detail/photos/flowers, cemetery and place lookup, photo download, and a GraphQL fallback for any missing data. No obvious dead ends.
Read-only OpenHeritage search for genealogy and cultural heritage records.
Search and fetch Wikidata entities, execute SPARQL queries, and resolve external identifiers.
Anonymous read-only access to source-backed public SHAR Production knowledge.
Read-only A2Me family context tools for AI assistants (members, dates, activity, relationships)
