Grounds LLMs in real Latgalian: Wiktionary lemmas, inflections, romanization.
Scored across 4 tools
The romanize/deromanize pair form a clearly distinct inverse direction, and search vs get_inflections are the only real overlap. The descriptions explicitly delineate the boundary (get_inflections is a fallback when search omits inline forms), so an agent can disambiguate, though the two still both surface inflection tables.
All four tools share a consistent latgalian_ prefix and snake_case, and three use a bare verb (romanize, deromanize, search). get_inflections introduces a get_ verb form, a minor deviation from the otherwise uniform verb style.
Four tools is lean but well-scoped for a word-lookup/romanization server, with each tool earning its place (both transform directions, search, and table retrieval). It sits at the lower edge of comfortable but is not thin enough to be a problem.
The surface covers both romanization directions plus Wiktionary search and inflection retrieval, forming a coherent lifecycle for language lookup. Gaps are minor (no direct entry-by-id fetch or reverse English→Latgalian beyond the search_language flag), but core workflows are covered.
Find the real Latgalian word(s) whose pronunciation-romanization matches this
clean-ASCII input — the inverse direction of latgalian_romanize. Because
romanize is lossy, this is a LOOKUP against the words already in the dictionary
cache: attested spellings come back as source=dictionary. If none match, a single
best-effort reconstruction is returned (source=reconstruction, approximate=true) —
a guess, not attested. 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 | Romanized (clean-ASCII) Latgalian text to resolve back to real orthography. Returns the attested dictionary spelling(s) whose romanization matches (source=dictionary, exact) — several may match one ambiguous key. On a miss, a single best-effort reconstruction (source=reconstruction, approximate=true), which is a guess: romanize is lossy, so case, the plain o/ō, the cedilla on ŗ and macron length cannot be recovered, and a soft-consonant glide (ly/ny/ky/gy) may be over-restored. |
| 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 the lossiness of romanization, the two distinct result modes (source=dictionary vs source=reconstruction, approximate=true), that reconstruction is a guess rather than attested, and that caching causes non-deterministic results over time. This is exactly the behavioral context annotations cannot carry.
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 and the inverse relationship to latgalian_romanize, then the lookup-vs-reconstruction behavior. Efficient, though the lossiness details slightly duplicate the parameter schema description.
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 and the annotations cover the safety profile, yet the description still conveys the essential return semantics (dictionary hit vs approximate reconstruction). 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?
With only one parameter and 100% schema description coverage, the schema already documents the input, its ASCII constraint, the multiple-match possibility, and the recovery limitations. The description restates this material rather than adding meaning beyond the schema, so the 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 and resource ('Find the real Latgalian word(s) whose romanization matches'), and explicitly positions itself as the inverse of the sibling `latgalian_romanize`. An agent can distinguish it from latgalian_search and latgalian_romanize 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?
Explains the operating context clearly: it is a lookup against the dictionary cache, with reconstruction as fallback, and notes coverage grows so results may change. It does not explicitly say when to prefer a sibling such as latgalian_search over this tool, so it falls short of full when/when-not guidance.
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 — positive AND negative) tables 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 lemma) from a search result's inflection handle, e.g. 'akmiņs', 'byut'. | |
| 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 readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the return format (Markdown plus structuredContent), the need to switch on result.category ('nominal' | 'verbal' | 'not_found') before reading the body, and the CC BY-SA 4.0 source. Slight redundancy with the declared outputSchema keeps it from a 5.
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 action and scope, and every sentence carries information (scope, output shape, category switch, license). The nested parentheticals make it dense but not wasteful; it 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?
Given an output schema exists, the description need not explain returns, yet it usefully highlights the category discriminator and the Markdown/structuredContent duality. With both params documented and safety covered by annotations, an agent has everything needed 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 both parameters are well documented in the schema, so the baseline is 3. The description adds meaning by framing entry_id + word_class as an 'inflection handle' sourced from a search result, giving provenance for the values that the schema alone does not fully convey.
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 ('Fetch') plus the exact resource (full declension for nominals, conjugation for verbs, positive and negative) for a lemma identified by a search result's inflection handle. It also implicitly distinguishes itself from latgalian_search by noting the search's inline-form behavior, so an agent can tell the two apart.
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 scopes when to use it ('only when a search ran without inline forms or left a match un-expanded') and when not to (a default search already returns each match's table inline). This is a clear when/when-not statement rather than an implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Strip Latgalian orthography down to clean, pronounceable ASCII for an
English-trained downstream (a voice/TTS, a search box). See the text
parameter doc for the exact letter mappings. Returns Markdown plus the
romanized output as structuredContent matching the declared outputSchema.
Pure local transform: no dictionary lookup, no network, and the output is
always ASCII.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Latgalian text to reduce to clean, pronounceable ASCII. Lowercases and maps each special letter to an English-readable spelling: the macron vowels double (ā→aa, ē→ee, ī→ee, ō→o, ū→oo), the caron consonants respell (č→ch, š→sh, ž→zh), and the soft consonants take a 'y' glide (ļ→ly, ņ→ny, ķ→ky, ģ→gy; ŗ→r). A one-way fold — diacritics are dropped, never added. Pass a word, phrase, or several lines; whitespace and punctuation are preserved. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The romanized ASCII output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive and closed-world, so safety is covered. The description adds genuine behavioral context beyond that: it is a pure local transform, performs no dictionary lookup or network access, and always emits ASCII. It does not detail failure behavior on empty or unsupported 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 short sentences, front-loaded with the purpose before the mechanics. Each sentence carries information (purpose, mapping pointer, return shape, execution profile), though the parenthetical examples are slightly redundant phrasing rather than new content.
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 the brief note about Markdown plus structuredContent is sufficient and return values need no elaboration. For a single-parameter, local, read-only transform the description covers purpose, execution profile, and output shape adequately; only edge-case behavior is left unstated.
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 there is a single parameter, so the schema itself carries the semantics (including the full letter-mapping table). The description usefully points the agent to the `text` parameter doc, but adds no mapping detail of its own beyond what the schema already states.
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 description names a specific verb and resource (romanize Latgalian orthography to ASCII) and states the downstream consumer (TTS, search box), which is unusually concrete. It doesn't explicitly name or contrast with the sibling latgalian_deromanize, so the direction is only inferred from the verb. Clear, but short of full sibling differentiation.
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 gives a clear use case — converting Latgalian for an English-trained downstream such as voice/TTS or a search box — which tells the agent when this tool is appropriate. It stops short of stating exclusions or explicitly routing the agent to latgalian_deromanize for the inverse operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look a Latgalian word up on Wiktionary and return its senses plus full declension/conjugation tables — attested content, 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 Latgalian 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. Latgalian (default): a SINGLE Latgalian word, any form — an inflected form ('akmiņa') is resolved to its lemma ('akmiņs') automatically via cached paradigms, and the result says so; diacritics are optional once a paradigm is cached ('akmins' finds 'akmiņs'). English (search_language='eng'): the English word whose Latgalian 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 in ONE call, no follow-up latgalian_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 Latgalian entries; the per-sense translations list itself is always returned. | |
| search_language | No | Language the query word is in: 'ltg' (default) looks the Latgalian word up directly; 'eng' finds the Latgalian equivalents of an English word (per-sense, from Wiktionary's translation tables) and returns their full entries. Glosses are in English either way. | ltg |
| Name | Required | Description |
|---|---|---|
| found | Yes | False when nothing matched. For an eng query, True means Latgalian 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 ltg): the Latgalian 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. ltg 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. ltg 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?
Beyond the readOnly/idempotent/openWorld annotations, it discloses server-side caching, live-upstream pacing, rate limiting with retry guidance, the CC BY-SA 4.0 attribution obligation, and that output is Markdown plus structuredContent. This is unusually complete 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-loads the core behavior (lookup + tables) before the eng-mode and caching details, and every sentence carries information. It is dense and slightly long, but no sentence 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?
With an output schema present and annotations covering the safety profile, the description still supplies everything an agent needs: modes, caching, rate-limit handling, licensing, and the relationship to the sibling inflection 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 coverage is 100% so the baseline is 3, but the description adds semantics the schema doesn't stress: that diacritics are optional once a paradigm is cached and that eng queries accept multiword entries. It also ties max_forms/rate-limit cost together rather than just restating the schema.
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 (look up) and resource (Latgalian word on Wiktionary), plus two distinct modes (ltg direct lookup, eng reverse translation). It explicitly distinguishes itself from the sibling latgalian_get_inflections by noting forms come inline in one call.
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 concrete when-to-use guidance: any inflected form works, eng mode for reverse lookup, include_forms=false for a cheap existence screen, and max_forms for per-call expansion. It also names the alternative workflow (no follow-up latgalian_get_inflections) and prescribes retry behavior on rate-limit errors.
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.
latgalian_get_inflections8 fields changedInput schema / properties / entry_id / patternAdded value: +"^[A-Za-zĀāČčĒēĪīŪūŌōŖŗŠšŽžĻļŅņĶķĢģ][A-Za-zĀāČčĒēĪīŪūŌōŖŗŠšŽžĻļŅņĶķĢģ\\-']{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 / LatgalianNominalParadigm / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Latgalian 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), Latgalian 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 / LatgalianVerbalParadigm / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Latgalian 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), Latgalian 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 / ParadigmNotFound / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Latgalian 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), Latgalian 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."latgalian_search4 fields changedOutput schema / $defs / LatgalianNominalParadigm / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Latgalian 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), Latgalian 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 / LatgalianVerbalParadigm / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Latgalian 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), Latgalian 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 / ParadigmNotFound / properties / source / defaultPrevious value: -"Wiktionary, the free dictionary (en.wiktionary.org), Latgalian 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), Latgalian 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), Latgalian 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), Latgalian 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."latgalian_deromanizelatgalian_get_inflectionslatgalian_romanizelatgalian_searchGrounds LLMs in the real Livonian dictionary: attested words, inflections, romanization.
Grounds LLMs in real Latin: Wiktionary lemmas, Morpheus inflections, citations.
Grounds LLMs in real Church Slavonic: Wiktionary lemmas, dual-number paradigms, transliteration.
Grounds LLMs in real Old Norse: lemmas, mediopassive paradigms, English→Old Norse lookup.
Add one secure layer between your agents and this server.