A
licenseNot graded
qualityF
maintenanceAllows the AI to read .ged files and genetic data.
37
MIT
gedcom-mcp
Click on "Install 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., "@gedcom-mcpload my family.ged file and list all descendants of Jane Doe"
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.
gedcom-mcp
MCP server for querying local GEDCOM genealogy files through AI assistants. Load any .ged file and search, browse, and traverse your family tree without leaving your AI workflow.
Part of the Genealogy-MCP organization.
Note: GitHub is a read-only mirror. Development happens on GitLab.
Available Tools
Tool | Description |
| Load and parse a GEDCOM (.ged) file into memory |
| Search individuals by name, dates, place, sex |
| Retrieve a specific individual by cross-reference ID |
| Retrieve a family record (accepts family or individual xref) |
| Get the ancestor tree for an individual |
| Get the descendant tree for an individual |
| Get statistics about the loaded GEDCOM file |
Related MCP server: GEDCOM MCP Server
Configuration
All settings are optional with sensible defaults.
Environment Variable | Default | Description |
|
| Maximum allowed GEDCOM file size in MB |
|
| Default ancestor traversal depth |
|
| Default descendant traversal depth |
|
| Hard ceiling on traversal depth |
|
| Maximum search results returned |
| (empty) | Comma-separated allowed directories for file loading |
Setup: Claude Desktop
Add to your claude_desktop_config.json:
Using uv (local)
{
"mcpServers": {
"gedcom": {
"command": "uv",
"args": ["--directory", "/path/to/gedcom-mcp", "run", "gedcom-mcp"],
"env": {
"GEDCOM_ALLOWED_BASE_DIRS": "/path/to/your/gedcom/files"
}
}
}
}Using Docker
{
"mcpServers": {
"gedcom": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-v", "/path/to/your/gedcom/files:/data:ro",
"-e", "GEDCOM_ALLOWED_BASE_DIRS=/data",
"ghcr.io/genealogy-mcp/gedcom-mcp"
]
}
}
}Setup: Claude Code
Using uv (local)
claude mcp add gedcom -- uv --directory /path/to/gedcom-mcp run gedcom-mcpUsing Docker
claude mcp add gedcom -- docker run -i --rm \
-v /path/to/your/gedcom/files:/data:ro \
-e GEDCOM_ALLOWED_BASE_DIRS=/data \
ghcr.io/genealogy-mcp/gedcom-mcpDevelopment
# Install dependencies
make install
# Run tests with coverage
make test
# Run all checks (lint + type-check + test + audit)
make ci
# Format code
make format
# Run via stdio transport
make run-stdio
# Run via streamable-http on port 8000
make runLicense
AGPL-3.0-only
Available Tools
2 toolsexecuteA
Run a named operation. Use 'search' first to discover the exact operation name and its params schema, then call this with {operation: '...', params: {...}}.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only and has open-world parameters. Description adds context on the dynamic nature of params and the need for prior discovery, but doesn't elaborate on potential side effects beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words; front-loaded with the core action and followed by essential workflow guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's meta nature and presence of an output schema, the description fully covers the expected workflow and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already describes parameters, the description reinforces the workflow of using 'search' to obtain the schema for 'params', adding value beyond the schema's static descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Run a named operation' and distinguishes from sibling 'search' by specifying the prerequisite discovery step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use 'search' first to discover operation name and params, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchARead-onlyIdempotent
Discover available operations and their parameters. Call with a top-level 'query' string (not inside params). Returns matching operations with parameter schemas and usage examples. Always use this before calling 'execute' to find the correct operation name.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds beyond annotations: it specifies the calling convention (top-level query string) and return behavior ('Returns matching operations with parameter schemas and usage examples'). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant words. Every sentence earns its place by providing critical usage and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity as a meta-tool for searching operations, description covers purpose, invocation pattern, and return content. Output schema exists, so return values are documented there. Could mention error handling or pagination but not required for this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are present for both parameters (query and category). The description adds value by clarifying the top-level query format (not inside params) which differs from the nested schema. Despite context indicating 0% schema description coverage, the actual schema includes descriptions, so the description enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Discover' and resource 'available operations and their parameters'. It clearly differentiates from sibling 'execute' by stating 'Always use this before calling execute to find the correct operation name'. Purpose is unambiguous and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Always use this before calling execute' and specifies input format: 'Call with a top-level query string (not inside params)'. Full guidance on when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.8/5.0
Disambiguation5/5
The two tools have clearly distinct purposes: 'search' is for discovering operations and their parameter schemas, while 'execute' runs a specific operation by name. There is no ambiguity or overlap between them.
Naming Consistency5/5
Both tools use a single imperative verb ('search', 'execute'), which is a consistent and simple naming pattern. Although not verb_noun, the pattern is uniform.
Tool Count5/5
With only 2 tools, the server efficiently provides a meta-interface to dynamically discover and execute many underlying operations. This lean design is well-suited for its purpose.
Completeness5/5
The tool set is complete for its intended role: 'search' covers discovery of all operations and parameters, and 'execute' covers execution. There are no missing operations given the design.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Read-only A2Me family context tools for AI assistants (members, dates, activity, relationships)
Search, fetch (with provenance), scan, and convert AI instruction files for agents.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to create, edit, and query genealogical data from GEDCOM files. Supports complex genealogy searches, automatic data enrichment from web sources, relationship analysis, and biography generation for individuals and families.14MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to interact with Gramps genealogy databases for intelligent family tree research and management. Provides comprehensive tools for searching family data, creating records, analyzing relationships, and tracking genealogy research through natural language.41AGPL 3.0
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to query genealogy data from GEDCOM files with 24 tools for search, navigation, relationship analysis, and timeline events.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Genealogy-MCP/gedcom-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server