estonian-mcp

check_officialese

Read-onlyIdempotent

Detects Estonian officialese in reports, academic and business prose, flagging style issues so writers can revise toward plainer language.

Instructions

Flag Estonian kantseliit in reports, academic and business prose; statutes and contracts go to check_legalese, which protects terms of art.

Issue rules: impersonal-voice (ratio 0.4+, 4+ verbs), nominalisation (4+ -mine nouns per 100 words, positioned at the first), noun-density (noun/verb 2.5+, weakest: weigh it last), clause-stacking (3+ subordinate-clause openers in a sentence), long-sentence (25+ words), officialese-filler, officialese-phrase, poolt-calque, kusin-tapsemalt, calque-phrase. impersonal-voice and noun-density are document-wide (position 0). 'läbi viima' in the conduct sense is an officialese-phrase in any form (viidi läbi, on läbi viinud, viis uuringu läbi), and läbiviimine, läbiviija, läbiviidud, läbiviidav, läbi viimine an officialese-filler, suggesting korraldama / tegema (pidama for a meeting) in the same form, with the words between kept (viis uuringu läbi → korraldas uuringu); routes and threaded objects (Rada viib läbi metsa, Kaabel tuleb läbi viia seinast, kaabli läbiviimine), time spans (päev läbi), postpositions, the numeral viis and the fugue term are skipped, and the 'läbi suruma' sense is not told apart. A thing carried through with no route word (Kohver viidi läbi) is still flagged. kusin-tapsemalt is a sentence-initial 'Küsin/Küsime täpsemalt, kas …' in a letter; a plan to ask someone else matches too unless a reporting-back verb follows (…, ja annan teada; …, ja võtan teiega ühendust), and quoted speech, a dialogue-dash line and a quoted e-mail line ('>') are skipped. Both are style hints, not errors. calque-phrase is a translated stock phrase of letters: sealhulgas, kuid mitte ainult (and eelkõige, kuid mitte ainult, where only the tail goes); antud juhul / hetkel / olukorras, not the participle (on antud olukorras, kus ...); adresseerima a problem, not a mail item; ärge kõhelge ... võtmast, rewritten with its own verb; kiri leiab teid hästi; tänan teid teie ... eest; vaatan edasi koostööle, with an awaited event (not vaatas edasi merele); Palun leidke manuses, not a search instruction (Palun leidke manusest oma nimi). Leiate manusest and läbi e-posti are accepted Estonian and not flagged. metrics.nominalisations gives each -mine noun's verb, a particle verb written apart (läbivaatamine → läbi vaatama, tagaajamine → taga ajama), a noun + verb compound by its head (riskihindamine → hindama, sisuloomine → looma), and no verb when none is known. The split 'läbi viimine' counts as läbiviimine. Nouns lexicalised as things (teadmised, pakkumine, kohtumine, ettevõtmine and their compounds) and -misi adverbs (vaikimisi) are not counted.

Precision-first starter lexicons: no issues is not proof the text is plain.

Input Schema

Name	Required	Description	Default
`text`	Yes	Estonian non-legal prose (report, academic, business).

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv0.9.0Oct 24, 2026
- changedInput schema / properties / text / description
```
Previous value: -"Estonian non-legal text (report, academic, business) to check for kantseliit / bureaucratic density."New value: +"Estonian non-legal prose (report, academic, business)."
```
- removedInput schema / properties / text / title
```
Removed value: -"Text"
```
- removedInput schema / title
```
Removed value: -"check_officialeseArguments"
```
- 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 / metrics / additionalProperties
```
Removed value: -true
```
- removedOutput schema / properties / metrics / default
```
Removed value: -null
```
- removedOutput schema / properties / metrics / title
```
Removed value: -"Metrics"
```
- 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: -"_OfficialeseResult"
```
Addedv0.5.6Aug 23, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/openWorld, so the description is free to disclose genuine behavior — and it does: per-rule thresholds, which rules are document-wide (position 0), which senses are skipped, and precise false-positive carve-outs. The one gap is that the `metrics.nominalisations` explanation is a return-value detail rather than invocation behavior, and the description never states the output shape at a high level (though an output schema exists).

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

Conciseness3/5

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

Purpose and rule inventory are front-loaded and machine-scannable via backticked rule names, but the second half collapses into a dense run-on paragraph of micro edge cases (the numeral viis, the fugue term, "Kohver viidi läbi", quote-line skipping). These are real precision aids but are unstructured and would read far better as bullets; the agent must parse a wall of prose to extract the exclusion rules.

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?

Since an output schema exists, return values needn't be explained — yet the description still clarifies the one ambiguous field (`metrics.nominalisations`, its verb resolution, split-particle handling, and lexicalised exclusions). For a rule-engine style checker with 10+ rules and many carve-outs, this is materially complete.

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?

Single parameter with 100% schema coverage, so the baseline is 4. The description reinforces the expected input domain (Estonian non-legal prose; kantseliit-bearing reports/academic/business text) which adds a small amount of guidance beyond the schema's own "Estonian non-legal prose (report, academic, business)."

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?

Opens with a specific verb+resource+scope: "Flag Estonian kantseliit in reports, academic and business prose" and immediately names the boundary case ("statutes and contracts go to check_legalese"). An agent can distinguish this from check_legalese, check_style, and classify_register without opening a schema.

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?

Explicitly routes the alternative: legal texts go to check_legalese; this tool is for non-legal prose. It also states the tool's epistemic posture ("Both are style hints, not errors" and "no issues is not proof the text is plain"), which tells the agent how to interpret results rather than just when to call.

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