estonian-mcp

common_legal_usage

Read-onlyIdempotent

Retrieve common legal collocations for an Estonian word from Riigi Teataja legislation to use correct phrasing instead of inventing it.

Instructions

Standard legal collocations for an Estonian word, from an index of Riigi Teataja legislation (the bundled one: five core codes). Use it instead of inventing legal phrasing.

common_before / common_after: the commonest lemmas of the nearest content word on each side, with counts; inflect them to fit. A frequency signal, not a rule. found: false says only that the index lacks the word, not that it is wrong.

Input Schema

Name	Required	Description	Default
`word`	Yes	One Estonian word, any inflected form.

Output Schema

Name	Required	Description	Default
`found`	No
`lemma`	No
`frequency`	No
`common_after`	No
`common_before`	No
`summary_estonian`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed20 schema fields changedv0.9.0Oct 24, 2026
- changedInput schema / properties / word / description
```
Previous value: -"A single Estonian (legal) word to look up canonical collocations for, e.g. 'hagi', 'kohustus', 'taotlus'."New value: +"One Estonian word, any inflected form."
```
- removedInput schema / properties / word / title
```
Removed value: -"Word"
```
- removedInput schema / title
```
Removed value: -"common_legal_usageArguments"
```
- removedOutput schema / properties / common_after / default
```
Removed value: -null
```
- removedOutput schema / properties / common_after / items / additionalProperties
```
Removed value: -true
```
- removedOutput schema / properties / common_after / title
```
Removed value: -"Common After"
```
- removedOutput schema / properties / common_before / default
```
Removed value: -null
```
- removedOutput schema / properties / common_before / items / additionalProperties
```
Removed value: -true
```
- removedOutput schema / properties / common_before / title
```
Removed value: -"Common Before"
```
- removedOutput schema / properties / found / default
```
Removed value: -null
```
- removedOutput schema / properties / found / title
```
Removed value: -"Found"
```
- removedOutput schema / properties / frequency / default
```
Removed value: -null
```
- removedOutput schema / properties / frequency / title
```
Removed value: -"Frequency"
```
- removedOutput schema / properties / lemma / default
```
Removed value: -null
```
- removedOutput schema / properties / lemma / title
```
Removed value: -"Lemma"
```
- 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 / word
```
Removed value: -{
-  "default": null,
-  "title": "Word",
-  "type": "string"
-}
```
- removedOutput schema / title
```
Removed value: -"_LegalUsageResult"
```
Addedv0.5.6Aug 23, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover read-only, closed-world and idempotency, so the bar is lower; the description still adds real interpretive context: the fields returned (common_before/common_after with counts), the instruction to inflect them, and the warning that this is "a frequency signal, not a rule" and that found:false is not a correctness verdict. That is exactly the kind of caveat the schema cannot express.

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-loads purpose, then qualifies the output semantics in two tight follow-up sentences. Every clause carries distinct information (scope, field meaning, caveat) with no repetition.

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?

Even though an output schema exists, the description supplies the interpretive layer an agent needs to act on the results correctly: what the frequency counts mean, that lemmas must be inflected, and that a miss is not a judgement. Nothing essential to correct invocation or interpretation 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 coverage is 100% and the single parameter's own description already says "one Estonian word, any inflected form." The description adds no parameter-level detail beyond that, so the baseline 3 applies; its added value lies in interpreting the output fields, which is scored elsewhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and verb: legal collocations for an Estonian word drawn from an index of Riigi Teataja legislation, with the exact scope of the bundled corpus (five core codes). It carves out a distinct niche versus the check_*/analyze_* siblings, though it does not name a specific alternative to prefer over it.

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?

"Use it instead of inventing legal phrasing" gives a clear positive usage condition, and the found:false caveat tells the agent not to treat an empty result as an error. No explicit when-not-to-use or named sibling alternative is given.

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