slavonic
Server Details
Grounds LLMs in real Church Slavonic: Wiktionary lemmas, dual-number paradigms, transliteration.
- 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.8/5 across 3 of 3 tools scored.
Each tool has a distinct purpose: search_slavonic for dictionary lookup, get_inflections for retrieving declension/conjugation tables of a specific lemma, and transliterate_slavonic for script conversion. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case: get_inflections, search_slavonic, transliterate_slavonic. Naming is clear and predictable.
With 3 tools, the server is well-scoped for its purpose of Old Church Slavonic linguistic data. Each tool earns its place without unnecessary redundancy or missing core operations.
The set covers searching, inflection lookup, and transliteration, which are the primary needs for this domain. One minor gap might be a tool to clear cache or list available lemmas, but overall it's fairly complete.
Available Tools
3 toolsget_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 provide readOnlyHint, idempotentHint, destructiveHint, openWorldHint. Description adds output format details (Markdown plus structuredContent with shape {'result': <paradigm>}), instructs to switch on result.category, and sources content from en.wiktionary.org (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?
Description is 5 sentences, front-loaded with purpose, efficient with no superfluous 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 parameters, annotations, output schema, and sibling tools, the description fully covers usage, output, and source. No gaps for an agent to be confused.
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 exist (100% coverage). Description adds context: entry_id as 'the Cyrillic lemma from a search result's inflection handle' with examples ('богъ', 'глаголати'), and word_class as 'the part-of-speech section' with examples ('verb', 'noun'). Enriches 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 fetches inflection tables for a lemma using entry_id and word_class. It distinguishes from sibling tools (search_slavonic, transliterate_slavonic) by specifying this is for retrieving tables, not searching or transliterating.
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 using only when a search ran without inline forms or left a match un-expanded, noting that a default search already returns inline tables. Provides clear context and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_slavonicLook 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 read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral details: caching, rate limiting, polite upstream fetching, lemma resolution for inflected forms, and content licensing (CC BY-SA) with attribution requirements. 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 well-structured and front-loaded with the main purpose, then explains special features, caching, output format, and license. It is somewhat long but every sentence adds value. Minor room for tightening, but not wasteful.
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, inflection resolution, caching, output with both Markdown and structuredContent matching outputSchema), the description covers all key aspects: usage modes, parameter effects, output format references, license requirements, and error handling (rate-limit retry). The presence of an output schema reduces the need to detail return values, and the description appropriately references 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?
Schema description coverage is 100% for all 4 parameters. The description goes beyond by explaining spelling normalization, performance implications of max_forms, the effect of include_forms on cold queries, and the dual-language mode for search_language. This adds significant practical guidance for the agent.
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 looks up an Old Church Slavonic word on Wiktionary and returns senses plus full declension/conjugation tables. It also explains the reverse lookup via English and notes that inflected queries resolve to lemmas. It implicitly distinguishes from sibling tool 'get_inflections' by stating that inflection tables are returned inline, avoiding a follow-up.
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 on when to use each mode (chu vs eng), how parameters like max_forms and include_forms affect behavior, and mentions caching and rate limits. However, it does not explicitly state when not to use this tool versus alternatives like get_inflections, though the inline return of inflections suggests using this tool instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transliterate_slavonicTransliterate 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?
Adds significant detail beyond annotations: drops liturgical marks, folds spellings, returns Markdown+structuredContent matching outputSchema, no dictionary/network. 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?
Single paragraph well-organized: purpose, example, behavior, return format. Slightly dense but clear; could be more structured but 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 complexity (two scripts, mark handling) and availability of output schema/annotations, description covers all essential aspects: input, processing, output, side effects (none).
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 100%, but description adds crucial context: accepts both scripts, handles marks and folding, works for copied liturgical text. Enhances understanding beyond schema's label.
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 tool transliterates Church Slavonic (Cyrillic or Glagolitic) to scientific Latin transliteration used by Wiktionary, with examples and distinction from siblings (get_inflections, search_slavonic).
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: for transliterating liturgical text with marks. Implicitly distinguishes from siblings by noting it's a pure local transform, no lookup or network. Lacks explicit 'do not use if...' 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.
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!