hub
Server Details
One MCP endpoint over every Valksor dictionary: namespaced tools plus a JSON passthrough.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 27 of 27 tools scored.
Each tool is clearly disambiguated by its language prefix (e.g., anglo_, latgalian_, latin_) followed by a distinct operation (search, get_inflections, romanize, etc.). No two tools share the same name, and operation boundaries are well-defined.
All tools follow a consistent pattern: language prefix + underscore + operation verb or noun (e.g., anglo_search, latgalian_romanize). The only exception is 'dictionaries', which serves as a meta-tool for discovery, but it still follows the hub's naming logic.
With 27 tools, the count is high but appropriate for a multilingual dictionary hub covering 7-8 languages. Each language has 3-5 tools (search, get_inflections, romanize/deromanize), which is reasonable. The number could be seen as slightly heavy but well-justified by the scope.
The tool set covers the core operations for each language: searching, inflections, romanization/deromanization, and for some languages transliteration or lemmatization. It is read-only, but that matches the hub's purpose. Minor gaps include lack of etymology tools for most languages (except Scythian) and no update/delete operations, but these are not essential for a dictionary lookup service.
Available Tools
27 toolsanglo_deromanizeFind the Old English word(s) matching an ASCII spellingARead-onlyIdempotentInspect
Find the real Old English word(s) whose ASCII spelling matches this input — the
inverse of anglo_romanize. romanize is deeply lossy (th←þ or ð, dropped
macrons), so this is a LOOKUP against words already cached: attested spellings
come back as source=dictionary. If none match, a single best-effort reconstruction
(source=reconstruction, approximate=true) — a guess, not attested. Coverage grows
as words are cached.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ASCII-spelled Old English 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), a guess: Old English romanization is deeply lossy (th←þ or ð, dropped macrons/dots), so the dictionary hit is the reliable answer. |
Output Schema
| Name | Required | Description |
|---|---|---|
| candidates | Yes | |
| approximate | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: the lossy mapping (th←þ or ð, dropped macrons), lookup against cached words, two source types (dictionary vs reconstruction), and the approximate flag. Annotations already indicate read-only and idempotent, and no contradictions.
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?
The description is one paragraph that front-loads the purpose and then explains key details. It is appropriately sized for the complexity, though could be slightly more concise.
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 the tool's complexity (inverse mapping, lossy conversion, caching, two source types) and the presence of an output schema, the description covers the most important aspects. It does not detail output format, but the output schema likely covers that.
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 high (100% for the single parameter), and the description adds meaning by explaining that input is ASCII-spelled Old English text and detailing the two possible outcomes. This goes beyond the schema's basic description.
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 clearly states the tool's purpose: 'Find the real Old English word(s) whose ASCII spelling matches this input — the inverse of `anglo_romanize`.' It uses a specific verb and resource and distinguishes itself from its sibling 'anglo_romanize'.
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 explains when to use the tool (as the inverse of romanize) and provides context about the lossy nature and lookup behavior. It does not explicitly state when not to use or list alternatives, but the sibling list and context make it clear this is for deromanization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
anglo_get_inflectionsGet an Old English inflection tableARead-onlyIdempotentInspect
Fetch the full declension (nominals, including the pronouns' dual) 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 lemma) from a search result's inflection handle, e.g. 'cyning', 'bindan'. | |
| word_class | Yes | The part-of-speech section from a search result's inflection handle, e.g. 'verb', 'noun', 'adjective', 'pronoun'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe, read-only, idempotent operation. Description adds that it returns Markdown and structuredContent with a specific shape, instructs to check result.category before reading the body, and notes the source (en.wiktionary.org under CC BY-SA 4.0). No contradictions.
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?
The description is thorough and front-loaded with the primary purpose. It is slightly verbose but every sentence adds necessary information. Could be slightly trimmed without losing clarity.
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 100% schema coverage, an output schema, and clear usage guidelines, the description provides all necessary context. It explains both the purpose and the expected response structure, enabling correct invocation.
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?
Both parameters have schema descriptions with examples (entry_id: 'cyning', 'bindan'; word_class: 'verb', 'noun'). Description adds context that these come from a search result's inflection handle, making the origin and expected values clear.
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 clearly states the tool fetches inflection tables (declension/conjugation) for Old English lemmas, using entry_id and word_class from a search result. It distinguishes from the sibling 'anglo_search' by explaining that a default search already returns inline tables, so this tool is only needed when search ran without inline forms or left a match un-expanded.
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 ('only when a search ran without inline forms or left a match un-expanded') and when not to use ('a default search already returns each match's table inline'). Provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
anglo_romanizeRomanize Old English to clean ASCIIARead-onlyIdempotentInspect
Reduce Old English orthography to its primary ASCII spelling (þing→thing, wæter→waeter; macrons and the dotted ġ/ċ dropped) for an ASCII-keyboard downstream. Pure local transform: no dictionary lookup, no network, always ASCII.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Old English text to reduce to its primary ASCII spelling. Drops macrons and the dotted ġ/ċ, and folds the special letters (þ/ð→th, æ→ae, ƿ→w, œ→oe): þing→thing, wæter→waeter. For an ASCII-keyboard downstream. Pass a word, phrase, or several lines. |
Output Schema
| Name | Required | Description |
|---|---|---|
| text | Yes | The primary ASCII spelling. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: 'Pure local transform: no dictionary lookup, no network, always ASCII.' This reinforces the readOnly and idempotent hints, and adds detail about operation guarantees.
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?
Two sentences, front-loaded with the main action and examples. Every word contributes value; no redundancy.
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 the tool's simplicity (one parameter, no nested objects) and the presence of an output schema, the description is complete. It covers input, transformation, and guarantees, leaving no gaps.
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?
The input schema already provides a detailed description of the 'text' parameter (100% coverage). The description reiterates the parameter with examples, but doesn't add significant semantic value beyond what the schema provides.
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 clearly states the verb 'Reduce' and the resource 'Old English orthography' to ASCII, with specific examples and a contrast to dictionary lookup. It distinguishes from sibling tools like 'anglo_deromanize' by specifying direction.
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 provides clear context for use: when ASCII output from Old English is needed, and specifies it's a local transform with no network. It doesn't explicitly exclude alternatives, but the sibling list makes the differentiation obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
anglo_searchLook an Old English word upARead-onlyIdempotentInspect
Look an Old English 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 a modern English word instead: the result lists its per-sense Old English 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. Old English (default): a SINGLE Old English word, any form — an inflected form ('bindaþ') is resolved to its lemma ('bindan') automatically via cached paradigms, and the result says so; the special letters are optional once a paradigm is cached ('thing' finds þing, 'waeter' finds wæter). English (search_language='eng'): the English word whose Old English 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 (nouns, the adjectives' strong/weak family, the verbs' moods, the pronouns' dual) in ONE call, no follow-up anglo_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 Old English entries; the per-sense translations list itself is always returned. | |
| search_language | No | Language the query word is in: 'ang' (default) looks the Old English word up directly; 'eng' finds the Old English equivalents of a modern English word (per-sense, from Wiktionary's translation tables) and returns their full entries. Glosses are in modern English either way. | ang |
Output Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | False when nothing matched. For an eng query, True means Old English 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 ang): the Old English 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. ang 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. ang 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable context about caching, rate limiting, and attribution requirements. It also explains automatic lemma resolution via cached paradigms. No contradictions with annotations.
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?
The description is well-structured: it starts with the main functionality, then details parameter behaviors, and ends with caching and licensing notes. Every sentence adds value, though it is somewhat lengthy. It could be slightly more concise without losing clarity.
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 the tool has 4 parameters, full schema coverage, an output schema, and annotations, the description covers all essential aspects: input semantics, behavioral traits (caching, rate limits), and relationship to sibling tools. No gaps for agent decision-making.
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?
Although schema coverage is 100%, the description adds significant meaning beyond the schema: it explains how query handles inflected forms and special letters, how max_forms affects caching and speed, how include_forms controls output and relates to sibling tools, and how search_language toggles the lookup direction.
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 specifies the tool looks up Old English words on Wiktionary, returning senses and full declension/conjugation tables. It clearly distinguishes from sibling tools by focusing on Old English and mentioning the reverse English lookup feature. The verb 'Look' and resource 'Old English word' are specific.
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 explains when to use each search_language (ang for direct Old English lookup, eng for reverse English to Old English). It mentions that inflected forms resolve automatically and that include_forms=true avoids needing anglo_get_inflections. However, it does not explicitly state when not to use the tool or provide alternative tools for other languages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dictionariesARead-onlyIdempotentInspect
Index of every Valksor dictionary reachable through this hub and its CURRENT tool and prompt names (each named _). Call this to discover or re-check names — e.g. after an 'unknown tool'/'unknown prompt' error. The optional language argument narrows the result to one dictionary by its id (the prefix before the first underscore). Each entry's host is that dictionary's public site, for reference only — you still reach its tools through this hub by their listed names, not via that host.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Restrict the index to one dictionary by its id. |
Output Schema
| Name | Required | Description |
|---|---|---|
| dictionaries | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds that host URLs are for reference only and explains naming convention, providing useful 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?
Description is front-loaded with purpose and well-structured, but slightly verbose. Every sentence adds value.
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 the complexity (meta-tool with output schema and robust annotations), description is complete enough for an agent to understand when and how to use it.
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 100% schema coverage, baseline is 3. Description adds meaning by explaining language parameter as dictionary id (prefix before underscore), giving practical usage insight.
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 clearly states the tool is an index of dictionaries and their tool/prompt names, distinguishing it from sibling tools which are the actual dictionary operations.
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 advises calling it to discover or re-check names after errors, with optional language narrowing. No explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
interslavic_get_inflectionsGet an Interslavic inflection tableARead-onlyIdempotentInspect
Fetch the full declension (noun/adjective) or conjugation (verb) table for a word 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": } — switch on result.category ('noun' | 'adjective' | 'verb' | 'not_found') before reading the body. Tables are generated by the official Interslavic morphology engine, not attested.
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes | The dictionary word id from a search result's inflection handle (a number, e.g. '33555') — NOT the headword itself (Interslavic homographs share a spelling). | |
| word_class | Yes | The paradigm class from a search result's inflection handle: 'noun', 'adjective' or 'verb'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds critical context: the output includes both Markdown and structuredContent with a specific shape, instructs to check result.category before parsing, and warns that tables are generated by the official engine (not attested). This goes beyond annotations.
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?
The description is concise at ~100 words, structured in three clear sentences: purpose, usage guidelines, and output format. Front-loaded with the main action, no 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?
Given the tool's complexity (inflection table retrieval for a constructed language), the description fully covers input, when to use, output structure including the category field, and a caveat about generated tables. The presence of an output schema and rich annotations makes it complete.
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?
Input schema has 100% coverage with detailed parameter descriptions (entry_id as dictionary word id, word_class as paradigm class). The description reinforces the connection between parameters (entry_id + word_class) but does not add new details beyond the schema. Still, the schema is already rich.
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 clearly states the tool fetches inflection tables (declension or conjugation) for a word identified by entry_id and word_class. It specifies verb+resource (fetch table) and distinguishes from default search which already returns tables inline, making the scope unambiguous.
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 the tool: only when a search ran without inline forms or left a match un-expanded, noting that a default search already returns tables inline. This clear guidance differentiates from the primary search tool and prevents redundant calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
interslavic_searchLook an Interslavic word upARead-onlyIdempotentInspect
Look an Interslavic word up in the bundled community dictionary and return its translation matrix (English + 11 Slavic languages) plus its full, algorithmically-generated declension/conjugation table. Any form and either script works; an inflected query resolves to its headword and the result notes it. With search_language='eng' the query is an English word: the result lists its Interslavic equivalents plus their expanded entries. Returns Markdown plus the same result as structuredContent matching the declared outputSchema.
Fully offline (bundled snapshot); calls are rate limited per client IP. Content: the Interslavic dictionary (van Steenbergen et al.); reuse licence unconfirmed — attribute the source.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The word to look up, in the language search_language names. Interslavic (default): a SINGLE Interslavic word, any form and either script — an inflected form ('brata') resolves to its headword ('brat') via the reverse form index, Latin and Cyrillic both work for headwords, and diacritics are optional ('delati' finds 'dělati'). English (search_language='eng'): the English word whose Interslavic equivalents you want. | |
| max_forms | No | Optional override for how many inflection tables to expand this call (0–12). Tables are served from the bundled dataset (no network), so this is cheap. 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 interslavic_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. Pronouns, numerals and indeclinables carry no table. For eng queries this governs the expanded Interslavic entries. | |
| search_language | No | Language the query is in: 'isv' (default) looks the Interslavic word up directly; 'eng' finds the Interslavic equivalents of an English word (via the gloss index) and returns their full entries. These are the only two queryable languages in v1 — each entry ALSO carries a read-only translation matrix into 11 more languages (Russian, Polish, Czech, Ukrainian, …), but you cannot query IN those. | isv |
Output Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | False when nothing matched. For an eng query, True means the gloss index named Interslavic words — entries may still be empty when none of them expanded (see translations). |
| query | Yes | |
| source | No | |
| entries | No | |
| handles | No | |
| language | Yes | |
| translations | No | Populated only for eng queries (always [] for isv): the Interslavic words whose English gloss matched the query. Entries/handles below are the expanded entries of those words. |
| resolved_from | No | The original query when resolved via the index; else empty. isv queries only — always empty for eng results. |
| search_method | No | How the match was found: 'direct' = the query matched a headword; 'lemma_index' = an inflected/alternate spelling resolved via the reverse form index; 'translations' = an English query resolved via the gloss index. |
| resolved_lemma | No | The headword actually searched when resolved; else empty. isv 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 matched words were NOT expanded into entries because the per-search expansion cap was reached (they still appear under translations). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description discloses that the tool is fully offline, rate-limited, and includes licensing details. It also notes the return format (Markdown + structuredContent).
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?
The description is well-structured and efficiently conveys purpose and key details without unnecessary verbosity. Slightly longer than minimal but all sentences add value.
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 the tool's complexity (4 params, 2 modes, output schema), the description covers all essential aspects: query behavior, inflection handling, offline nature, rate limits, and licensing. The presence of an output schema reduces the need to describe return values.
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?
All parameters have thorough schema descriptions, so the description adds limited new semantics. It reiterates search modes and inflection behavior, but provides no critical additional meaning beyond 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?
The description clearly states the tool's purpose: looking up an Interslavic word and returning its translation matrix and declension/conjugation table. It distinguishes from siblings like interslavic_get_inflections by combining both tasks and also supports English query mode.
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 explains when to use the tool for Interslavic vs English queries, and how to control inflection output via include_forms. However, it does not explicitly compare to siblings like interslavic_get_inflections for cases where only inflections are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
interslavic_transliterateTransliterate one Interslavic word between Latin and CyrillicARead-onlyIdempotentInspect
Transliterate ONE Interslavic word between Latin and Cyrillic. This is
bidirectional: it auto-detects the input's script and returns the attested spelling
in the OTHER script — Latin input yields Cyrillic, Cyrillic input yields Latin (or
pass target to force it). Unlike the lossy deromanize tools, this is an EXACT
dataset lookup (both spellings are stored per entry): it never guesses — a word not
in the dataset returns empty candidates.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ONE Interslavic word (not a phrase — the lookup does not tokenize). Auto-detects the script and returns the attested spelling in the OTHER script (Latin↔Cyrillic). A word absent from the dataset, or input with no clear script, returns empty candidates — this is an exact lookup and never guesses. | |
| target | No | Force the output script (cyrillic|latin); omit to auto-detect. |
Output Schema
| Name | Required | Description |
|---|---|---|
| direction | Yes | |
| candidates | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description reveals bidirectional auto-detection, exact lookup behavior, and that absent words return empty candidates. This adds significant behavioral context not captured in 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?
The description is concise, front-loaded with the main purpose, and every sentence adds value—no fluff. It efficiently covers purpose, usage, and behavior in two paragraphs.
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 the tool's simplicity (2 params, no nested objects, output schema present), the description is complete. It covers the exact lookup nature, script handling, and differentiation from sibling tools. The presence of an output schema reduces the need to describe return values.
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 100% schema description coverage, the baseline is 3. The description adds context like 'not a phrase—the lookup does not tokenize' and clarifies the behavior of empty candidate returns, providing nuance beyond 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?
The description clearly states the tool transliterates one Interslavic word between Latin and Cyrillic. It specifies the exact verb-resource relationship and distinguishes from sibling tools like interslavic_search by focusing on transliteration alone.
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 explicitly contrasts with 'lossy deromanize tools' and notes this is an exact dataset lookup that never guesses, guiding when to use this tool over alternatives. It also clarifies input should be a single word, not a phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
latgalian_deromanizeFind the Latgalian word(s) matching a romanized spellingARead-onlyIdempotentInspect
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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| candidates | Yes | |
| approximate | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide safety (readOnlyHint, idempotentHint), but description adds detailed behavioral context: lossy romanization, cache-based lookup, source field semantics (dictionary vs. reconstruction with approximate flag), and specific ambiguity details (case, o/ō, cedilla, macron, glide).
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?
Single paragraph of 4 sentences, front-loaded with purpose, then explains behavior efficiently. No redundant words.
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?
Covers all essential aspects: inverse direction, lossy mapping, cache-based lookup, two output types, reconstruction as guess, time-dependent coverage. With output schema expected, return values are likely documented elsewhere.
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 covers 'text' param 100%, but description adds meaning beyond schema: explains what romanized clean-ASCII means, mentions lossy nature and resolution process. Not solely dependent on 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?
Clearly states it finds Latgalian words matching a romanized spelling, explicitly names it as inverse of latgalian_romanize, and distinguishes two output modes (dictionary lookup vs. reconstruction).
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 when to use (given romanized input) and contrasts with latgalian_romanize; mentions caching behavior that affects results over time. Not explicit about when not to use, but inverse relation is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
latgalian_get_inflectionsGet a Latgalian inflection tableARead-onlyIdempotentInspect
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'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds value by disclosing the content source (en.wiktionary.org, CC BY-SA 4.0), explaining the output shape (Markdown plus structuredContent with category), and describing how to handle different result types. No contradictions with annotations.
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?
The description is three sentences, each serving a distinct purpose: purpose, usage guidelines, and output handling. It is front-loaded with the core action and efficiently conveys all necessary information without redundancy.
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 the tool's complexity (inflection tables, multiple categories), the description covers: what it does, when to use it, output format (Markdown + structuredContent), and how to interpret result.category. The presence of an output schema reduces the need to describe return values further.
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 has 100% coverage with clear descriptions for both parameters. The description reinforces these by providing examples (e.g., 'akmiņs', 'byut') and context about 'lemma' and 'search result's inflection handle'. This adds practical clarity beyond the schema alone.
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 clearly states it fetches full declension or conjugation tables for a lemma identified by a search result's inflection handle (entry_id + word_class). It differentiates from sibling tools like latgalian_search and latgalian_romanize by specifying the exact use case and context.
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 explicitly says '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.' It also advises to switch on result.category before reading the body, providing clear when-to-use and how-to-interpret guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
latgalian_romanizeRomanize Latgalian to clean ASCIIARead-onlyIdempotentInspect
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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| text | Yes | The romanized ASCII output. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint and readOnlyHint. The description adds valuable behavioral details: the transform is local, does not require network or dictionary, and always outputs ASCII. It also explains the return format (Markdown + structuredContent matching the outputSchema), which is beyond what annotations 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?
The description is three sentences long, front-loads the core purpose, and each sentence provides essential information (purpose, note to parameter doc, behavioral properties, and output format). No redundancy or 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?
Given the simple single-parameter tool, full schema coverage, output schema presence, and annotations, the description covers the usage context, behavior, and return format completely. It omits no critical information for an agent to select and invoke this tool 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 description already details the exact letter mappings. The description does not add new parameter-level semantics beyond referencing the parameter doc. Hence 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?
The description starts with a specific verb-resource combination ('Strip Latgalian orthography down to clean, pronounceable ASCII') and clarifies the intended downstream use (voive/TTS, search). This clearly differentiates it from siblings like livonian_romanize by focusing on the Latgalian language.
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 explicitly states the tool's use case ('for an English-trained downstream') and its characteristics ('Pure local transform: no dictionary lookup, no network'). It does not explicitly mention when not to use or list alternatives, but the sibling set and tool name implicitly guide the agent away from other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
latgalian_searchLook a Latgalian word upARead-onlyIdempotentInspect
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 |
Output Schema
| 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations (readOnlyHint, idempotentHint, destructiveHint). It details caching, rate limiting, lemma resolution, return format (Markdown + structuredContent), and attribution requirements. No contradictions with annotations.
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?
The description is well-organized with clear sections for the main functionality, caching, and rate limits. It front-loads the purpose and is not overly verbose, though a few sentences are longer than necessary.
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 the tool's complexity (multiple parameters, output schema, caching, rate limits, attribution), the description covers all essential aspects. It mentions the output schema exists, explains error handling, and provides legal context. No major gaps.
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. The description adds value by explaining the behavior of max_forms in cold queries and the 'eng' mode's expanded entries, which are not fully captured in the parameter descriptions. This helps the agent choose appropriate parameter values.
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 clearly states the tool looks up a Latgalian word on Wiktionary and returns senses and full declension/conjugation tables. It also explains the 'eng' search mode for English-to-Latgalian lookup. It distinguishes from sibling tools like latgalian_get_inflections by noting that this tool can include inflection tables inline via the include_forms parameter.
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 provides clear guidance on using both search languages and the optional parameters. It mentions that inflected queries resolve automatically and that rate-limit errors require waiting. However, it could be more explicit about when to use the separate latgalian_get_inflections tool instead of including forms here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
latin_get_inflectionsGet a Latin inflection tableARead-onlyIdempotentInspect
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 lemma) from a search result's inflection handle, e.g. 'amo', 'aqua'. | |
| word_class | Yes | The part-of-speech section from a search result's inflection handle, e.g. 'verb', 'noun', 'adjective'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds beyond this by explaining the output format (Markdown plus structuredContent with shape {'result': <paradigm>}) and how to parse it (switch on result.category). It also discloses the data source (en.wiktionary.org, CC BY-SA 4.0), which aligns with openWorldHint.
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?
The description is concise and well-structured: purpose, usage condition, output format, and attribution. Every sentence adds value without redundancy. It is front-loaded with the primary action and specific usage context.
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 the presence of an output schema (declared), the description adequately covers the input parameters, the conditions for usage, and how to handle the output (check result.category). The data source is mentioned, rounding out the context for a tool with only 2 parameters and an output schema.
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% with descriptions. The description adds contextual meaning by explaining that entry_id is 'a search result's inflection handle' with examples (e.g., 'amo', 'aqua'), and word_class is 'the part-of-speech section from a search result's inflection handle' with examples (e.g., 'verb', 'noun'). This enriches the schema descriptions.
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 clearly states the tool fetches a full declension or conjugation table for a lemma identified by entry_id and word_class. It distinguishes from a default search that already returns tables inline, and it's specific to Latin inflections, differentiating from sibling tools like latgalian_get_inflections or norse_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?
Explicit guidance on when to use: 'Use this only when a search ran without inline forms or left a match un-expanded'. Also instructs to switch on result.category before reading the body, providing clear direction on how to process the output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
latin_lemmatizeMorphologically analyze a Latin formARead-onlyIdempotentInspect
Analyze one inflected Latin form with the Morpheus morphological analyzer: its lemma(s) plus the grammatical reading (person, number, tense, mood, voice, case…). Useful when you want the morphology itself — for the dictionary entry, latin_search already resolves inflected queries on its own. Returns Markdown plus the analysis as structuredContent matching the declared outputSchema. Results are cached server-side. Analyses via the Perseids Morpheus service.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | One inflected Latin word form to analyze, e.g. 'amavit', 'aquam'. Macrons optional. |
Output Schema
| Name | Required | Description |
|---|---|---|
| word | Yes | |
| found | Yes | |
| source | No | |
| analyses | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful context: results are cached server-side, uses Perseids Morpheus service, returns Markdown and structuredContent matching outputSchema. No contradictions.
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?
Three sentences with no wasted words. The first sentence defines purpose, the second provides usage guidance, and the third mentions caching and service. Information is front-loaded and efficient.
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 one parameter, full schema coverage, and an existing output schema (mentioned but not shown), the description adequately covers the tool's purpose, usage, and return format. Complements annotations well.
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?
The single parameter 'word' has a description in the schema. The description adds examples ('e.g. 'amavit', 'aquam'') and notes that macrons are optional, providing additional meaning beyond 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?
The description clearly states it analyzes one inflected Latin form with the Morpheus morphological analyzer, providing lemma and grammatical reading. It distinguishes from the sibling tool 'latin_search' which resolves inflected queries for dictionary entry. The verb 'analyze' and resource 'one inflected Latin form' are specific.
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: 'when you want the morphology itself' and contrasts with 'latin_search' for dictionary entry. Mentions caching and server-side service. Provides clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
latin_searchLook a Latin word upARead-onlyIdempotentInspect
Look a Latin 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 or the Morpheus analyzer) and the result notes the resolution. With search_language='eng' the query is an English word instead: the result lists its per-sense Latin 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. Latin (default): a SINGLE word, any form — an inflected form ('amavit') is resolved to its lemma ('amo') automatically, and the result names it (search_method tells you how; resolved_lemma is the lemma to follow for the full paradigm); macrons are optional ('amo' and 'amō' both work). English (search_language='eng'): the English word whose Latin equivalents you want — multiword entries like 'give up' 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 latin_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 Latin entries; the per-sense translations list itself is always returned. | |
| search_language | No | Language the query word is in: 'lat' (default) looks the Latin word up directly; 'eng' finds the Latin equivalents of an English word (per-sense, from Wiktionary's translation tables) and returns their full entries. Glosses are in English either way. | lat |
Output Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | False when nothing matched. For an eng query, True means Latin 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 lat): the Latin terms each English sense translates to, in sense order. Entries/handles below are the expanded dictionary entries of those terms. |
| resolved_from | No | The query whose lemma this result names (paired with resolved_lemma); else empty. lat queries only (always empty for eng). Set both when an inflected miss was re-searched (search_method lemma_index/morpheus) and when the query's own page is a form-of stub returned directly (search_method stays 'direct'). |
| search_method | No | How the match was found: 'direct' = the query itself matched; 'lemma_index' = an inflected form resolved via a previously cached paradigm; 'morpheus' = resolved via the Morpheus morphological analyzer; 'translations' = an English query resolved via Wiktionary translation tables. |
| resolved_lemma | No | The lemma this query maps to; else empty. lat queries only. With search_method 'lemma_index'/'morpheus' the entries below ARE this lemma's; with 'direct' the entries are the queried form-of stub and this names the lemma whose page holds the full paradigm (search it / latin_get_inflections it). Only set when unambiguous — a form mapping to several lemmas leaves it empty (use lemmatize); the per-sense form_of still carries each. |
| 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: automatic lemmatization via Morpheus, caching, politeness and rate-limiting, and the CC BY-SA 4.0 license. Annotations already indicate readOnly, idempotent, and non-destructive, and the description enhances transparency without contradiction.
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?
The description is structured into clear paragraphs and is front-loaded with the main purpose. While it is somewhat long, every sentence contributes necessary detail. It is well-organized but could be slightly more concise.
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 the tool's complexity (dual language modes, caching, rate-limiting, output schema), the description covers all pertinent aspects: automatic lemmatization, result format (Markdown + structuredContent), caching behavior, rate-limit handling, and attribution requirements. It is complete for effective agent usage.
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%, providing a baseline of 3. The description adds value by explaining that the query can be any inflected form and that resolution is noted in results, and it clarifies the behavior of max_forms and include_forms. This goes beyond the schema's documentation.
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 clearly states the tool's purpose: looking up a Latin word on Wiktionary and returning senses and full declension/conjugation tables. It explicitly distinguishes two modes (Latin query and English query) and mentions attested content. It differentiates from sibling tools like latin_get_inflections and latin_lemmatize by noting that include_forms=true removes the need for follow-up calls.
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 provides explicit guidance on when to use the tool: for any Latin word form (with automatic lemmatization) or for English words via search_language='eng'. It explains that results are cached and that rate-limit errors should be handled by waiting and retrying. It also mentions that setting include_forms=true avoids needing the sibling latin_get_inflections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
livonian_deromanizeFind the Livonian word(s) matching a romanized spellingARead-onlyIdempotentInspect
Find the real Livonian word(s) whose pronunciation-romanization matches this
clean-ASCII input — the inverse direction of livonian_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) Livonian 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, stød, palatalization and macron length cannot be recovered. |
Output Schema
| Name | Required | Description |
|---|---|---|
| candidates | Yes | |
| approximate | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations by explaining lossy romanization, cache-dependent results, two return types (dictionary exact vs reconstruction guess), and that repeated queries may change outcomes. Annotations already indicate read-only and idempotent, and the description adds crucial nuance.
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?
The description is a single paragraph that front-loads purpose and is well-structured, but is somewhat verbose with four sentences. Each sentence adds value, so it earns a high score but could be tightened.
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 the output schema exists, the description fully covers tool behavior including caching, lossiness, and return types. No critical information is missing for correct usage.
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 already describes the parameter in detail. The tool description reinforces but does not add significant new semantic information beyond 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?
The description clearly states the tool finds real Livonian word(s) matching a romanized spelling, explicitly naming it as the inverse of livonian_romanize and distinguishing from sibling 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?
Provides clear context for when to use (romanized input to get orthography) and explains the lookup vs reconstruction behavior. Could explicitly mention when to use search instead, but the inverse relationship with romanize is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
livonian_get_inflectionsGet Livonian inflection tableARead-onlyIdempotentInspect
Fetch the full declension (nouns) or conjugation (verbs) table for a word identified by a search result's inflection handle (entry_id + word_class) — the exact case, number, tense, not a guessed ending. Use this only when a search ran without inline forms, or to fetch a match a broad search left un-expanded. Never a first call — the handle values only come from livonian_search results, and a default search already returns each match's table inline, so calling this afterwards just re-fetches what you have.
Returns Markdown — a nominal gets one case × {singular, plural} table; a verb gets a table per mood/tense (person × {affirmative, negative}, the negation auxiliary folded into the negative) plus its principal-parts and participle lists — or a clean not-found message. (Grammatical labels are normalised to English; Livonian forms stay verbatim.) The same table rides along as structuredContent with the shape {"result": } per the declared outputSchema — switch on result.category ('nominal' | 'verbal' | 'not_found') before reading the body. Results are cached server-side (repeats are instant) and calls are rate limited — on a rate-limit error, wait a few seconds and retry. Table content is from livonian.tech (CC BY-SA 4.0 — attribute if republished).
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes | The word id from a search result's inflection handle. Accepts a number or a digit-string (e.g. 17746 or "17746"). | |
| word_class | Yes | The word-class code from a search result's inflection handle (e.g. 's' = noun, 'adj' = adjective, 'vi' = intransitive verb, 'vt' = transitive verb). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) indicate safe reading; description adds details about caching, rate limits, output format (Markdown with structuredContent), not-found messages, and attribution requirements, all beyond annotations.
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?
Description is front-loaded with critical usage guidance and well-structured. While somewhat long, each sentence adds value and no redundancy is present. Could be slightly trimmed but remains effective.
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?
All aspects covered: purpose, usage constraints, output format, error handling, caching, rate limits, and attribution. Output schema is present and referenced, so no gaps remain.
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?
Both parameters are described in detail, with examples and context linking them to search results. Schema coverage is 100%, so baseline is 3; the added examples and usage context raise it to 4.
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 clearly states it fetches inflection tables for Livonian words using a search result's handle, and distinguishes from sibling tools by specifying it is not a first call and only used when inline forms are missing.
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 (when search ran without inline forms or to expand a broad search) and when not to use (never as first call, as handle comes from search and default search returns inline tables). Provides clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
livonian_romanizeRomanize Livonian to clean ASCIIARead-onlyIdempotentInspect
Strip Livonian 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 | Livonian text to reduce to clean, pronounceable ASCII. Strips macrons, diacritics and capitals (ā→aa, š→sh, õ→u), softens a palatalized consonant (ņ ļ ŗ ţ ḑ) only before a vowel (ņ+a→nya, else ikšiggiņ→ikshiggin), and hyphenates the broken tone (si'zzõl→siz-zul) and long-vowel diphthong glides (kīen→kee-en). Pass a word, phrase, or several lines. |
Output Schema
| Name | Required | Description |
|---|---|---|
| text | Yes | The romanized ASCII output. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds key behavioral traits: pure local transform, no network, always ASCII output, and detailed transformation rules in the parameter doc.
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?
Two front-loaded sentences with no wasted words, effectively communicating purpose, behavior, and output format.
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 high schema coverage and output schema, the description is fully complete, noting the return format (Markdown + structuredContent) and the pure transform nature.
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% with a rich parameter description; the tool description summarizes transformations effectively, adding context without redundancy.
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 clearly states it strips Livonian orthography to clean ASCII for downstream use, specifying the verb 'Romanize' and explicitly distinguishing from sibling tools like 'latgalian_romanize' and 'slavonic_transliterate'.
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 provides usage context (for English-trained TTS/search) and what the tool does not do (no dictionary, no network), but does not explicitly mention when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
livonian_searchSearch the Livonian dictionaryARead-onlyIdempotentInspect
Look a word up in the real Livonian–Estonian–Latvian dictionary and return only attested content, so translations are grounded, not invented.
Search a meaning (in English/Latvian/Estonian) to find the Livonian headword, or a
Livonian word to confirm it exists and read its sense, part of speech and examples.
See the query and search_language parameter docs for how to phrase a query. By
default each match's full inflection table is returned inline, so one call usually
suffices; on a broad query only the first N tables expand (the rest are listed as
handles to fetch with livonian_get_inflections). Returns Markdown plus the same result as
structuredContent matching the declared outputSchema.
Results are cached server-side, so repeating a query is instant and free; a first-time query reaches the live dictionary and calls are rate limited — on a rate-limit error, wait a few seconds and retry instead of re-issuing immediately. Dictionary content is from livonian.tech (CC BY-SA 4.0 — attribute if republished).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A SINGLE content word, not a phrase. Exactly one word per call — even with several candidates or synonyms in mind, search them one at a time ('see', then 'look'), never combined into one query like 'see look'. Drop function words and infinitive markers — search 'to water' as 'water', 'the sea' as 'sea'. The dictionary matches one attested headword, so a multi-word query often returns nothing even when the word exists; search the main word first, then refine. May be Livonian, Latvian, Estonian, or English (e.g. 'jarā', 'away', 'sea'). Matching is bidirectional. An inflected Livonian form (search_language='liv') is resolved to its dictionary lemma automatically when the form is known — the result says so when that happened. | |
| max_forms | No | Optional override for how many inflection tables to expand this call (0–12). Raise it to pull more tables in ONE call on a broad query, or set a small value to keep a broad query cheap. On an uncached query each table is fetched sequentially with polite pacing toward the upstream, so a high value on a cold broad query is slow — the bound limits upstream fan-out, not just response size. Omit to use the server's default cap. | |
| include_forms | No | When true (default), each match's full inflection table is returned INLINE — usable cases/tenses in ONE call, no follow-up livonian_get_inflections. Set false to get just the headword handles + glosses: a cheap way to SCREEN several candidate words or synonyms (which exist? which sense?) before spending forms on the one you pick. Bounded by a per-search cap — use max_forms to raise or lower it for this call. | |
| search_language | No | Language your query word is in — selects which language the search matches against: 'eng' (default), 'liv', 'lat', or 'est'. For English→Livonian translation, keep 'eng'. Glosses are in English. | eng |
Output Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | False when nothing matched. |
| query | Yes | |
| source | No | |
| entries | No | Structured dictionary entries: headword, pronunciation, part of speech, paradigm anchors, and senses with example sentences. |
| handles | No | |
| language | Yes | |
| resolved_from | No | The original inflected query when search_method='lemma_index'; empty on a direct match. |
| search_method | No | How the match was found: 'direct' = the query itself matched; 'lemma_index' = the query was an inflected Livonian form, resolved to its dictionary lemma via the cached paradigm index and re-searched. |
| resolved_lemma | No | The dictionary lemma actually searched when search_method='lemma_index'; empty on a direct match. |
| forms_truncated | No | How many handles did NOT get an inline table because the per-search cap was reached. Refine the query or call livonian_get_inflections. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, etc.), the description adds caching behavior, rate limiting details, content licensing (CC BY-SA 4.0), return format (Markdown + structuredContent), and automatic resolution of inflected forms. No contradictions with annotations.
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?
The description is well-structured with front-loaded purpose and detailed parameter guidance. However, it is somewhat verbose; some sentences (e.g., on caching and licensing) could be condensed. Still, every sentence earns its place.
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 the tool's complexity (4 params, output schema exists), the description covers all necessary aspects: usage, caching, rate limits, licensing, relationship to sibling tool, and examples. It is complete for an AI agent to correctly select and invoke the 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?
All 4 parameters are described in the schema (100% coverage). The description adds significant value beyond schema: explains how to phrase queries (single word, no function words), specifies search_language codes with examples, and provides practical guidance for max_forms and include_forms (e.g., when to raise/lower, trade-offs).
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 clearly states the tool is for looking up words in a Livonian dictionary with attested content. It distinguishes from sibling tools like livonian_get_inflections by specifying that this tool returns headword matches with inflection tables inline, while the sibling handles separate inflection fetches.
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 provides explicit when-to-use (searching meanings in various languages, confirming existence, reading sense/POS/examples) and when-not-to-use (not phrases, one word per call, drop function words). It also mentions alternatives like livonian_get_inflections for broad queries and gives rate limit advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
norse_get_inflectionsGet an Old Norse inflection tableARead-onlyIdempotentInspect
Fetch the full declension (nominals) or conjugation (verbs — active AND mediopassive) 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. 'maðr', 'kasta'. | |
| word_class | Yes | The part-of-speech section from a search result's inflection handle, e.g. 'verb', 'noun', 'adjective'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, etc.), description adds return format (Markdown + structuredContent with category switching) and licensing from Wiktionary. No contradictions with annotations.
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?
Three concise sentences: first defines operation, second gives usage guidance, third details output and processing. Each sentence earns its place; no redundancy.
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?
Handles complexity of inflection tables with declension/conjugation, usage scenario, structured output shape, and source attribution. Output schema exists, so return details are sufficient. Complete for an agent.
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 covers both parameters with descriptions; description enhances by explaining they come from an inflection handle and provides examples ('maðr', 'kasta', 'verb', 'noun'), adding practical context.
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?
Clearly states it fetches full declension/conjugation tables for Old Norse lemmas, specifies parameters (entry_id and word_class) from a search result's inflection handle, and distinguishes from default search which returns tables inline.
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 tells when to use (when search ran without inline forms or match un-expanded) and when not to (default search already returns tables). Also implies prerequisite of having a search result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
norse_searchLook an Old Norse word upARead-onlyIdempotentInspect
Look an Old Norse word up on Wiktionary and return its senses plus full declension/conjugation tables — attested content (including the verbs' mediopassive voice), 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 Norse 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. Old Norse (default): a SINGLE Old Norse word, any form — an inflected form ('mǫnnum') is resolved to its lemma ('maðr') automatically via cached paradigms, and the result says so; diacritics are optional once a paradigm is cached ('madr' and 'mathr' both find maðr, 'monnum' finds mǫnnum). English (search_language='eng'): the English word whose Old Norse 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 (and the verbs' mediopassive voice) in ONE call, no follow-up norse_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 Old Norse entries; the per-sense translations list itself is always returned. | |
| search_language | No | Language the query word is in: 'non' (default) looks the Old Norse word up directly; 'eng' finds the Old Norse equivalents of an English word (per-sense, from Wiktionary's translation tables) and returns their full entries. Glosses are in English either way. | non |
Output Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | False when nothing matched. For an eng query, True means Old Norse 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 non): the Old Norse 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. non 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. non 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, etc.), the description discloses caching, rate limiting, politeness to upstream, licensing (CC BY-SA 4.0), and that results include both Markdown and structuredContent matching the output schema. This exceeds the basic safety profile provided by annotations.
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?
The description is front-loaded with the core purpose, then logically covers modes, behavior, caching, and licensing. Every sentence is informative with no redundancy, achieving high information density.
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 the tool's complexity (4 parameters, output schema, sibling tools), the description covers purpose, usage scenarios, caching, rate limits, licensing, and return format. No gaps remain for an agent to infer.
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?
All 4 parameters have detailed schema descriptions (100% coverage), so baseline 3. The tool description adds value by explaining the resolution of inflected queries to lemmas and the caching behavior, which ties the parameters together meaningfully.
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 clearly states the tool looks up an Old Norse word on Wiktionary and returns senses plus full declension/conjugation tables. It also explains the English reverse lookup mode. It distinguishes itself from the sibling norse_get_inflections by noting that full tables are returned inline, so no follow-up needed.
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 provides explicit guidance on when to use each search language ('non' vs 'eng'), how to handle inflected queries, and when to set include_forms false for a quick screen. It also mentions rate-limit retry advice, giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scythian_get_descendantsGet a Proto-Scythian entry's descendantsARead-onlyIdempotentInspect
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'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return format (Markdown + structuredContent with 'result' payload and category) and content attribution. This adds value beyond annotations, which already indicate read-only, idempotent, non-destructive behavior.
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 with no redundancy: purpose, usage context, return handling, and attribution. Front-loaded and every sentence earns its place.
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?
Fully covers purpose, when-to-use, return shape, and content origin. With output schema present and rich annotations, no gaps remain for this 2-parameter 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% and each parameter description adds meaningful context (e.g., example values, tolerance for asterisk, source handle). Description enhances understanding beyond 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?
The description clearly states it fetches the full descendants payload (etymology, glosses, reflex tree) for a lemma identified by a descendant handle. Specific verbs and resource details distinguish it from sibling tools like scythian_search.
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 says to use only when a search ran without inline payloads or left a match un-expanded, and that a default search already returns payloads inline. Also instructs to check result.category before reading body.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scythian_searchLook a Proto-Scythian word upARead-onlyIdempotentInspect
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 |
Output Schema
| 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses caching behavior, rate limiting, ASCII folding of spellings, and attribution requirements. It explains that results are cached server-side and that first-time queries are polite. No contradictions with annotations.
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?
The description is front-loaded with core functionality and well-structured, covering modes, then behavioral notes. It is slightly lengthy but each sentence adds value, so it's appropriately concise without being overly verbose.
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 the tool's complexity (two modes, caching, output schema), the description covers all necessary aspects: what it does, how parameters affect behavior, performance considerations, and legal attribution. It leaves no significant gaps for the agent to infer.
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. The description adds value by explaining how parameters interact (e.g., include_forms and max_forms) and providing context for the search_language parameter. However, the schema descriptions are already detailed, so marginal gain is moderate.
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 clearly states the tool looks up a Proto-Scythian word on Wiktionary, returning senses and descendants payload. It distinguishes between direct lemma lookup and English reverse search, and differentiates from sibling scythian_get_descendants by noting that descendants are returned inline when include_forms is true.
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 provides explicit guidance on when to use each search mode (query language parameter) and when to set include_forms to true vs false to avoid separate sibling calls. It also explains the behavior of max_forms for controlling the number of expanded descendants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
slavonic_detransliterateFind the Church Slavonic word(s) matching a Latin transliterationARead-onlyIdempotentInspect
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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| candidates | Yes | |
| approximate | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond annotations: transliteration is lossy, results can be dictionary hits or reconstructions, reconstructions are approximate with specific limitations (no Glagolitic, no liturgical marks), and coverage grows over time. Annotations only indicate readOnly, idempotent, non-destructive, and open world.
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?
The description is concise yet comprehensive, using a few well-structured sentences. It front-loads the main purpose, then adds necessary nuance. No redundant or extraneous text.
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 the tool's complexity (two modes, lossy mapping, coverage-dependent results), the description covers all essential aspects. An output schema exists, so return values are documented elsewhere. The description provides sufficient context for correct use.
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% for the single required parameter `text`. The description adds valuable context about the nature of the input (scientific-Latin transliteration) and what happens to it (resolved to orthography, possible multiple matches). This goes beyond the schema's basic length constraints.
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 title and description clearly state the tool's purpose: finding real Church Slavonic words from a Latin transliteration, explicitly noting it is the inverse of `slavonic_transliterate`. This distinguishes it from sibling tools with similar names.
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 explains that the tool performs a lookup against a dictionary cache with a fallback reconstruction. It implies when to use (when needing detransliteration) and hints at limitations (lossy, coverage-dependent). However, it does not explicitly state when not to use it or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
slavonic_get_inflectionsGet a Church Slavonic inflection tableARead-onlyIdempotentInspect
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'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the response format (Markdown plus structuredContent with a specific shape) and instructs how to interpret the result.category. It also mentions the external source and license, adding context beyond the annotations (which already declare readOnly, openWorld, idempotent, non-destructive).
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?
The description is concise, front-loaded with the primary action, and every sentence adds necessary information without redundancy. It efficiently covers purpose, usage, output, and licensing in a few sentences.
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 the tool's complexity (2 parameters, output schema provided), the description is complete: it explains when to use, what it does, what it returns, and how to process the output. The presence of an output schema reduces the need for return value details.
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?
The schema already covers the parameters with 100% description coverage. The description adds context by explaining that the parameters form an 'inflection handle' and are obtained from a search result, which helps agents understand the relationship between parameters and the tool's usage scenario.
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 clearly states that the tool fetches inflection tables (declension or conjugation) for a lemma, using an inflection handle. It specifies both the resource and action, and distinguishes it from sibling tools by language and context.
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 explicitly states when to use this tool: 'only when a search ran without inline forms or left a match un-expanded'. It contrasts with a default search that returns tables inline, providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
slavonic_searchLook a Church Slavonic word upARead-onlyIdempotentInspect
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 |
Output Schema
| 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds explicit behavioral details: caching, rate limiting (with retry guidance), content source (en.wiktionary.org) and license. No contradictions.
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?
The description is detailed and well-structured but slightly verbose. Each paragraph serves a purpose and front-loads key information. It could be trimmed slightly without losing value.
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 the output schema exists, the description fully covers behavior: return format (Markdown + structuredContent), caching, rate limits, edge cases (inflected forms, English reverse), and licensing. No gaps for the tool's complexity.
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%. The description adds value by explaining the difference between chu and eng modes, inflected form resolution via cached paradigms, and practical guidance for optional parameters like max_forms and include_forms.
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 clearly states it looks up an Old Church Slavonic word on Wiktionary, returning senses and full declension/conjugation tables. It also covers the reverse English lookup mode. The tool is distinguished from sibling tools like slavonic_get_inflections by noting that no follow-up is needed.
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 explains when to use this tool (direct lookup, reverse lookup, getting full inflections in one call) and mentions caching and rate limits. It refers to slavonic_get_inflections as an alternative, but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
slavonic_transliterateTransliterate Church Slavonic to scientific LatinARead-onlyIdempotentInspect
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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| text | Yes | The scientific transliteration. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it details dropping of liturgical marks, folding of late spellings, and that it returns Markdown plus structuredContent. Annotations already indicate read-only and idempotent, and description reinforces that with specifics.
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?
The description is a compact four-sentence paragraph that front-loads the purpose, provides examples, and covers key behaviors without extraneous 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?
Given the output schema exists (mentioned), the description covers input handling, transform behavior, and output format. It fully prepares an agent to invoke the tool 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?
The one parameter 'text' is fully covered in the schema description. The tool description adds context about how the text is processed (marks dropped, etc.) and the output format, which adds value beyond 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?
The description explicitly states it 'Render Church Slavonic — Cyrillic or Glagolitic — in the scientific Latin transliteration Wiktionary uses' with examples, clearly identifying the tool's purpose and distinguishing it from siblings which handle other languages.
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 explains when text will work as-is and that it is a pure local transform with no network or dictionary lookup, guiding usage. It does not explicitly mention when not to use, but the context of sibling tools for different languages provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!