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 13 of 13 tools scored.
Each tool is prefixed with the language name, making cross-language ambiguities impossible. Within a language, search and get_inflections have clearly distinct purposes, and utility tools like lemmatize or romanize are additional and non-overlapping.
All tools follow a consistent `<language>_<action>` pattern. The actions are uniform: search, get_inflections, plus language-specific helpers (lemmatize, romanize, get_descendants, transliterate). No mixing of conventions.
13 tools cover five languages, each with a core search tool and inflection retrieval, plus a few language-specific extras. The count is well within the 3-15 ideal range and each tool earns its place without bloat.
For each language, the surface provides look-up (search) and detailed inflection tables (get_inflections), which are the primary needs for a dictionary server. Utility tools for lemmatization, romanization, and transliteration fill common secondary needs. No obvious gaps.
Available Tools
13 toolslatin_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 declare readOnlyHint, idempotentHint, and destructiveHint, so the tool's safety is clear. The description adds behavioral details: returns Markdown plus structuredContent with a specific shape, instructs to switch on result.category, and states the content source (Wiktionary, CC BY-SA 4.0). No contradiction 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 concise with four sentences, each serving a purpose: main action, usage guidance, output format, and attribution. No unnecessary words; information is front-loaded.
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 (though not displayed), the description adequately covers all necessary context: when to use, how to obtain inputs, what the output looks like (Markdown + structuredContent with category switch), and source attribution. It is complete for an AI 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 coverage is 100% with both parameters documented. The description adds value by explaining that these parameters come from a search result's inflection handle and gives examples (e.g., 'amo' for entry_id, 'verb' for word_class), which clarifies their 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 uses 'Fetch the full declension or conjugation table' and clearly identifies the resource as a paradigm for a lemma. It distinguishes from sibling tools like latin_search by noting that a default search already returns inline tables, and this tool is for when the search did not include them.
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 '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.' Provides clear when-to-use and when-not-to-use guidance, and explains how to obtain the arguments from a search result's inflection handle.
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, search_latin 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 declare readOnlyHint, idempotentHint, destructiveHint. Description adds that results are cached server-side and uses Perseids Morpheus service, providing useful behavioral context beyond annotations. 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?
Four sentences, all relevant and front-loaded with purpose. No redundant information. Efficient and clear.
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 tool with one parameter and presence of output schema, the description covers return format (Markdown + structuredContent), external service, and caching. Complete for its 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 has 100% coverage with a detailed description for the single parameter. The overall description adds context about the service and output format, but does not significantly enhance parameter meaning beyond the schema's own description. 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?
Description clearly states it analyzes one inflected Latin form to return lemma(s) and grammatical reading. It distinguishes from sibling tool latin_search by noting that for dictionary entries, search_latin resolves inflected queries on its own, so purpose is specific and differentiated.
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 when to use this tool (when you want morphology) vs. sibling latin_search (for dictionary entry). Mentions caching but no explicit exclusions or prerequisites. Clear context but lacks additional usage caveats.
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 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 / 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?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint false), description adds caching, rate limits, inflected form resolution via Morpheus, return format (Markdown + structuredContent), and attribution requirements. 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?
Description is thorough but every sentence adds value. Front-loaded with primary purpose. Slightly long but appropriate given tool complexity and multiple modes.
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 major aspects: query languages, input forms, caching, rate limits, output format, and reuse restrictions. Output schema exists, so return values are documented elsewhere. Complete for a tool of this 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 coverage is 100% so baseline is 3. Description adds significant user-facing details: macrons optional, English multi-word queries, resolution of inflected forms, and effect of include_forms on server load, enhancing understandability 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?
Description clearly states the verb 'Look up' and the resource 'Latin word on Wiktionary', with detailed explanation of English reverse lookup mode. It distinguishes from siblings like latin_get_inflections by covering full declension/conjugation tables and morphological resolution.
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?
Describes when to use Latin vs English query mode, that any form works, and caching/rate limit behavior. Lacks explicit mention of when to prefer sibling tools like latin_get_inflections, but context is clear enough.
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 search_livonian 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?
The description details the return format (Markdown and structuredContent with category), caching behavior, rate limits with retry guidance, and licensing attribution requirement, all of which go beyond the annotations that only indicate readOnly, idempotent, and 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 well-structured: purpose first, then usage guidelines, then output details, caching, rate limits, and licensing. Every sentence adds value without redundancy, making it appropriately sized for the complexity.
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 two simple params, an output schema, and no nested objects, the description covers all necessary context: when to use, how to use, what the output looks like, error handling, and licensing, leaving no gaps 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 coverage is 100%, so baseline is 3. The description does not add new semantic meaning beyond what the schema already provides; it only mentions the handle concept which is implicit in the parameter names.
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 the full declension or conjugation table for a word using a specific handle, distinguishing it from other language-specific inflection tools by explicitly naming the language and the exact input method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use ('only when a search ran without inline forms or to fetch a match from a broad search') and when not to use ('never a first call', 'just re-fetches what you have'), and mentions the alternative of using default search which already returns inline tables.
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?
Description adds behavioral context beyond annotations: pure local transform, no network, always ASCII output, returns Markdown and structuredContent. 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 sentences, each serving a purpose: stating goal, directing to parameter docs, describing return format. No wasted 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?
Given the simple single-parameter tool with full schema coverage and output schema, the description is complete. It covers purpose, usage, parameter detail guidance, output format, and behavioral traits.
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 contains detailed mapping rules. The tool description adds no new parameter semantics, thus baseline of 3.
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?
Title and description clearly state the action of romanizing Livonian text to clean ASCII. Specific verb 'strip' and resource 'Livonian orthography' are used. Distinguishes from sibling tools by language specificity and output format.
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?
Description specifies use for English-trained downstream systems like TTS or search boxes. It does not explicitly state when not to use or provide alternatives, but the context is clear given the sibling set.
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 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 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 get_inflections. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds extensive behavioral context beyond annotations: caching behavior, rate limits, automatic lemma resolution for inflected forms, default inline inflection tables, and the trade-off with max_forms. It even mentions the source attribution license. This is highly transparent.
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 a clear opening purpose, followed by behavioral notes and parameter details. While comprehensive, it could be slightly tightened without losing clarity. It is front-loaded with the core function and use cases.
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, caching, rate limits) and the presence of an output schema, the description covers all necessary aspects: return format (Markdown + structuredContent), how to handle broad queries, and error recovery. It is complete for an agent to use effectively.
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 parameter descriptions in the schema are already detailed (100% coverage), but the tool description enriches them with practical usage tips: query must be a single word, examples for each search language, and the trade-off for include_forms and max_forms. This adds significant semantic value.
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 is for looking up words in a Livonian dictionary, returning attested content. It distinguishes from sibling tools like latin_search and norse_search by focusing on Livonian, and mentions the bidirectional translation capability.
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 when-to-use guidance: search meanings to find headwords or search Livonian words to confirm existence. It explains when to use get_inflections for broad queries, though it doesn't explicitly compare with other siblings like livonian_romanize. Caching and rate-limit handling are also useful for usage decisions.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that it returns both Markdown and structuredContent with a category switch, and notes the content source (en.wiktionary.org). This goes beyond annotations 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?
Three sentences, front-loaded with purpose. Every sentence adds necessary information without redundancy. License attribution is appropriately placed at the end.
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 existence of an output schema, the description adequately covers input sources, output shape, usage context, and data provenance. No gaps identified.
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%, but the description adds value by explaining that parameters come from a search result's inflection handle and providing concrete examples for both entry_id and word_class.
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 'Fetch', the resource 'full declension or conjugation tables', and the scope 'for a lemma identified by a search result's inflection handle'. It distinguishes from siblings by noting that a default search already 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 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.' This provides clear when-to-use and when-not-to-use guidance, referencing the sibling norse_search.
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 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?
The description adds significant behavioral context beyond annotations: caching behavior, rate limiting with retry advice, automatic inflection resolution via cached paradigms, and licensing attribution. 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 into a few sentences covering purpose, usage, and behavior. It could be slightly more concise but remains clear and front-loaded with the main action.
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 exists), the description covers caching, rate limiting, attribution, inflection resolution, and return format (Markdown + structuredContent). It is complete and self-contained.
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?
Despite 100% schema coverage, the description enriches each parameter with contextual examples (e.g., 'mǫnnum' to 'maðr'), trade-offs for max_forms, and explanation of include_forms bounding. It adds value beyond the schema definitions.
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, returning senses and full declension/conjugation tables. It distinguishes from siblings like norse_get_inflections by noting inflections are returned inline, and adds English reverse lookup functionality.
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 ('non' vs 'eng') and that any word form works. It implies this is the primary single-call tool by noting no follow-up get_inflections needed, but does not explicitly state when not to use it.
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?
Annotations already indicate readOnlyHint and idempotentHint. The description adds value by detailing the return format (Markdown plus structuredContent with shape), advising on handling the 'result.category' field, and acknowledging the content source (CC BY-SA 4.0), which goes beyond the 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, starting with the core purpose, then providing usage conditions, return structure details, and attribution. Every sentence serves a clear function with 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 presence of an output schema and comprehensive annotations, the description completes the picture by explaining the return structure, how to interpret the result, and the data origin. It is fully adequate for an AI 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?
Schema coverage is 100% with parameter descriptions that include examples and constraints (e.g., no asterisk for entry_id, pattern for word_class). The tool description does not add significant new information about the parameters beyond the schema, so 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 clearly states the verb 'Fetch' and the resource 'full descendants payload', specifying that it retrieves etymology, glosses, and reflex tree for a Proto-Scythian lemma. It effectively distinguishes from sibling tools like scythian_search by noting that default searches already return inline payloads.
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 payloads or left a match un-expanded', providing clear when-to-use and when-not-to-use guidance. It contrasts with the default search behavior, offering a functional alternative.
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 get_descendants_scythian. 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. Description adds operational details: server-side caching, polite rate limiting, content source and license (CC BY-SA 4.0), and that results include both Markdown and structuredContent matching outputSchema. No 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 detailed but each sentence adds value. Front-loaded with main purpose, followed by specifics. Could be slightly more structured (e.g., separating search modes more clearly), but it remains readable 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 the tool's complexity (two search modes, parameter interactions, caching, rate limiting, output format), the description covers all necessary aspects. It explains the return format and references the output schema, 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?
Schema descriptions already cover all parameters thoroughly (100% coverage). Description adds further context: e.g., ASCII folding rules for query, the effect of max_forms on cold queries, and the behavior of include_forms for eng searches. This goes meaningfully 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?
Clearly describes two search modes: lookup a Proto-Scythian lemma (with ASCII folding) or reverse search via English, and what is returned (senses, descendants). Distinguishes from sibling scythian_get_descendants by noting it can include descendants 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?
Provides explicit guidance on when to use each search_language ('xsc' vs 'eng'), explains caching and rate limiting with retry advice, and notes the alternative of using get_descendants separately. Also clarifies the behavior of include_forms and max_forms.
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?
Annotations declare read-only, idempotent, non-destructive. Description adds that it returns Markdown plus structuredContent with a specific shape, and advises switching on result.category. Source attribution adds transparency.
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 concise sentences plus attribution. Front-loaded with main action, 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?
Given the tool's moderate complexity, the description covers behavior, parameters, return shape, usage context, and source. Output schema existence is mentioned. Sibling tools differ by language, so differentiation is clear.
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 detailed descriptions. Description adds context by explaining that parameters come from a search result's inflection handle, linking to usage guidelines.
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 Church Slavonic using entry_id and word_class. It distinguishes from sibling tools by specifying the language and context (when search didn't return inline). The verb 'Fetch' and resource 'inflection table' 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: only when a search ran without inline forms or left a match un-expanded, noting that default search returns inline. This provides clear usage boundaries and compares to default behavior.
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 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 indicate readOnlyHint and idempotentHint. The description adds behavioral details: caching, polite rate limiting, CC BY-SA 4.0 licensing, Markdown+structured output. No contradictions. Good context 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 well-structured and front-loaded with purpose. It is about 7-8 sentences, covering all key aspects without excessive verbosity. Could be slightly more concise, but still 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?
Given the output schema exists and the description mentions Markdown and structuredContent, it is complete for a search tool. It also clarifies caching, rate limits, and idempotency. No missing details 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?
Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining inflected form resolution for 'query', pacing implications for 'max_forms', inline vs. cheap screen for 'include_forms', and reverse lookup for 'search_language'.
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 Old Church Slavonic words on Wiktionary, returns senses and full declension/conjugation tables, handles inflected forms, and allows reverse English searches. It distinguishes itself from sibling tools like slavonic_get_inflections by offering a complete lookup in one call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for full lookups, including inflected form resolution and reverse English searches) and mentions caching and rate limits. However, it does not explicitly state when not to use it or name alternatives for partial tasks.
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 discloses key behaviors beyond what annotations provide: it drops liturgical reading marks (titlos, accents) and folds late Church Slavonic spellings. It also mentions the output format (Markdown with structuredContent matching the outputSchema) and confirms it is a local transform. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint).
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 (three sentences) and well-structured: it starts with the core action, provides an example, explains what is dropped, mentions the output format, and notes the local nature. Every sentence adds value 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 simplicity (one parameter, no nested objects, output schema present), the description covers all necessary context: transliteration target, handling of liturgical marks and late spellings, output format, and non-networked behavior. Annotations address safety, so the description is fully 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?
The input schema has 100% description coverage for the single 'text' parameter, providing detailed information about what it accepts and how it processes the text. The tool description briefly reiterates some of this but does not add significant new semantics beyond the schema's own description. 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 clearly states the tool's purpose: to transliterate Church Slavonic (Cyrillic or Glagolitic) to scientific Latin transliteration as used by Wiktionary. It provides a specific example (богъ → bogŭ, ⰱⱁⰳⱏ → bogŭ) and distinguishes it from sibling tools, which focus on inflections, lemmatization, or 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?
The description implies when to use the tool (e.g., 'copied liturgical text works as-is') and notes it is a pure local transform with no network or dictionary lookup. While it does not explicitly state when not to use it or point to alternatives, the sibling tools are sufficiently different that an agent can infer appropriate usage.
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!