gedcom-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct purpose: get_* fetches by ID, find_* searches by criteria, list_* traverses relations, and get_sources/suggest_slug handle dedicated concerns. The potential overlap between get_family and list_children is minor as they take different inputs and serve different queries.
Naming Consistency4/5
Tools follow a consistent verb_noun pattern with get_ (by ID), find_ (search), and list_ (relation traversal). The 'info' tool breaks the pattern, and 'suggest_slug' uses a less common verb, but the overall structure is predictable.
Tool Count5/5
Ten tools is well within the ideal range for a focused domain server. Each tool addresses a core genealogy query or workspace utility with no redundancy.
Completeness5/5
The server covers the full read-only lifecycle: retrieval by ID, search by name/family, ancestor/descendant traversal, source citations, and a slug utility. There are no obvious dead ends or missing operations for its stated purpose.
Average 4.1/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds useful context by mentioning the inclusion of Ancestry's _APID codes when present and scoping to 'immediate events.' However, it does not state whether this is a read-only operation, how errors are handled, or the exact shape of the response.
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 short, clear sentences with front-loaded purpose and no superfluous content. It efficiently communicates the tool's core function and a key behavioral detail.
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 the simple input schema (one parameter) and the existence of an output schema, the description adequately covers scope and notable inclusions. It falls short of complete by not addressing edge cases (e.g., missing sources) or providing any usage guidance relative to siblings, but it is sufficient for a straightforward retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the individual_id parameter. The description refers to 'the individual,' which maps to the parameter name but adds little beyond what the schema already implies. No format, constraints, or examples are provided.
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?
The description clearly identifies what the tool returns: source citations for a given individual, including their immediate events. This distinguishes it from sibling tools like get_individual or list_ancestors, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: use this tool when you need source citations for an individual. However, no explicit alternatives or exclusions are provided, so agents must infer when this is preferable to related tools like get_individual or find_family.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It discloses the generations limit but does not clarify whether the individual is included, how results are ordered, or error handling. This lack of key behavioral context is a significant gap for a tool without annotation support.
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?
The description is a single, front-loaded sentence that conveys the core purpose and key limitation with no wasted words. The backticked 'generations' clearly references the parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with an output schema, the description adequately states the purpose and depth parameter. However, it lacks usage guidance and behavioral details like self-inclusion or traversal order, making it only minimally complete for the given complexity.
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?
The schema has zero description coverage, so the description must compensate. It does so by mapping 'given individual' to individual_id and 'up to generations levels' to the generations parameter, giving each parameter a clear semantic. While not exhaustive (e.g., no mention of defaults), it covers the essential meaning.
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?
The description uses the specific verb 'list' (from the tool name) with the resource 'descendants' and clearly scopes it to a given individual and a depth limit. This distinguishes it from siblings like list_children and list_ancestors by focusing on the descendant hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving descendants up to a certain number of generations, but it does not explicitly compare with alternatives like list_children or list_ancestors, nor state when to use this tool over them. The depth limit hints at its broader scope, but guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It adds useful context about the 'generation' field and the depth limit, but does not mention error conditions, ordering, or whether the individual itself is included. This is adequate but not comprehensive.
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?
The description is two sentences, front-loaded with the primary purpose, and includes only necessary details. Every word earns its place; it is concise and well-structured.
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 that an output schema exists, the description does not need to explain return values in detail. It covers the main behavioral nuance (generation field semantics) and the depth limit, making it reasonably complete for a simple list tool. Minor omissions like handling of non-existent individuals do not significantly detract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining the 'generations' parameter ('up to ``generations`` levels') and implying 'individual_id' as the given individual. However, it does not elaborate on the ID format or other potential constraints, leaving some semantic gaps.
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?
The description clearly states that the tool returns ancestors of a given individual, with the depth limited by the 'generations' parameter. This distinguishes it from sibling tools like list_children and list_descendants by explicitly specifying the ancestor direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving ancestors but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It is a straightforward description without comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It adds the useful detail that results span all spouse families, but it does not disclose return structure, ordering, pagination, or potential edge cases (e.g., individuals with no children).
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?
The description is a single, efficient sentence that conveys the core function without unnecessary words. It is well-structured for a simple list tool.
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 the tool's simplicity, the presence of an output schema, and the clear scope of listing children across all spouse families, the description covers the essential context. A minor gap is the lack of explicit differentiation from list_descendants, but overall it is complete enough for an agent to select and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and while the description ties 'given individual' to the individual_id parameter, it does not explain the expected format or provide additional constraints. The parameter name is self-explanatory, so this is minimally sufficient but not enriching.
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?
The description clearly identifies the tool's function: listing children of a specified individual, with the scope 'across all spouse families.' This distinguishes it from sibling tools like list_ancestors and list_descendants, which cover broader or different relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving an individual's children, but it does not explicitly state when to use this tool over alternatives such as list_descendants or get_family. No exclusions or situational guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It specifies that the record's husband/wife/children are resolved to summary dicts and that id accepts both '@F1@' and 'F1' formats, adding meaningful context beyond the schema. It does not cover error handling or edge cases, but this is acceptable for a read-only retrieval tool.
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?
The description is a single sentence, front-loaded with the primary action and key details. It contains no filler or redundant information, making it concise and well-structured.
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?
For a simple get-by-id tool, the description covers the essential functionality, including the id format and the resolution of relations. Since an output schema exists, the return values are already documented. It lacks explicit alternative-tool guidance and edge-case behavior, but given the tool's simplicity, the description is reasonably complete.
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?
The schema provides only the parameter name and type with 0% description coverage. The description compensates by explaining that 'id' identifies a FAM record and gives examples of acceptable formats ('@F1@' or 'F1'), which adds value beyond the bare schema definition.
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?
The description clearly states the tool returns a full FAM record for a given id, with husband/wife/children resolved to summary dicts. This precise verb+resource combination distinguishes it from siblings like get_individual or find_family, which target different record types or search behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. The name and description imply usage for fetching a family record by id, but there is no mention of exclusions or comparisons to sibling tools like find_family or get_individual, making the usage context only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description bears the burden. It discloses a key behavioral rule (at least one parameter required) but does not state that the operation is read-only or describe return behavior. The word 'search' implies a read operation, but this is not explicit.
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 concise sentences, front-loaded with the primary action and followed by a critical usage constraint. Every word earns its place.
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?
The description is adequate for a search tool with an output schema. It covers the main search criteria and the precondition. It does not mention edge cases like empty results or matching semantics, but these are not essential given the output schema depth.
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 description coverage is 0%, so the description compensates by naming and explaining the three main parameters (husband_query, wife_query, marriage_year) and the constraint that one must be set. It does not explain 'limit', but that parameter's purpose is obvious from its name and schema default.
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?
The description clearly states the tool searches families by spouse name and/or marriage year, using a specific verb ('search') and resource ('families'). It distinguishes from sibling tools like find_individual and get_family by focusing on family-level search with spouse criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Search families by spouse name and/or marriage year' and a clear constraint that at least one of the three key parameters must be set. Does not mention alternatives explicitly, but the constraint gives clear guidance on valid invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral traits: token matching against all NAME records (primary + AKAs), and the return format (compact summaries with specific fields). It does not mention case sensitivity, partial matching, or pagination, but the disclosed behavior is significant and useful.
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?
The description is two sentences, front-loaded with the primary purpose, and every sentence adds specific value (matching behavior and return content). There is no fluff or repetition of schema-visible information.
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?
Despite having an output schema, the description already explains the return fields, adding value. It covers purpose and matching logic well. It does not explicitly state when not to use it or limit behavior, but for a straightforward search tool, it is adequately complete and minimal-viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'query' parameter's semantics (tokens matched against names) but does not mention 'limit' or its effect (truncating results). The description adds meaning to one of two parameters only, so it partially compensates but not fully.
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?
The description clearly states a specific action ('Search for individuals by name') and resource ('individuals'), and distinguishes itself from siblings like get_individual (likely ID-based) and find_family by focusing on name search. It also details the matching logic and return fields, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is a name-based search tool that matches tokens against primary and AKA names. This implies when to use it (when you have a name) versus alternatives like get_individual (by ID) or find_family (families), but it does not explicitly state exclusions or alternatives, so it misses the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly indicates this is a read operation ('Return'), discloses the contents of the response, and specifies the error behavior for non-existent records. It could mention auth/rate limits, but for a simple read-by-id tool this is strong coverage.
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?
The description is two sentences, front-loaded with the primary action, and every clause earns its place. It avoids redundancy and fluff.
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 simple one-parameter input, the presence of an output schema, and the tool's complexity, the description is complete: it covers accepted id formats, the nature of the returned record, and the error case. The mention of workspace content schema also informs the user about shaping of external_ids.
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 description coverage is 0%, but the description compensates by defining 'id' as an INDI record identifier and providing accepted formats ('@I123@' or 'I123'). This adds meaning beyond the bare schema. However, it doesn't elaborate on constraints like max length or data type edge cases, so not a 5.
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?
The description uses a specific verb ('Return') and resource ('full INDI record for id'), and enumerates included data (events, residences, sources, etc.), clearly distinguishing this from sibling tools like get_family or find_individual. Even without an explicit sibling comparison, the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an individual id and need the full record, but it does not explicitly state when to use this over alternatives, nor does it provide exclusions. The error message provides some guidance for missing ids, but no when/not-when comparisons to siblings are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses the exact output contents including the conditional '(if Ancestry)' for tree id. It clearly implies a read-only operation, though it does not explicitly state side effects or performance notes. The transparency is adequate for a simple info tool.
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?
The description is a single, front-loaded sentence with no fluff. Every word contributes meaning, specifying the return values concisely.
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 simplicity (0 params, output schema exists), the description fully covers what the tool does and what it returns. There is no missing guidance for invocation or interpretation.
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?
The tool has zero parameters and the schema is 100% covered by an empty object. The description does not need to explain parameters, and the baseline for 0 params is 4, which is appropriate here.
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?
The description clearly states the tool returns basic info about the loaded GEDCOM, listing specific items (file path, tree id, counts). This verb+resource framing distinguishes it from sibling tools that focus on individual/family queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: it provides an overview of the loaded GEDCOM. While it does not explicitly say 'use this instead of X', the contrast with sibling family-specific tools is implied, and no exclusions are needed for a parameterless info tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers: it discloses the slug derivation algorithm for both record types, the handling of missing years ('unknown'), the lowercase ASCII and hyphen-separated encoding, and the return payload (slug plus inputs). This goes well beyond a vague summary.
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?
The description is compact and front-loaded with a clear purpose, followed by precise algorithmic details. Every sentence contributes essential information: the rule, record-type variations, missing-year handling, character constraints, and return value. No filler or redundant phrasing.
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?
For a single-parameter utility with an output schema, the description covers all essential aspects: what it does, how it derives the result, edge cases, and expected return. The reference to AGENTS.md is explained inline, so the tool is fully usable without external files. Sibling tools confirm the domain context, making the description complete enough for correct selection and invocation.
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?
The schema only declares an 'id' with zero description. The tool description clarifies that 'id' refers to 'the given record' and that the tool derives the slug inputs (surname, given, birthyear, etc.) from it. It does not explicitly define the id format, but the context makes it clear, and the description adds meaning to an otherwise opaque parameter.
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?
The description uses a specific verb ('Apply') and names the resource ('the workspace folder-slug rule from AGENTS.md to the given record'). It explicitly differentiates from siblings by being the only tool that generates slugs, and it even provides the exact rules for INDI and FAM records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: whenever a folder slug is needed for a record, following the workspace rule. It does not explicitly mention alternatives or when not to use it, but the sibling context (all read-oriented retrieval tools) and the concrete slug-format guidance make the use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![gedcom-mcp-server MCP server](https://glama.ai/mcp/servers/brianjbeach/gedcom-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/brianjbeach/gedcom-mcp-server)

Score Badge

Copy to your README.md:

[![gedcom-mcp-server MCP server](https://glama.ai/mcp/servers/brianjbeach/gedcom-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/brianjbeach/gedcom-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/brianjbeach/gedcom-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server