Skip to main content
Glama

Reconstruction walk

nabu_etym
Read-only

Trace an attested lemma to its reconstructed ancestors: submit a word like deus or guþ to retrieve crosswalk entries with glosses, matching reflexes, cognates, and nested proto-language chains.

Instructions

Walk the reconstruction crosswalk (the comparativist's join): give an ATTESTED lemma (богъ, guþ, deus) and get every reconstructed ancestor whose Wiktionary descendants name it — Proto-Slavic, PIE, Proto-Germanic, Proto-Balto-Slavic, Proto-West Germanic, Proto-Italic, Proto-Indo-Iranian (kaikki.org extracts, CC-BY-SA + GFDL; PRESERVE license fields when quoting). Each entry carries the *headword, gloss, the reflex that matched (matched_via, incl. its borrowed loan flag), its COGNATES across languages with corpus attestation counts (attested_count = gold-lemma passages in this catalog; null = not attested here, an absence not a zero) and per-edge borrowed flags, and nested ancestors — the full chain up the proto shelves (прьстъ→*pьrstъ→*pírštan→*per-), bounded because each shelf enters a walk once; a loan edge carries edge_borrowed: true. Romanization bridges scripts: guþ reaches *gudą through Gothic 𐌲𐌿𐌸. lang scopes the match to one attested language; a leading asterisk (*bogъ) looks a reconstruction up directly. A lemma with NO crosswalk path falls back to the dictionary shelf (nabu_define's own lookup): the reply then carries dictionary_entries (the nabu_define payload shape — a prose etymological article like Vasmer's still answers) plus an explanatory note; a genuine total miss enumerates the crosswalk's live shelves. Cognate lists are bounded (attested first, 20 shown) with honest totals; nabu etym (CLI) is unbounded.

Input Schema

NameRequiredDescriptionDefault
langNoScope the reflex match to one attested language (ISO-639-3: chu, orv, got, grc, lat, ang, san, …).
lemmaYesAn attested lemma (богъ, guþ, deus) — or a reconstruction with a leading asterisk (*bogъ) for a direct lookup.
limitNoMaximum reconstruction entries returned.
include_restrictedNoAlso serve research_private/restricted material. Default false and deliberately so: this surface must never leak private or license-restricted texts casually. Set true only when the requester understands and will honor the restriction.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.7.0

TDQS

A4.4/5.0
Behavior5/5

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

The only annotation is readOnlyHint, so the description carries most of the behavioral burden and does so richly: license-preservation obligations, the deliberate default of include_restricted=false, null vs zero attestation semantics, per-edge borrowed flags, bounded cognate lists with honest totals, and the fallback/total-miss reply shapes.

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?

Purpose is front-loaded and nearly every clause carries substantive semantics (matched_via, borrowed flags, ancestors chain, fallback). However, the single monolithic paragraph with heavy parentheticals and Unicode examples makes it harder to scan than it needs to be.

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?

There is no output schema, yet the description thoroughly delineates the return shape: headword, gloss, matched_via, cognates with attested_count semantics, nested ancestors, and the `dictionary_entries` fallback payload. An agent has enough to call and interpret the result.

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 100% and every parameter already has its own description. The description restates the `lang` scoping and the asterisk convention for `lemma` but adds no syntax or format detail beyond the schema, and does not expand on `limit` or `include_restricted`. 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?

Opens with a specific verb and resource: 'Walk the reconstruction crosswalk ... give an ATTESTED lemma ... and get every reconstructed ancestor.' It names the proto shelves returned, the fallback to nabu_define's dictionary shelf, and the unbounded CLI, so an agent can distinguish it from nabu_search/nabu_define without opening the schema.

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 clear invocation guidance: pass an attested lemma, or a leading asterisk (*bogъ) for a direct reconstruction lookup; `lang` scopes the reflex; missing crosswalk paths fall back to dictionary entries. It stops short of explicitly recommending a sibling (nabu_cognates, nabu_define) for cases where the agent should not use this tool.

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