hub

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

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

Output Schema

Name	Required	Description	Default
`found`	Yes	False when nothing matched. For an eng query, True means the gloss index named Interslavic words — entries may still be empty when none of them expanded (see translations).
`query`	Yes
`source`	No		Interslavic 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.
`entries`	No
`handles`	No
`language`	Yes
`translations`	No	Populated only for eng queries (always [] for isv): the Interslavic words whose English gloss matched the query. Entries/handles below are the expanded entries of those words.
`resolved_from`	No	The original query when resolved via the index; else empty. isv queries only — always empty for eng results.
`search_method`	No	How the match was found: 'direct' = the query matched a headword; 'lemma_index' = an inflected/alternate spelling resolved via the reverse form index; 'translations' = an English query resolved via the gloss index.	direct
`resolved_lemma`	No	The headword actually searched when resolved; else empty. isv queries only — always empty for eng results.
`forms_truncated`	No	How many handles did NOT get an inline table because the per-search cap was reached.
`matches_truncated`	No	How many matched words were NOT returned because the per-search match cap was reached (eng queries only).
`translations_truncated`	No	How many distinct matched words were NOT expanded into entries because the per-search expansion cap was reached (they still appear under translations).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

addedOutput schema / properties / matches_truncated

Added value: +{
+  "default": 0,
+  "description": "How many matched words were NOT returned because the per-search match cap was reached (eng queries only).",
+  "title": "Matches Truncated",
+  "type": "integer"
+}

AddedJul 12, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses offline bundled snapshot behavior, per-client-IP rate limiting, source attribution/licensing caveat, inflected-query resolution noting, and that results come as both Markdown and structuredContent. This is exactly the value-add layer annotations cannot carry.

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-loaded with purpose, then behavior, then operational constraints; each sentence contributes. Slightly dense and repeats some search_language detail already in the schema, but no wasted filler.

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 an output schema present, the description need only signal the return shape, which it does (Markdown + structuredContent). Combined with rate-limit, offline, and licensing notes, an agent has everything needed to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description still adds operational meaning — that 'eng' returns Interslavic equivalents with expanded entries, and that include_forms governs expanded entries for eng queries. It largely restates the schema's enum semantics, but the cheap-screen guidance for include_forms is genuine added value.

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

Purpose5/5

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

States a specific verb+resource ('Look an Interslavic word up in the bundled community dictionary') plus the scope of the return value (translation matrix + full inflection table). It also distinguishes its behavior from siblings by ruling out a follow-up call to interslavic_get_inflections.

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

Usage Guidelines5/5

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

Explicit conditions are given: any form and either script resolves; search_language='eng' switches to reverse lookup; include_forms=false gives a cheap existence screen; max_forms adjusts the per-call cap. It also names the alternative (interslavic_get_inflections) and states it is unnecessary by default.

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

All hub tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?