estonian-mcp

check_numbers

Read-onlyIdempotent

Flags Estonian number-writing errors in text, including decimal and thousands separators, approximate tildes, month-year dates, range spacing, and percent suffixes.

Instructions

Flags number-writing slips (numbrite õigekirjutus):

decimal-separator: 3.14 → 3,14; skips kell 10.30, 14.05, punkt 3.2, Python 3.12, but flags a bare 10.30.
thousands-separator: 1,250 → 1250, 1,500,000 → 1 500 000 (EKI groups from five digits; ideally non-breaking spaces, suggestion has plain ones). If 1,250 was meant as the decimal 1,25, keep it.
approximate-tilde: 50 → u 50 (Umbes 50 at a sentence start; umbes and ligikaudu also fit). A style hint for general prose: EKI keeps the tilde for variants (mina ~ ma), so a spaced tilde after a word, ≈, code (inline, fenced or indented), paths, versions and ranges (510) are not flagged.
month-year-digits: 09.2016 → sept 2016, a date rather than a decimal; EKI finds the month in words clearer. A one-digit month (1.2019) is left alone, as it may be a rate, and 10 to 12 after a rate word or currency pair in the clause (kurss 11.2050, EUR/SEK, keskmine, koefitsient) is a decimal. Inflect a full month name to fit the sentence (alates märtsist 2019); abbreviations need no ending.
range-spacing: 2020 - 2024 → 2020-2024, 5 - 10 päeva → 5-10. Only a spaced keyboard hyphen between plain numbers; typeset EKI text uses the mõttekriips, also unspaced. Skips sums and expressions after =, scores, code, phone numbers, a label and its value (ülesanne 1 - 10 punkti), ends containing a space (9000 - 10 000), ordinal and season ranges (2015.-2019. aastal, 2019/2020), and month.year ends.
percent-sign-suffix: 20%-line → 20% or 20-protsendiline; case endings (10%-st, 5%-ni) are fine.

Spelling out small numbers is not checked.

Input Schema

Name	Required	Description	Default
`text`	Yes	Estonian text.

Output Schema

Name	Required	Description	Default
`issues`	No
`summary_estonian`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.9.0Oct 24, 2026
- changedInput schema / properties / text / description
```
Previous value: -"Estonian text to check for number-formatting (decimal comma, thousands space)."New value: +"Estonian text."
```
- removedInput schema / properties / text / title
```
Removed value: -"Text"
```
- removedInput schema / title
```
Removed value: -"check_numbersArguments"
```
- removedOutput schema / properties / issues / default
```
Removed value: -null
```
- removedOutput schema / properties / issues / items / additionalProperties
```
Removed value: -true
```
- removedOutput schema / properties / issues / title
```
Removed value: -"Issues"
```
- removedOutput schema / properties / note
```
Removed value: -{
-  "default": null,
-  "title": "Note",
-  "type": "string"
-}
```
- removedOutput schema / properties / summary_estonian / default
```
Removed value: -null
```
- removedOutput schema / properties / summary_estonian / title
```
Removed value: -"Summary Estonian"
```
- removedOutput schema / properties / text
```
Removed value: -{
-  "default": null,
-  "title": "Text",
-  "type": "string"
-}
```
- removedOutput schema / title
```
Removed value: -"_CheckResult"
```
First observedv0.2.4Jul 5, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish readOnly/idempotent/closed-world, and the description goes well beyond them: per-rule false-positive exclusions, the note that typeset mõttekriips is out of scope, and the disclosure that `suggestion` returns plain spaces where non-breaking spaces are ideal. That last point is genuinely useful output nuance; only the overall response shape is left to the output schema.

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 a one-line purpose, then a scannable bullet per rule with arrow examples — dense but each line carries rule, conversion, and exceptions. The bullets are long and exception-heavy (the range-spacing bullet alone carries five skip categories), which is justified for a linter but borders on spec-dumping.

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?

For a single-parameter read-only linter with an output schema, the description supplies everything an agent needs: what counts as a violation per category, what is deliberately not flagged, and that suggestions may be imperfect on whitespace. Nothing material 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?

One required parameter with 100% schema coverage ('Estonian text'). The description reinforces the input domain through its Estonian-language examples but adds no syntax, length, or formatting constraints for `text`, so the schema carries the semantics here.

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: flags number-writing slips (numbrite õigekirjutus) in Estonian text, then enumerates the six exact rule categories with before/after examples. This is clearly distinguishable from sibling linters like check_punctuation or check_hyphenation, which cover other orthographic domains.

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?

Each bullet defines the triggering condition plus explicit skips (code, paths, versions, scores, phone numbers, sums after =), and the closing line 'Spelling out small numbers is not checked' marks a real boundary. It never names an alternative sibling tool or says when to prefer this over, say, spell_check, so it stops short of full routing guidance.

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