estonian-mcp

check_redundancy

Read-onlyIdempotent

Detects redundant doubling and pleonasms in Estonian text, including doubled "also" particles, double superlatives, and fixed pleonasms, so you can remove unnecessary repetition.

Instructions

Flags redundant doubling (liiasus, pleonasm):

doubled-also: two "also" particles together (samuti ka, ka samuti, ühtlasi ka); keep one.
double-superlative: kõige before an absolute adjective (kõige optimaalsem, "most optimal"); drop kõige.
fixed-pleonasm: a short curated list (ajaline periood, väike nüanss, üldine konsensus).

Each issue's explanation gives the reason in Estonian. Conservative: it misses much redundancy a native speaker would hear.

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 pleonasm / redundant word pairs."New value: +"Estonian text."
```
- removedInput schema / properties / text / title
```
Removed value: -"Text"
```
- removedInput schema / title
```
Removed value: -"check_redundancyArguments"
```
- 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/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent and closed-world behavior, and the description adds real value beyond them: the exact detection taxonomy, the fact that each issue's `explanation` is in Estonian, and an honest recall limitation ('misses much redundancy a native speaker would hear'). It does not state severity levels or whether output is per-occurrence, but the conservativeness disclosure is substantive.

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

Conciseness5/5

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

Front-loaded purpose statement followed by a tight bulleted taxonomy where each bullet earns its place by pairing a category code with concrete examples. The final sentence on conservativeness is short and load-bearing, with no filler.

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

Completeness4/5

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

An output schema exists, so return structure need not be explained, and the description covers categories, explanation language, and known recall gaps. Minor gaps remain: nothing on input size limits or what happens with non-Estonian text. For a single-parameter checker this is close to complete.

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 parameter with 100% schema description coverage, so the schema already documents `text` as Estonian text. The description adds nothing about the parameter itself (no length limits, no handling of mixed-language input). Baseline 3 applies when the schema does the heavy lifting.

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?

Names a specific verb (flags) and a precise linguistic resource (redundant doubling / liiasus / pleonasm), then enumerates the exact three categories it detects with Estonian examples. Among the many check_* siblings this is unmistakably the redundancy checker, distinguishable without opening the schema.

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: pass Estonian text and it reports doubling/pleonasm issues. There is no explicit when-to-use versus check_style, check_officialese, or check_compounds, nor any when-not guidance. The closing note about being conservative hints at when to distrust results, which is useful but not full routing guidance.

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