Grounds LLMs in real Scythian: Proto-Scythian lemmas, etymologies, Ossetian/Khotanese descendants.
Scored across 2 tools
The two tools overlap in that both can return the descendants payload (search inline by default, get_descendants for explicit fetches). However, the descriptions explicitly state the boundary — use get_descendants only when a search ran without inline payloads or left a match un-expanded — so an agent can reliably choose.
Both names share a consistent 'scythian_' namespace prefix, and the verb-oriented style (search, get_descendants) is readable. The pattern is not perfectly parallel (one bare verb vs. one verb_noun), but it is a minor deviation in an otherwise predictable scheme.
Two tools for a narrow, read-only Proto-Scythian etymology lookup is defensible, but it sits at the thin end of the scale. A single search call that already inlines payloads makes the second tool a near-redundant fallback, so the surface feels minimal rather than well-scoped.
The domain is lookup of lemmas and their reflex trees, and search plus explicit payload retrieval covers both directions (reconstruction and English gloss) plus the fallback expansion path. No obvious dead ends for a read-only scholarly reference tool, though there is no browse/enumerate capability.
Fetch the full descendants payload — etymology, glosses and the reflex tree (Sarmatian→Alanic→Ossetian, Saka→Khotanese) — for a lemma identified by a search result's descendant handle (entry_id + word_class). Use this only when a search ran without inline payloads or left a match un-expanded — a default search already returns each match's payload inline. Returns Markdown plus the payload as structuredContent with the shape {"result": } per the declared outputSchema — switch on result.category ('descendants' | 'not_found') before reading the body. Content from en.wiktionary.org (CC BY-SA 4.0).
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes | The bare lemma (no asterisk) from a search result's descendant handle, e.g. 'tiɣri', 'baga' — a typed leading asterisk is tolerated. | |
| word_class | Yes | The part-of-speech section from a search result's descendant handle, e.g. 'noun', 'adjective', 'proper noun'. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds substantial context: return format (Markdown + structuredContent), response shape, the result.category switch ('descendants'|'not_found'), and licensing. Missing explicit auth/rate-limit notes, keeping it just below top.
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?
Front-loads the purpose, then usage constraint, then return shape. Every sentence earns its place. Slightly dense but no filler; could be marginally tighter.
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 2-param read tool with an output schema, annotations, and 100% schema coverage, the description covers provenance, use conditions, return shape, and the category discriminator. Nothing an agent needs to call it correctly is missing.
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 coverage is 100%, so baseline is 3, but the description adds genuine meaning: it clarifies that entry_id + word_class come from a 'search result's descendant handle', which ties the parameters to their provenance beyond the schema's field-level docs.
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?
States a specific verb+resource ('Fetch the full descendants payload') and enumerates what it contains (etymology, glosses, reflex tree). Clearly distinguishes itself from the sibling scythian_search by naming search results as the input handle source.
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?
Explicitly states when to use it ('only when a search ran without inline payloads or left a match un-expanded') and when not to ('a default search already returns each match's payload inline'). This is exactly the routing guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look a Proto-Scythian lemma up on Wiktionary and return its senses plus its full descendants payload — the reconstructed etymology and the reflex tree down to Ossetian and Khotanese, attested scholarship, not invention. Plain ASCII spellings are folded to the reconstruction's diacritics and the result notes the resolution. With search_language='eng' the query is an English word instead: the result lists the lemmas whose glosses match it (the translations block) plus their expanded entries. Returns Markdown plus the same result as structuredContent matching the declared outputSchema.
Results are cached server-side; first-time queries reach the live upstream politely and calls are rate limited — on a rate-limit error, wait a few seconds and retry. Content is from en.wiktionary.org (CC BY-SA 4.0 — attribute and share alike if republished).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The word to look up, in the language search_language names. Scythian (default): a SINGLE Proto-Scythian lemma — plain ASCII works ('tigri' finds *tiɣri: macrons and carons are folded, and ɣ→g, δ→d, β→b, ə→e, θ→t or th), with or without the reconstruction asterisk. English (search_language='eng'): the English word whose Proto-Scythian equivalents you want — matched against every entry's glosses. | |
| max_forms | No | Optional override for how many descendants payloads to expand this call (0–12). On an uncached query each payload is one politely paced upstream fetch, so high values on cold queries are slow. Omit for the server default. | |
| include_forms | No | When true (default), each match's full descendants payload — etymology, glosses and the reflex tree down to Ossetian and Khotanese — is returned INLINE in ONE call, no follow-up scythian_get_descendants. Set false for a cheap screen of which entries exist. Bounded by a per-search cap — use max_forms to adjust per call. For eng queries this governs the expanded entries; the matched-lemmas list itself is always returned. | |
| search_language | No | Language the query word is in: 'xsc' (default) looks the Proto-Scythian lemma up directly; 'eng' finds the lemmas whose English glosses match the query (the local gloss index — reconstructed languages have no translation tables) and returns their full entries. Glosses are in English either way. | xsc |
| Name | Required | Description |
|---|---|---|
| found | Yes | False when nothing matched. For an eng query, True means the gloss index named Proto-Scythian lemmas — entries may still be empty when none of them could be expanded (see translations). |
| query | Yes | |
| source | No | |
| entries | No | |
| handles | No | |
| language | Yes | |
| translations | No | Populated only for eng queries (always [] for xsc): the Proto-Scythian lemmas whose glosses match the query. Entries/handles below are the expanded dictionary entries of those lemmas. |
| resolved_from | No | The original query when resolved via the index; else empty. xsc queries only — always empty for eng results. |
| search_method | No | How the match was found: 'direct' = the query itself matched; 'lemma_index' = an ASCII/diacritic-folded spelling resolved via the reverse index; 'translations' = an English query resolved via the local gloss index. |
| resolved_lemma | No | The lemma actually searched when resolved; else empty. xsc queries only — always empty for eng results. |
| forms_truncated | No | How many handles did NOT get an inline descendants payload because the per-search cap was reached. |
| translations_truncated | No | How many distinct matched lemmas were NOT expanded into entries because the per-search expansion cap was reached (they still appear under translations). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive/openWorld, and the description still adds real operational context: server-side caching, live upstream fetches on first-time queries with proactive politeness pacing, rate limiting with a concrete retry instruction, and the CC BY-SA 4.0 attribution obligation. That is substantive disclosure beyond what structured fields provide.
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?
Purpose and the direct-lookup default are front-loaded, and each following sentence carries a distinct payload (eng mode, return format, caching/rate limits, license). It is dense and somewhat prosey — the etymology/reflex-tree clause repeats the schema's own wording — but nothing is filler.
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?
An output schema exists so return values need not be explained, and the description still covers what an agent needs before calling: both query-language modes, folding behavior for ASCII input, caching and rate-limit backoff, and licensing constraints on reuse. Nothing material is missing for a read-only, open-world search 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 query, search_language, max_forms, and include_forms in detail. The description restates the ASCII-folding behavior ('tigri' finds *tiɣri') and both lookup modes, which is useful framing but largely repeats schema text rather than adding new semantics, so it sits at the baseline.
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 first sentence names a specific verb and resource ('Look a Proto-Scythian lemma up on Wiktionary') and specifies exactly what comes back (senses plus the full descendants payload down to Ossetian and Khotanese). It also flags the second mode (search_language='eng' reverse lookup) and explicitly names the sibling it replaces the need for ('no follow-up scythian_get_descendants'), so an agent can separate it from the other *_search tools.
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?
It states when the alternate mode applies ('With search_language=eng the query is an English word instead'), when the cheap path applies, and what to do on a rate-limit error (wait a few seconds and retry). It stops short of saying when to prefer this tool over the parallel language search tools or when to call scythian_get_descendants directly, so routing between siblings is only partly covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
scythian_get_descendants7 fields changedInput schema / properties / entry_id / patternAdded value: +"^\\*?[^\\W\\d_][\\w\\u0300-\\u036F'-]{0,79}$"Input schema / properties / word_class / enumAdded value: +[
+ "abbreviation",
+ "acronym",
+ "adjective",
+ "adverb",
+ "affix",
+ "article",
+ "character",
+ "circumfix",
+ "classifier",
+ "combining form",
+ "conjunction",
+ "contraction",
+ "counter",
+ "determiner",
+ "diacritical mark",
+ "idiom",
+ "infix",
+ "initialism",
+ "interfix",
+ "interjection",
+ "letter",
+ "ligature",
+ "noun",
+ "number",
+ "numeral",
+ "participle",
+ "particle",
+ "phrase",
+ "postposition",
+ "prefix",
+ "preposition",
+ "prepositional phrase",
+ "pronoun",
+ "proper noun",
+ "proverb",
+ "punctuation mark",
+ "romanization",
+ "root",
+ "suffix",
+ "symbol",
+ "verb"
+]Input schema / properties / word_class / maxLengthRemoved value: -24Input schema / properties / word_class / minLengthRemoved value: -1Input schema / properties / word_class / patternRemoved value: -"^[a-z ]+$"Output schema / $defs / DescendantsNotFound / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Proto-Scythian reconstruction entries. Wikimedia Foundation. Text available under CC BY-SA 4.0; attribution and share-alike required when republishing. (CC BY-SA 4.0)"New value: +"Wiktionary, the free dictionary (en.wiktionary.org), Proto-Scythian reconstruction entries. Wikimedia Foundation. Text available under CC BY-SA 4.0; attribution and share-alike required when republishing. (CC BY-SA 4.0: https://creativecommons.org/licenses/by-sa/4.0/) Adapted: reformatted and condensed from the original."Output schema / $defs / ScythianDescendants / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Proto-Scythian reconstruction entries. Wikimedia Foundation. Text available under CC BY-SA 4.0; attribution and share-alike required when republishing. (CC BY-SA 4.0)"New value: +"Wiktionary, the free dictionary (en.wiktionary.org), Proto-Scythian reconstruction entries. Wikimedia Foundation. Text available under CC BY-SA 4.0; attribution and share-alike required when republishing. (CC BY-SA 4.0: https://creativecommons.org/licenses/by-sa/4.0/) Adapted: reformatted and condensed from the original."scythian_search3 fields changedOutput schema / $defs / DescendantsNotFound / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Proto-Scythian reconstruction entries. Wikimedia Foundation. Text available under CC BY-SA 4.0; attribution and share-alike required when republishing. (CC BY-SA 4.0)"New value: +"Wiktionary, the free dictionary (en.wiktionary.org), Proto-Scythian reconstruction entries. Wikimedia Foundation. Text available under CC BY-SA 4.0; attribution and share-alike required when republishing. (CC BY-SA 4.0: https://creativecommons.org/licenses/by-sa/4.0/) Adapted: reformatted and condensed from the original."Output schema / $defs / ScythianDescendants / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Proto-Scythian reconstruction entries. Wikimedia Foundation. Text available under CC BY-SA 4.0; attribution and share-alike required when republishing. (CC BY-SA 4.0)"New value: +"Wiktionary, the free dictionary (en.wiktionary.org), Proto-Scythian reconstruction entries. Wikimedia Foundation. Text available under CC BY-SA 4.0; attribution and share-alike required when republishing. (CC BY-SA 4.0: https://creativecommons.org/licenses/by-sa/4.0/) Adapted: reformatted and condensed from the original."Output schema / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Proto-Scythian reconstruction entries. Wikimedia Foundation. Text available under CC BY-SA 4.0; attribution and share-alike required when republishing. (CC BY-SA 4.0)"New value: +"Wiktionary, the free dictionary (en.wiktionary.org), Proto-Scythian reconstruction entries. Wikimedia Foundation. Text available under CC BY-SA 4.0; attribution and share-alike required when republishing. (CC BY-SA 4.0: https://creativecommons.org/licenses/by-sa/4.0/) Adapted: reformatted and condensed from the original."get_descendants_scythianscythian_get_descendantsscythian_searchsearch_scythianget_descendants_scythiansearch_scythianGrounds LLMs in real Old Norse: lemmas, mediopassive paradigms, English→Old Norse lookup.
Grounds LLMs in real Church Slavonic: Wiktionary lemmas, dual-number paradigms, transliteration.
Grounds LLMs in real Latin: Wiktionary lemmas, Morpheus inflections, citations.
Grounds LLMs in the real Livonian dictionary: attested words, inflections, romanization.
Add one secure layer between your agents and this server.