genealogy-mcp

Overview Schema Source Related Servers Discussions Admin

dna_match

Read-only

Estimate which relationships a DNA match fits from shared autosomal DNA in centimorgans using Shared cM Project 4.0 ranges, closest first. Verify options with documents and kinship.

Instructions

Which relationships a DNA match fits, from the amount of shared DNA (Shared cM Project 4.0 ranges), closest first. Several always fit: use documents (and the kinship tool) to decide.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "shared_cm": "<shared_cm>"
    },
    "name": "dna_match"
  }
}

Input Schema

Name	Required	Description	Default
`lang`	No		en
`shared_cm`	Yes	Total shared autosomal DNA in centimorgans (cM), as AncestryDNA, MyHeritage, 23andMe, FTDNA or GEDmatch report it

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.1Oct 16, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/openWorld annotations, the description discloses an important behavioral fact: results are non-unique ('Several always fit'), so the output is a candidate set rather than a verdict. It also credits the underlying methodology (Shared cM Project 4.0 ranges). It doesn't say how many candidates come back, but the output schema presumably covers that.

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, zero filler. The core purpose is front-loaded and the disambiguation caveat follows immediately after.

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 two-parameter, single-required-input tool with an output schema present, the description supplies everything the agent needs: what the result means, its ordering, and that the result is inherently ambiguous. Return-value details are correctly left to the output schema.

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 coverage is 50%: shared_cm is fully documented in the schema, while lang has only an enum and default with no prose. The description adds no parameter-level detail (no unit hints, no format/locale behavior), so it neither compensates for the gap nor goes beyond the schema. Baseline 3 is appropriate.

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 states a concrete transformation (shared DNA in cM → candidate relationships) and names the source of the ranges (Shared cM Project 4.0), plus the output ordering ('closest first'). It also distinguishes itself from a sibling by explicitly naming the 'kinship tool' as the complementary step rather than a substitute.

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?

It gives real routing guidance: when several relationships fit, use documents and the kinship tool to disambiguate. What's missing is a positive trigger for when to reach for dna_match in the first place (e.g., vs. the kinship or check_match tools) — the agent must infer that this is the cM-interpretation step.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.