Skip to main content
Glama

Look an Interslavic word up

interslavic_search
Read-onlyIdempotent

Look an Interslavic word up in the bundled community dictionary and return its translation matrix (English + 11 Slavic languages) plus its full, algorithmically-generated declension/conjugation table. Any form and either script works; an inflected query resolves to its headword and the result notes it. With search_language='eng' the query is an English word: the result lists its Interslavic equivalents plus their expanded entries. Returns Markdown plus the same result as structuredContent matching the declared outputSchema.

Fully offline (bundled snapshot); calls are rate limited per client IP. Content: the Interslavic dictionary (van Steenbergen et al.); reuse licence unconfirmed — attribute the source.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe word to look up, in the language search_language names. Interslavic (default): a SINGLE Interslavic word, any form and either script — an inflected form ('brata') resolves to its headword ('brat') via the reverse form index, Latin and Cyrillic both work for headwords, and diacritics are optional ('delati' finds 'dělati'). English (search_language='eng'): the English word whose Interslavic equivalents you want.
max_formsNoOptional override for how many inflection tables to expand this call (0–12). Tables are served from the bundled dataset (no network), so this is cheap. Omit for the server default.
include_formsNoWhen true (default), each match's full declension/conjugation table is returned INLINE — usable cases/tenses in ONE call, no follow-up interslavic_get_inflections. Set false for a cheap screen of which entries exist. Bounded by a per-search cap — use max_forms to adjust per call. Pronouns, numerals and indeclinables carry no table. For eng queries this governs the expanded Interslavic entries.
search_languageNoLanguage the query is in: 'isv' (default) looks the Interslavic word up directly; 'eng' finds the Interslavic equivalents of an English word (via the gloss index) and returns their full entries. These are the only two queryable languages in v1 — each entry ALSO carries a read-only translation matrix into 11 more languages (Russian, Polish, Czech, Ukrainian, …), but you cannot query IN those.isv

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
foundYesFalse when nothing matched. For an eng query, True means the gloss index named Interslavic words — entries may still be empty when none of them expanded (see translations).
queryYes
sourceNoInterslavic dictionary (Medžuslovjansky slovnik), J. van Steenbergen et al. — steen.free.fr / medzuslovjansky (interslavic-dictionary.com). Morphology by @interslavic/utils. Reuse licence unconfirmed; reused here with attribution.
entriesNo
handlesNo
languageYes
translationsNoPopulated only for eng queries (always [] for isv): the Interslavic words whose English gloss matched the query. Entries/handles below are the expanded entries of those words.
resolved_fromNoThe original query when resolved via the index; else empty. isv queries only — always empty for eng results.
search_methodNoHow the match was found: 'direct' = the query matched a headword; 'lemma_index' = an inflected/alternate spelling resolved via the reverse form index; 'translations' = an English query resolved via the gloss index.direct
resolved_lemmaNoThe headword actually searched when resolved; else empty. isv queries only — always empty for eng results.
forms_truncatedNoHow many handles did NOT get an inline table because the per-search cap was reached.
translations_truncatedNoHow many distinct matched words were NOT expanded into entries because the per-search expansion cap was reached (they still appear under translations).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the annotations: fully offline bundled snapshot, per-client-IP rate limiting, Markdown plus structuredContent output matching the outputSchema, inflected-form resolution to headword, and reverse English-gloss search. The annotations already establish read-only, idempotent, and closed-world behavior, and the description is fully consistent with them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose and key behavior in the first paragraph, then gives terse operational and licensing notes. It is efficient for the tool's complexity, though the content-reuse licence sentence is metadata rather than invocation guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With the output schema covering return structure and annotations covering safety, the description supplies the remaining operational context: offline snapshot, rate limits, input form/script behavior, and search_language modes. This is complete enough for an agent to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters in detail. The description reinforces query flexibility and search_language='eng' behavior, but adds no syntax or constraints beyond what the schema provides, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: looking up an Interslavic word and returning its translation matrix plus declension/conjugation table. It clarifies scope and behavior for both query languages, but does not name nearby sibling interslavic_get_inflections in the main description to differentiate search from dedicated inflection retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied as a dictionary search, and the description explains search_language='eng' vs default isv. However, it does not explicitly say when to prefer this tool over interslavic_get_inflections or the transliteration siblings, nor when not to use it. The include_forms parameter description mentions avoiding a follow-up call, but the main description lacks routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources