estonian-mcp

check_defined_terms

Read-onlyIdempotent

Maps defined terms and cross-references in Estonian legal documents, flagging duplicate or unused definitions so you can verify terminology before relying on it.

Instructions

Maps defined terms and cross-references in a long Estonian legal document.

defined_terms: each (edaspidi «X») term. total_occurrences counts exact-form, case-sensitive matches, the definition included, so it misses inflected uses: verify a defined-but-unused issue before acting. cross_references: §, lõige, punkt and artikkel mentions, not validated. issues: terms defined twice or unused.

Input Schema

Name	Required	Description	Default
`text`	Yes	Whole Estonian legal document.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv0.9.0Oct 24, 2026
- changedInput schema / properties / text / description
```
Previous value: -"A long Estonian legal document to map defined terms ('edaspidi «X»') and § / lõige / punkt cross-references."New value: +"Whole Estonian legal document."
```
- removedInput schema / properties / text / title
```
Removed value: -"Text"
```
- removedInput schema / title
```
Removed value: -"check_defined_termsArguments"
```
- removedOutput schema / properties / cross_references / default
```
Removed value: -null
```
- removedOutput schema / properties / cross_references / items / additionalProperties
```
Removed value: -true
```
- removedOutput schema / properties / cross_references / title
```
Removed value: -"Cross References"
```
- removedOutput schema / properties / defined_terms / default
```
Removed value: -null
```
- removedOutput schema / properties / defined_terms / items / additionalProperties
```
Removed value: -true
```
- removedOutput schema / properties / defined_terms / title
```
Removed value: -"Defined Terms"
```
- 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: -"_DefinedTermsResult"
```
Addedv0.5.6Aug 23, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it warns that total_occurrences is exact-form and case-sensitive, includes the definition itself, and therefore misses inflected uses, and that cross-references are unvalidated. These are exactly the false-positive traps an agent needs to know before reporting results.

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?

One front-loaded sentence states the purpose, then each output field gets a tight clause explaining its semantics and caveat. No filler, and the caveats sit next to the fields they qualify.

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 one-input read-only analyzer with an output schema, the definition covers input expectations, each returned field, the counting semantics, and the reliability limit on issues and cross-references. Nothing an agent needs to call or interpret it is missing.

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 required parameter with 100% schema description coverage, so the baseline is 4. The description adds the meaningful constraint that the text must be a whole Estonian legal document, which the schema's one-line description also conveys.

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 verb and resource: mapping defined terms and cross-references in a long Estonian legal document, plus an issues check. That is concrete and distinguishable from morphological siblings like lemmatize or pos_tag, though it never contrasts with check_term_consistency, the closest neighbor.

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 by the domain (Estonian legal documents) and by the caution to 'verify a defined-but-unused issue before acting'. There is no explicit statement of when to pick this over check_term_consistency or check_domain_terms, leaving the agent to infer the boundary from names alone.

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