estonian-mcp

check_punctuation

Read-onlyIdempotent

Detects missing commas in Estonian sentences, including before clause conjunctions and after subordinate clauses, to help correct punctuation.

Instructions

Flags a missing comma:

comma-before-clause-conjunction: before et, kuna, sest, kuigi, kuid, vaid, nagu, mistõttu, millepärast or kuhu. A comma before a pair (nii et, ilma et) passes, as does et after ja, ning, ega or ehk; nagu is flagged only before a clause with a verb.
comma-after-subordinate-clause: closing a clause opened after a comma by a relative word (kes, mis, kus) or a subordinator (et, kui, kas), before the main clause's verb: Mees, kes seal seisis oli minu isa → , oli; before its subject instead when that stands right before the verb and cannot be the clause's own (Hommikul, kui ärkasin päike juba paistis → , päike). Otherwise that is where the comma goes at the latest; it may belong earlier, before a longer fronted subject or inside a split phrase.
comma-before-ja-after-subordinate-clause: before ja or ning when the main clause goes on after a kes or mis clause, told by the verbs' person: Juhtisin projekti, mis kestis kaks aastat ja koolitasin → , ja.

The last two read only words that cannot be anything but a verb, so a verb that is also a noun (tuli, sai, lõppes) is missed; ei in ei ... ega and in ei tea kus, a -vad participle after olema (kes olid sobivad) and on in an English name (video on demand) are not counted. A line break, a table cell edge (| or a tab), an HTML tag, an arrow or a quotation mark ends the clause. Not checked: the comma before kui, mis or kes (it depends on meaning), apposition commas, dashes, colons. A comma before ja in a list and a letter's greeting and closing commas are check_translationese's.

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 missing commas before subordinating conjunctions."New value: +"Estonian text."
```
- removedInput schema / properties / text / title
```
Removed value: -"Text"
```
- removedInput schema / title
```
Removed value: -"check_punctuationArguments"
```
- 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

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description goes well beyond them by disclosing concrete false negatives (verb/noun homographs like tuli, sai, lõppes; ei in ei ... ega; -vad participles after olema; "on" inside English names) and the token boundaries that terminate a clause (line break, table cell edge, HTML tag, arrow, quotation mark). That is exactly the accuracy context an agent needs before trusting the output.

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?

The lead is front-loaded and each bullet is information-bearing, but the second bullet sprawls into a long, hard-to-parse sentence ("Otherwise that is where the comma goes at the latest; it may belong earlier, before a longer fronted subject or inside a split phrase"). Much of the rule-level detail is more useful for interpreting results than for deciding to call the tool, which is heavy for a one-parameter checker.

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?

With an output schema present, return values need no explanation, and the description fully covers scope, exclusions and known blind spots. The only residual gap is that it never states in its own text that the input must be Estonian or whether all issues in a passage are reported at once.

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?

There is a single parameter with 100% schema description coverage ("Estonian text."), so the schema carries the load and the baseline is 3. The description adds only indirect input hints — that line breaks, tabs and HTML tags act as clause boundaries — but never states the language requirement or input expectations itself.

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?

The description opens with a specific verb and outcome ("Flags a missing comma") and enumerates the three exact rule IDs it emits, so an agent knows precisely what class of problem is detected. It also names the sibling that owns the excluded cases ("check_translationese's"), making it distinguishable from check_style, check_capitalization and the rest.

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?

Scope boundaries are unusually explicit: the "Not checked" sentence lists kui/mis/kes commas, apposition commas, dashes and colons, and the final sentence routes list/greeting commas to check_translationese. There is no explicit "use this when" framing or statement that it should be combined with the other checks, so it stops short of a 5.

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