Grounds LLMs in real Church Slavonic: Wiktionary lemmas, dual-number paradigms, transliteration.
Scored across 4 tools
The four tools have largely distinct purposes: transliterate/detransliterate are clearly labeled inverses, and search vs get_inflections are separated by the description (search inlines forms; get_inflections is a fallback for un-expanded matches). There is mild overlap since search already returns declension/conjugation tables that get_inflections also fetches, but the descriptions clarify when each applies.
All names share a predictable slavonic_ prefix and are snake_case. Minor deviation: get_inflections uses a get_ verb_noun form while the others are bare verbs, but the pattern is still readable and cohesive.
Four tools is a tight, well-scoped set for a narrow transliteration-plus-dictionary domain, with each tool earning its place. It leans slightly thin but nothing feels redundant or missing among the core operations.
The surface covers both transliteration directions plus word lookup (OCS→English and English→OCS) and full inflection paradigms, which is solid lifecycle coverage for the domain. Minor gaps remain around batch processing or richer morphological queries, but agents can work around them.
Find the real Church Slavonic word(s) whose scientific-Latin transliteration
matches this input — the inverse direction of slavonic_transliterate. Because
transliterate is lossy, this is a LOOKUP against the words already in the
dictionary cache: attested spellings (normalized OCS Cyrillic) come back as
source=dictionary. If none match, a single best-effort reconstruction is returned
(source=reconstruction, approximate=true) — a guess in normalized OCS Cyrillic, not
attested, with no Glagolitic or liturgical marks. Coverage grows as words are
cached, so an identical query may return a reconstruction now and a dictionary hit
later.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Scientific-Latin transliteration of Church Slavonic to resolve back to real orthography. Returns the attested dictionary spelling(s) whose transliteration matches (source=dictionary, exact) — several may match one ambiguous key. On a miss, a single best-effort reconstruction in normalized OCS Cyrillic (source=reconstruction, approximate=true), which is a guess: transliterate is lossy, so case, digraph boundaries (д+з vs ѕ) and the оу/ѿ ligatures cannot be recovered, and no Glagolitic or liturgical marks are produced. |
| Name | Required | Description |
|---|---|---|
| candidates | Yes | |
| approximate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/openWorld annotations, it discloses that this is a cache lookup rather than a computed inverse because transliteration is lossy, what each result source means (attested vs reconstructed), that reconstructions lack Glagolitic/liturgical marks, and that coverage grows over time (a repeated query may change tier). This is unusually rich behavioral context.
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-loaded with the purpose and the inverse-relationship, then the failure-mode explanation. Dense but every sentence carries needed information; slightly long for a single-parameter tool.
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 the two result modes, their approximate flag, and the coverage-growth caveat, which is everything an agent needs to call it correctly.
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% and the parameter's own schema description already covers the lossy-recovery caveats and the multiple-match ambiguity, so the tool description adds little beyond structured data. Baseline 3 applies.
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 ('Find the real Church Slavonic word(s) whose scientific-Latin transliteration matches this input') and explicitly frames itself as the inverse of the sibling `slavonic_transliterate`, so an agent can distinguish it from `slavonic_search` and `slavonic_get_inflections` without opening a schema.
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?
Names the direction of use relative to the sibling transliterate tool and clearly describes the two outcome branches (dictionary hit vs failed lookup). It does not spell out explicit conditions for preferring any of the other siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full declension (nominals) or conjugation (verbs) table for a lemma identified by a search result's inflection handle (entry_id + word_class). Use this only when a search ran without inline forms or left a match un-expanded — a default search already returns each match's table inline. Returns Markdown plus the table as structuredContent with the shape {"result": } per the declared outputSchema — switch on result.category ('nominal' | 'verbal' | 'not_found') before reading the body. Content from en.wiktionary.org (CC BY-SA 4.0).
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes | The Wiktionary page title (the Cyrillic lemma) from a search result's inflection handle, e.g. 'богъ', 'глаголати'. | |
| word_class | Yes | The part-of-speech section from a search result's inflection handle, e.g. 'verb', 'noun', 'adjective'. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/openWorldHint/destructiveHint=false, so the safety profile is covered. The description adds genuinely non-annotated behavior: the return format (Markdown plus structuredContent), the {'result': <paradigm>} shape, and the instruction to branch on result.category ('nominal' | 'verbal' | 'not_found') before reading the body. It loses a point only because part of the return detail is restated from the declared output schema.
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-loaded with the core purpose, followed by usage constraint, then return handling and license. Every sentence carries information and the ordering is logical; it is slightly dense but not padded.
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?
With an output schema present the description need not detail return values, yet it usefully flags the category switch and not_found case, covers when to invoke, and includes attribution/licensing. Nothing an agent needs to call this 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 description coverage is 100%, and the schema already explains both entry_id (Wiktionary page title / Cyrillic lemma from the inflection handle) and word_class (part-of-speech section). The description only restates the parameters as an 'inflection handle (entry_id + word_class)' pairing, adding little beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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 and resource ('Fetch the full declension (nominals) or conjugation (verbs) table for a lemma'), and distinguishes the tool from its search siblings by noting that a default search already returns tables inline. An agent can tell exactly what it retrieves and when it differs from slavonic_search without opening either schema.
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?
Gives an explicit when-to-use ('only when a search ran without inline forms or left a match un-expanded') and a when-not ('a default search already returns each match's table inline'). It also states the prerequisite source of the inputs (a search result's inflection handle), so the agent knows this is a second-step tool, not a first entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look an Old Church Slavonic word up on Wiktionary and return its senses plus full declension/conjugation tables — attested content (singular, dual and plural), not invented. Any form of the word works; an inflected query is resolved to its lemma automatically via previously cached paradigms and the result notes the resolution. With search_language='eng' the query is an English word instead: the result lists its per-sense Old Church Slavonic equivalents (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. Church Slavonic (default): a SINGLE Old Church Slavonic word in Cyrillic, any form — an inflected form ('бога') is resolved to its lemma ('богъ') automatically via cached paradigms, and the result says so; normalized OCS spelling works best, but titlos/accents and modern-Cyrillic respellings (ы for ꙑ) are folded. English (search_language='eng'): the English word whose Old Church Slavonic equivalents you want — multiword entries like 'apple tree' work. | |
| max_forms | No | Optional override for how many inflection tables to expand this call (0–12). On an uncached query each table 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 declension/conjugation table is returned INLINE — usable cases/tenses (singular, dual AND plural) in ONE call, no follow-up slavonic_get_inflections. 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 OCS entries; the per-sense translations list itself is always returned. | |
| search_language | No | Language the query word is in: 'chu' (default) looks the Old Church Slavonic word up directly; 'eng' finds the OCS equivalents of an English word (per-sense, from Wiktionary's translation tables) and returns their full entries. Glosses are in English either way. | chu |
| Name | Required | Description |
|---|---|---|
| found | Yes | False when nothing matched. For an eng query, True means Old Church Slavonic translations were found — 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 chu): the OCS terms each English sense translates to, in sense order. Entries/handles below are the expanded dictionary entries of those terms. |
| resolved_from | No | The original inflected query when resolved; else empty. chu queries only — always empty for eng results. |
| search_method | No | How the match was found: 'direct' = the query itself matched; 'lemma_index' = an inflected form resolved via a previously cached paradigm; 'translations' = an English query resolved via Wiktionary translation tables. |
| resolved_lemma | No | The lemma actually searched when resolved; else empty. chu queries only — always empty for eng results. |
| forms_truncated | No | How many handles did NOT get an inline table because the per-search cap was reached. |
| translations_truncated | No | How many distinct translated 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?
Goes well beyond the annotations (readOnly/openWorld/idempotent), disclosing server-side caching, polite paced upstream fetches, rate limiting with a concrete recovery ('wait a few seconds and retry'), and CC BY-SA 4.0 attribution obligations. These are real operational traits an agent could not infer from structured fields.
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-loaded with purpose then the eng-mode variant, caching/rate-limit notes, and licensing. Dense but every sentence carries information an agent needs — the only mild bloat is restating the eng-mode behavior that also appears in the schema.
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-value detail is unnecessary; the description instead covers modes, caching, error recovery, and licensing. For a 4-param lookup tool with rich annotations and an output schema, 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 description coverage is 100%, so the schema already documents all four parameters thoroughly (including max_forms pacing and include_forms semantics). The description reinforces search_language='eng' behavior and the lemma-resolution guarantee but adds little syntax or meaning the schema lacks; baseline 3 is appropriate.
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 ('Look an Old Church Slavonic word up on Wiktionary') and names exactly what it returns: senses plus full declension/conjugation tables. It also distinguishes itself from the sibling slavonic_get_inflections by noting tables come back INLINE with 'no follow-up slavonic_get_inflections.'
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?
Gives clear context: any inflected form works and resolves to a lemma, and search_language='eng' switches to reverse lookup. It also advises include_forms=false for 'a cheap screen of which entries exist.' However it never explicitly states when to prefer the sibling slavonic_get_inflections or slavonic_transliterate, so the routing guidance is implicit rather than complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render Church Slavonic — Cyrillic or Glagolitic — in the scientific Latin transliteration Wiktionary uses (богъ → bogŭ, ⰱⱁⰳⱏ → bogŭ). Liturgical reading marks (titlos, accents) are dropped and late Church Slavonic spellings folded, so copied liturgical text works as-is. Returns Markdown plus the transliterated output as structuredContent matching the declared outputSchema. Pure local transform: no dictionary lookup and no network.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Church Slavonic text to transliterate — Cyrillic and/or Glagolitic, one word or whole lines. Liturgical reading marks (titlos, accents, breathings) are dropped and late Church Slavonic spellings folded, so text copied from a liturgical source or a lyrics sheet works as-is. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The scientific transliteration. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely non-structured behavior: liturgical marks (titlos, accents, breathings) are dropped, late spellings are folded, and the transform is purely local with no dictionary lookup or network call, plus the response shape. It does not discuss limits such as the 4000-character cap or failure behavior on mixed-script input.
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?
Four sentences, front-loaded with the verb and an illustrative example, then the transformation behavior, then the return format. Little waste, though the closing sentence about Markdown and structuredContent partially restates what the declared outputSchema already conveys.
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 single-parameter, deterministic local transform with an output schema and full annotation coverage, the description supplies everything needed to call it correctly: input scope, scripts accepted, preprocessing behavior, and side-effect freedom. The only gap is routing guidance among the sibling tools, which leaves a small ambiguity for an agent choosing between transliterate and detransliterate.
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% and the single 'text' parameter is already well documented, so the baseline is 3. The description goes slightly beyond the schema by showing an actual input-to-output mapping and confirming that both Cyrillic and Glagolitic scripts are accepted within the same argument.
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 (transliterate), a specific resource (Church Slavonic, Cyrillic or Glagolitic), and the target convention (scientific Latin as used by Wiktionary), with a concrete worked example (богъ → bogŭ). The directionality is explicit, which cleanly separates it from the slavonic_detransliterate sibling even without naming it.
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?
The description gives an implicit use case — liturgical text copied from a source or lyrics sheet works as-is — but never states when to prefer this tool over slavonic_detransliterate or the search/inflection siblings, and offers no exclusions or prerequisites. Usage is inferable from the transformation direction rather than spelled out.
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.
slavonic_get_inflections8 fields changedInput schema / properties / entry_id / patternAdded value: +"^[Ѐ-ӿꙀ-ꚟⰀ-ⱟ][Ѐ-ӿꙀ-ꚟⰀ-ⱟ\\-']{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 / ParadigmNotFound / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Old Church Slavonic 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), Old Church Slavonic 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 / SlavonicNominalParadigm / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Old Church Slavonic 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), Old Church Slavonic 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 / SlavonicVerbalParadigm / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Old Church Slavonic 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), Old Church Slavonic 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."slavonic_search4 fields changedOutput schema / $defs / ParadigmNotFound / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Old Church Slavonic 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), Old Church Slavonic 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 / SlavonicNominalParadigm / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Old Church Slavonic 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), Old Church Slavonic 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 / SlavonicVerbalParadigm / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Old Church Slavonic 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), Old Church Slavonic 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), Old Church Slavonic 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), Old Church Slavonic 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."slavonic_detransliterateget_inflectionssearch_slavonicslavonic_get_inflectionsslavonic_searchslavonic_transliteratetransliterate_slavonicget_inflectionssearch_slavonictransliterate_slavonicGrounds LLMs in real Latgalian: Wiktionary lemmas, inflections, romanization.
Grounds LLMs in real Latin: Wiktionary lemmas, Morpheus inflections, citations.
Grounds LLMs in the real Livonian dictionary: attested words, inflections, romanization.
Grounds LLMs in real Old Norse: lemmas, mediopassive paradigms, English→Old Norse lookup.
Add one secure layer between your agents and this server.