Skip to main content
Glama
Sign In
german-archives-mcp

german-archives-mcp

by ianderso
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

hessen_search

Read-only

Search digitised Hessian civil registers by place, year, and register type to find LAGIS catalogue entries with archive signatures and links; results are finding aids, not the records themselves.

Instructions

Find the digitised civil registers of a Hesse place: the Hessisches Landesarchiv's.

Every Standesamt's secondary registers, from 1874/1876 to 1900 (births), 1930 (marriages) and 1965 (deaths), as LAGIS catalogues them. Each hit has a signature (HStAM 922 Nr. 6013), years and LAGIS link; read a page with hessen_image. A hit is a finding aid, not the record. No hits is not a negative: try the Standesamt, or no year.

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": {
      "place": "<place>"
    },
    "name": "hessen_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage of results, 1-based.
rowsNoHits per page (1-25).
yearNoA year the register's title names, e.g. 1880.
placeYesA Standesamt or any place in today's Hesse, e.g. 'Korbach', or a village, which finds the registers of the Standesamt it belonged to.
registerNoOne register type; empty keeps all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond readOnlyHint/openWorldHint it discloses the coverage window per register type (1874/1876-1900 births, 1930 marriages, 1965 deaths), what a hit contains (signature, years, LAGIS link), and the crucial caveat that a hit is a finding aid rather than the record and that zero hits is not a negative. That is real behavioral context the annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, then scope, then return shape, then fallback advice. The phrase 'the Hessisches Landesarchiv's.' is awkward and some date detail is dense, but no sentence is wasted.

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?

Complete for a read-only search with no output schema: it describes what comes back per hit, the historical coverage limits, and what to do when a search returns nothing, which is the main failure mode an agent would hit.

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 100%, so place, year, register, page and rows are already documented. The description reinforces the place-semantics nuance (a village resolves to its Standesamt) and hints that year matches a year in the register title, but adds little the schema does not already state.

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 plus resource: 'Find the digitised civil registers of a Hesse place', with the holding archive (Hessisches Landesarchiv/LAGIS) and coverage dates named. It also separates itself from the sibling hessen_image by framing hits as catalogue entries to be read elsewhere.

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?

Gives concrete follow-up guidance: read a page with hessen_image, and if there are no hits, retry with the Standesamt name or without a year. It stops short of explicit when-not-to-use guidance, e.g. that other regional searches serve non-Hesse places.

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

Deploy Server

Other Tools