Pedigree MCP Server
References NSGC (National Society of Genetic Counselors) standardized pedigree nomenclature guidelines published in PubMed, ensuring compliance with Bennett 2008/2022 standards for medical pedigree documentation.
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., "@Pedigree MCP Servercreate a pedigree for a family with BRCA1 mutations across three generations"
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.
Pedigree MCP Server
Installation
Add to your MCP client configuration (e.g., Claude Desktop):
{
"mcpServers": {
"pedigree": {
"command": "npx",
"args": ["pedigree-mcp"],
"env": {}
}
}
}Build from Source
If you prefer to build from source:
git clone https://github.com/zzgael/pedigree-mcp.git
cd pedigree-mcp
npm install
npm run buildThen use in your MCP client configuration:
{
"mcpServers": {
"pedigree": {
"command": "node",
"args": ["/absolute/path/to/pedigree-mcp/dist/index.js"],
"env": {}
}
}
}Related MCP server: Kerykeion MCP Server
Features
Bennett 2008 Standard Compliance
This implementation follows the NSGC Standardized Human Pedigree Nomenclature:
Symbol | Description | Property |
Square | Male |
|
Circle | Female |
|
Diamond | Unknown sex |
|
Filled shape | Affected individual |
|
Diagonal line | Deceased |
|
Arrow (lower-left) | Proband |
|
Double arrow (lower-left) | Consultand (person seeking counseling) |
|
Brackets [ ] | Adopted |
|
Double line | Consanguinity | Auto-detected from shared ancestors |
Text on double line | Consanguinity degree |
|
Horizontal bar | MZ (identical) twins |
|
Diagonal lines | DZ (fraternal) twins |
|
Dot in center | Carrier status |
|
Outlined dot | Obligate carrier (inferred) |
|
"P" inside symbol | Pregnancy |
|
"P" + weeks label | Pregnancy duration |
|
Small triangle | Early pregnancy loss (<20 weeks) |
|
Large triangle | Stillbirth (≥20 weeks) |
|
"EP" below symbol | Ectopic pregnancy |
|
Crossed lines (X) | Infertility |
|
Hash marks on line | Divorced/separated |
|
Line through offspring | No children by choice |
|
"A" in upper right | Ashkenazi ancestry |
|
"*" in upper left | Genetic anticipation |
|
"d. XXy" label | Age at death (auto-calculated) |
|
Arrow + "OUT" label | Adopted OUT (placed for adoption) |
|
Dashed brackets | Foster placement (temporary) |
|
Roman numerals I, II, III | Birth order in sibling group |
|
"E" marker (blue) | ART - Egg donor conception |
|
"S" marker (blue) | ART - Sperm donor conception |
|
"Em" marker (blue) | ART - Embryo donor conception |
|
"GC" marker (blue) | ART - Gestational carrier (surrogate) |
|
"SAB" label | Pregnancy outcome - Spontaneous abortion |
|
"TOP" label | Pregnancy outcome - Termination of pregnancy |
|
"SB" label | Pregnancy outcome - Stillbirth |
|
"Het" label (green) | Gene copy number - Heterozygous |
|
"Hom" label (green) | Gene copy number - Homozygous |
|
"CH" label (green) | Gene copy number - Compound heterozygous |
|
Dashed partnership line | Unmarried/common-law partnership |
|
Conditions (Bennett Standard - FREE TEXT)
Per Bennett 2008 standard, conditions are documented using free text. Simply provide a conditions array with any disease/condition name:
{
"conditions": [
{ "name": "Breast cancer", "age": 42 },
{ "name": "Ovarian cancer", "age": 55 }
]
}Examples:
{ "name": "Huntington's disease", "age": 45 }{ "name": "Type 2 diabetes" }(no age = affected status only){ "name": "Cystic fibrosis" }{ "name": "Hereditary hemochromatosis", "age": 38 }
Colors are auto-assigned from a palette based on unique condition names. Multiple conditions show as quadrants (male) or pie slices (female).
Genetic Testing Results
Supports any gene - use pattern {gene}_gene_test:
{
"brca1_gene_test": { "type": "T", "result": "P" },
"htt_gene_test": { "type": "T", "result": "P" },
"apoe_gene_test": { "type": "S", "result": "N" }
}Gene test result codes:
type:
T(tested),S(screening),-(unknown)result:
P(positive),N(negative),-(unknown/VUS)
Labels appear as: BRCA1+ (positive), HTT- (negative)
Tools
get_pedigree_documentation
Returns comprehensive documentation about the pedigree data format. Always call this first before generating a pedigree.
generate_pedigree
Generates a family pedigree tree in PNG or SVG format.
Parameters:
Parameter | Type | Default | Description |
|
| required | Array of family members |
|
| 800 | Image width in pixels |
|
| 600 | Image height in pixels |
|
| 35 | Node diameter in pixels |
|
| #ffffff | Background color |
|
| ['age'] | Attributes to display |
|
| 'png' | Output format: png (base64 image) or svg (XML text) |
Data Format
Individual Object
interface Individual {
// Required
name: string; // Unique ID (max 7 chars)
sex: "M" | "F" | "U"; // Male, Female, Unknown
// Identity
display_name?: string; // Human-readable name for display (max 13 chars)
top_level?: boolean; // Founding individual (no parents)
proband?: boolean; // Index case
// Relationships
mother?: string; // Mother's name (must exist in dataset)
father?: string; // Father's name (must exist in dataset)
// Demographics
age?: number; // Current age
yob?: number; // Year of birth
status?: number; // 0 = alive, 1 = deceased
// Twins (Bennett standard)
mztwin?: string; // MZ twin group ID (identical)
dztwin?: string; // DZ twin group ID (fraternal)
// Special indicators (Bennett standard)
carrier?: boolean; // Carrier status (dot in center)
pregnant?: boolean; // Current pregnancy (P inside symbol)
terminated?: boolean; // Stillbirth/SAB (small triangle)
divorced?: boolean; // Divorced from partner (hash marks)
noparents?: boolean; // Adopted (brackets around symbol)
// Conditions (Bennett standard - FREE TEXT)
conditions?: Array<{
name: string; // Any condition: "Breast cancer", "Huntington's disease", etc.
age?: number; // Age at diagnosis/onset
}>;
// Genetic tests (pattern: {gene}_gene_test)
brca1_gene_test?: { type: "-"|"S"|"T", result: "-"|"P"|"N" };
brca2_gene_test?: { type: "-"|"S"|"T", result: "-"|"P"|"N" };
// ... any gene test
}Examples
📸 View All 21 Scenario Examples →
See the full gallery of standardized pedigree scenarios demonstrating Bennett 2008/2022 compliance, including gender diversity, twins, consanguinity, ART indicators, and complex multi-generation families.
Basic Three-Generation Pedigree
[
{"name": "MGF", "sex": "M", "top_level": true},
{"name": "MGM", "sex": "F", "top_level": true, "conditions": [{"name": "Breast cancer", "age": 55}]},
{"name": "Mother", "sex": "F", "mother": "MGM", "father": "MGF", "conditions": [{"name": "Breast cancer", "age": 42}]},
{"name": "Father", "sex": "M", "top_level": true},
{"name": "Proband", "display_name": "Sarah", "sex": "F", "mother": "Mother", "father": "Father", "proband": true, "age": 25, "brca1_gene_test": {"type": "T", "result": "P"}}
]Neurological Condition Pedigree
[
{"name": "GF", "sex": "M", "top_level": true, "status": 1, "conditions": [{"name": "Huntington's disease", "age": 52}]},
{"name": "GM", "sex": "F", "top_level": true},
{"name": "Father", "sex": "M", "mother": "GM", "father": "GF", "conditions": [{"name": "Huntington's disease", "age": 48}]},
{"name": "Mother", "sex": "F", "top_level": true},
{"name": "Proband", "sex": "M", "mother": "Mother", "father": "Father", "proband": true, "age": 25, "carrier": true}
]Twins Example
[
{"name": "Dad", "sex": "M", "top_level": true},
{"name": "Mom", "sex": "F", "top_level": true},
{"name": "Twin1", "sex": "M", "mother": "Mom", "father": "Dad", "mztwin": "mz1"},
{"name": "Twin2", "sex": "M", "mother": "Mom", "father": "Dad", "mztwin": "mz1"},
{"name": "DZTwin1", "sex": "M", "mother": "Mom", "father": "Dad", "dztwin": "dz1"},
{"name": "DZTwin2", "sex": "F", "mother": "Mom", "father": "Dad", "dztwin": "dz1"}
]Complex Family with Bennett Features
[
{"name": "GF", "sex": "M", "top_level": true, "status": 1},
{"name": "GM", "sex": "F", "top_level": true, "carrier": true},
{"name": "Father", "sex": "M", "mother": "GM", "father": "GF", "divorced": true},
{"name": "Mother", "sex": "F", "top_level": true},
{"name": "Child1", "sex": "F", "mother": "Mother", "father": "Father", "proband": true, "noparents": true},
{"name": "Loss", "sex": "U", "mother": "Mother", "father": "Father", "terminated": true}
]Development
# Install dependencies
npm install
# Run in development mode (watch)
npm run dev
# Run all tests
npm test
# Build for production
npm run build
# Type check
npx tsc --noEmitTesting
159 tests total covering:
Validation (parent references, gender constraints)
SVG rendering (all symbol types, indicators)
Condition markers and multi-condition pie charts
Gene test formatting
Twin rendering (MZ with bar, DZ without)
Consanguinity detection
Bennett 2008 compliance (carrier, pregnancy, termination, divorced)
Edge cases (deep pedigrees, wide generations, half-siblings)
References
License
MIT License - see LICENSE
Available Tools
2 toolsgenerate_pedigreeA
Generates a pedigree tree (Bennett 2008 standard) in PNG or SVG format. IMPORTANT: Use mother/father for ALL individuals with known parents - siblings share same parents. Only use top_level:true for founders with NO known parents.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | Yes | Array of family members in pedigreejs format | |
| width | No | Image width in pixels | |
| height | No | Image height in pixels | |
| symbol_size | No | Size of individual symbols | |
| background | No | Background color | #ffffff |
| labels | No | Which demographics to show: age, yob, or both. Condition and gene test labels are always shown automatically. | |
| format | No | Output format: png (base64 image, default) or svg (XML text) | png |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it generates visual output (PNG/SVG), follows a specific standard (Bennett 2008), and includes important constraints (e.g., siblings share parents, top_level usage rules). However, it lacks details on error handling, performance limits, or authentication needs, which would be beneficial for a tool with complex input.
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 highly concise and well-structured: two sentences that front-load the core purpose and follow with critical usage rules. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.
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?
Given the tool's complexity (7 parameters, nested dataset structure) and lack of annotations or output schema, the description is largely complete. It covers the tool's purpose, key behavioral rules, and output formats. However, it does not describe the return value (e.g., base64 string for PNG, XML for SVG) or potential errors, which would enhance completeness for a generative tool.
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 thoroughly. The description adds minimal parameter semantics beyond the schema, primarily emphasizing rules for 'mother/father' and 'top_level' usage. It does not explain parameter interactions or provide additional context for other parameters, resulting in a baseline score of 3.
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: 'Generates a pedigree tree (Bennett 2008 standard) in PNG or SVG format.' It specifies the verb ('generates'), resource ('pedigree tree'), standard ('Bennett 2008'), and output formats ('PNG or SVG'). This distinguishes it from the sibling tool 'get_pedigree_documentation', which likely provides documentation rather than generating visualizations.
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 provides explicit usage guidelines: 'IMPORTANT: Use mother/father for ALL individuals with known parents - siblings share same parents. Only use top_level:true for founders with NO known parents.' It specifies when to use certain parameters (mother/father vs. top_level) and includes critical constraints, offering clear guidance on how to structure the dataset correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pedigree_documentationA
Returns comprehensive documentation for the pedigree data format. ALWAYS call this first before generating a pedigree to understand the required data structure, properties, and examples.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read-only operation ('Returns documentation') and specifies the scope ('comprehensive documentation for the pedigree data format'). However, it doesn't mention potential limitations like response format, size constraints, or error conditions.
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 perfectly concise with two sentences that each serve distinct purposes: the first states what the tool does, the second provides critical usage guidance. There is zero wasted language or redundancy.
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 0-parameter tool with no output schema, the description provides excellent context about what information will be returned and when to use it. The only minor gap is the lack of information about the format or structure of the returned documentation.
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 tool has 0 parameters with 100% schema description coverage, so the baseline would be 4. The description appropriately doesn't discuss parameters since there are none, and instead focuses on the tool's purpose and usage context.
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 with specific verb ('Returns') and resource ('comprehensive documentation for the pedigree data format'). It explicitly distinguishes from its sibling tool 'generate_pedigree' by stating this should be called first before generating a pedigree.
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 provides explicit usage guidance: 'ALWAYS call this first before generating a pedigree.' It clearly positions this as a prerequisite to the sibling tool 'generate_pedigree' and specifies the context in which it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v1.0.0- First observed
generate_pedigree - First observed
get_pedigree_documentation
TDQS
Scored across 2 tools
The two tools have completely distinct purposes: one generates a pedigree tree in visual formats, while the other provides documentation about the data format. There is no overlap in functionality, making it impossible for an agent to confuse them.
Both tools follow a consistent verb_noun naming pattern (generate_pedigree, get_pedigree_documentation) with clear, descriptive names that align well with their functions. There are no deviations or mixed conventions.
With only two tools, the server feels under-scoped for a pedigree domain, which typically involves more operations like data validation, editing, or querying. While the tools cover core tasks, the count is too low for comprehensive coverage.
The server lacks essential operations for a pedigree system, such as creating, updating, or deleting pedigree data, validating input, or querying specific individuals. The tools only handle generation and documentation, leaving significant gaps that will likely cause agent failures in real-world workflows.
Maintenance
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
Generate and vectorize clean, editable SVG graphics from text, images, or both.
Generate, edit, and export data-architecture diagrams from your AI. Column lineage, PNG in chat.
Generate cloud architecture diagrams, flowcharts, and sequence diagrams.
Render, validate, encode/decode PlantUML diagram-as-code; 22 diagram types. Free, no auth.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables AI assistants to generate UML diagrams through natural language by rendering PlantUML code into PNG or SVG images. Supports sequence diagrams, class diagrams, use case diagrams, and other UML chart types with Base64-encoded output.7-
- AlicenseNot gradedqualityBmaintenanceEnables astrological chart generation including natal charts, synastry, transits, composite charts, and planetary returns using the Kerykeion library. Supports multiple output formats (text, SVG, PNG) and customizable themes, house systems, and languages.MIT
- FlicenseNot gradedqualityDmaintenanceGenerates sequence diagram images from Mermaid syntax or natural language descriptions, supporting multiple output formats (SVG, PNG) with customizable themes and dimensions.-
- AlicenseNot gradedqualityDmaintenanceEnables processing of SGF (Smart Game Format) files to extract comprehensive game information and generate customizable visual board diagrams in PNG or SVG formats with multiple themes.8MIT
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/plemio/pedigree-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server