estonian-mcp

spell_check

Read-onlyIdempotent

Detects misspelled words in Estonian text and returns each token in order with correction suggestions when available.

Instructions

Spell-check Estonian text. Lists only the misspelled tokens, each occurrence in text order: text, spelling: false, and suggestions when Vabamorf has any. An empty list means every word passed.

Passing proves only that a word is well-formed: Vabamorf accepts any valid compound, even an invented one (toortõlkeoht). Check a compound you coined with check_compound_familiarity.

Input Schema

Name	Required	Description	Default
`text`	Yes	Estonian text.
`suggestions`	No	Include correction suggestions for misspelled words.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.9.0Oct 24, 2026
- removedInput schema / properties / suggestions / title
```
Removed value: -"Suggestions"
```
- changedInput schema / properties / text / description
```
Previous value: -"Estonian text to spell-check."New value: +"Estonian text."
```
- removedInput schema / properties / text / title
```
Removed value: -"Text"
```
- removedInput schema / title
```
Removed value: -"spell_checkArguments"
```
- removedOutput schema / properties / result / items / additionalProperties
```
Removed value: -true
```
- removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
- removedOutput schema / title
```
Removed value: -"spell_checkOutput"
```
First observedv0.2.4Jul 5, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent, but the description adds the crucial semantic caveat that a pass only proves well-formedness, not lexical reality, because Vabamorf accepts invented compounds. It also defines what an empty list means and when suggestions appear — behavior an agent could not derive from 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.

Conciseness4/5

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

Two short paragraphs, front-loaded with the core action and the key caveat, with no filler. Minor waste in enumerating output field names (`text`, `spelling: false`) that an existing output schema already covers, though the ordering and conditional-presence notes do earn some of that space.

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 needs only to explain semantics and caveats, and it does exactly that — what a hit looks like, what empty means, and the false-positive risk on compounds. Nothing an agent needs to call this correctly is missing.

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 both `text` and `suggestions` are already documented with a default. The description mentions `suggestions` only as an output field ("`suggestions` when Vabamorf has any"), which adds little to the parameter's own schema text; baseline 3 applies.

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 and resource ("Spell-check Estonian text") and immediately characterizes the output ("Lists only the misspelled tokens"). It also distinguishes itself from the compound-oriented siblings by naming check_compound_familiarity as the tool for coined compounds.

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

Usage Guidelines4/5

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

Gives a clear condition for escalating to check_compound_familiarity when a compound is newly coined, which is real routing guidance against a large sibling set. It does not, however, explain how it relates to check_punctuation, check_capitalization, or check_style, so an agent must infer the boundaries of the other check_* family members.

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