genealogy-mcp

Overview Schema Source Related Servers Discussions Admin

draft_archive_request

Read-only

A draft letter to a registry office or an archive (Russian ZAGS, state, military and FSB archives; any archive in English, Spanish or Portuguese), with what to attach. Gaps are left in [brackets]. The user sends it — not the tool.

Instructions

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": {
      "kind": "<kind>"
    },
    "name": "draft_archive_request"
  }
}

Input Schema

Name	Required	Description
`born`	No
`died`	No
`kind`	Yes	zags: Registry office (ZAGS): a copy of a birth/marriage/death record; state_archive: State (regional) archive: genealogical search in parish registers, revision lists, etc.; military: Military archive (TsAMO, RGVA, RGVIA): service and losses; repression: FSB / MVD / SBU archive: investigation or deportation file; generic_en: Any archive, in English; generic_es: Any archive, in Spanish (Latin America, Spain); generic_pt: Any archive, in Portuguese (Brazil, Portugal)
`what`	No	What is requested
`place`	No
`years`	No
`person`	No
`spouse`	No
`archive`	No	Name and address of the archive
`details`	No
`parents`	No
`project`	No
`relation`	No	Who the requester is to the person
`requester`	No
`birth_place`	No
`death_place`	No
`requester_address`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.7.0Oct 22, 2026
- addedInput schema / properties / project
```
Added value: +{
+  "default": "",
+  "title": "Project",
+  "type": "string"
+}
```
First observedv0.5.1Oct 16, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known; the description adds genuinely new behavior — the output is a letter with deliberate [bracketed] placeholders and the tool never sends anything. That is exactly the kind of context annotations cannot express. It stops short of describing length, format, or what an incomplete draft looks like, but the key traits are covered.

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?

Three short sentences with zero filler; the artifact is stated first, then the placeholder convention, then the crucial send-boundary note. Every sentence earns its place.

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?

An output schema exists, so return shape needn't be explained, and the read-only annotation covers safety. What is missing given 17 mostly-undescribed inputs is guidance on which fields matter for which 'kind' (e.g. that zags wants born/died/place while repression wants person/details) — an agent can call the tool but cannot fill it well from the description alone.

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?

Seventeen parameters at only 24% schema description coverage, and the description offers almost nothing: aside from 'with what to attach' hinting at details, it never explains what 'what', 'details', 'project', 'archive', or 'years' should contain or how they interact. The heavy lifting falls on self-explanatory field names, which is not enough to compensate for the low coverage.

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?

Specific verb+resource: 'A draft letter to a registry office or an archive'. The description scopes the artifact (a letter with attachments, [bracketed] gaps) and the supported jurisdictions/languages, and explicitly states 'The user sends it — not the tool', which prevents the agent from misreading this as a send/dispatch tool. No sibling tool overlaps with drafting correspondence, so differentiation is implicit but effectively complete.

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 clear context for when to reach for it (need a ready-to-send request letter for ZAGS, state, military or FSB archives, or an English/Spanish/Portuguese generic archive) and rules out the send step. It does not say what to do instead when no archive letter is needed, or which upstream tools (find_sources, where_are_records, plan_research) should precede it.

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