latgalian
Server Details
Grounds LLMs in real Latgalian: Wiktionary lemmas, inflections, romanization.
- 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.6/5 across 3 of 3 tools scored.
Each tool has a distinct purpose: lookup/expand, fetch inflections by handle, and romanize. No overlap, and descriptions clearly differentiate them.
All tools follow the `latgalian_<verb>` pattern with consistent snake_case and clearly descriptive verbs.
3 tools are well-scoped for a specialized linguistic server covering search, inflections, and romanization without redundancy.
The set covers the full expected workflow (search, inflections, romanization). No obvious missing operations given the domain.
Available Tools
3 toolslatgalian_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=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral details: it returns Markdown plus structuredContent with a specific shape and mentions the source license. While it doesn't discuss rate limits or size constraints, it provides useful 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?
Three sentences covering purpose, usage, and output format in a compact, front-loaded manner. No redundant information; 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 as a specific inflection lookup with an output schema, the description covers usage conditions, output structure (Markdown + structuredContent with category), and source. Minor omission: no mention of error handling beyond 'not_found' category, but output schema implies 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 description coverage is 100%, with both entry_id and word_class having descriptive texts. The description adds value by explaining they come from a 'search result's inflection handle' and provides examples, clarifying their provenance and usage.
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 (nominals) or conjugation (verbs — positive AND negative) tables' for a lemma, using input fields entry_id and word_class. It distinguishes from siblings by noting that a default search already returns inline forms, 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 '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 guidance and implicitly when not to use. Also explains how to handle the output by switching on result.category.
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 indicate readOnly, idempotent, non-destructive. The description adds valuable behavioral details: it's a one-way diacritic drop, no external calls, always ASCII output, and returns Markdown with structuredContent. 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 very concise (three sentences), front-loads the purpose, and each sentence adds essential information without fluff.
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 low complexity, rich annotations, and presence of an output schema, the description covers all necessary aspects: purpose, behavior, parameter guidance, and expected output.
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% coverage with a detailed parameter description. The tool description further summarizes the mapping rules and directs to the param doc, adding 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 clearly states the tool strips Latgalian orthography to clean ASCII, with a specific purpose for English-trained downstream systems like TTS or search. It distinguishes from siblings (inflections, search) by focusing on pure romanization.
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 it's a pure local transform with no network or dictionary lookup, implying it's for simple phonetic conversion. It doesn't explicitly state when not to use it, but the context from siblings and the tool's simplicity provides sufficient guidance.
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?
Annotations already mark it as read-only, open-world, idempotent, and non-destructive. The description adds value by explaining caching, rate limiting, retry behavior, and content licensing, 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 well-structured and front-loaded with the primary purpose, but somewhat lengthy. Every sentence adds value, though some details could be slightly more compact.
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, two modes, caching, output schema), the description covers all essential aspects: both search languages, inflection resolution, caching, error handling, and output format. 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 description coverage is 100%, so baseline is 3. The description clarifies the interplay between 'max_forms' and 'include_forms', but doesn't add substantial meaning beyond the already detailed 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 looks up Latgalian words on Wiktionary and returns senses plus inflection tables. It explicitly distinguishes from sibling 'latgalian_get_inflections' by noting no follow-up is needed for full tables.
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 guidance on when to use 'include_forms=false' and how the two search languages work. However, it does not explicitly state when to use the sibling tool instead of this one.
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!