estonian-mcp

synonyms

Read-onlyIdempotent

Look up Estonian WordNet senses for a word to compare lemmas, definitions, and examples, so you can choose the term that fits your context.

Instructions

Estonian WordNet synsets for a word, one per sense, each with lemmas (the synonyms), any definition and any examples. synset_count is the total before max_synsets cuts the list.

For "is this the right word here?", read each definition against the context, not just lemmas. A gloss naming a medium, field or material limits where the word fits: korpus is "kirjaliku või suulise teksti elektrooniline kogu", so a set of images is not a korpus, while andmestik has no such limit. Register is a different question: check_officialese, classify_register.

Input Schema

Name	Required	Description	Default
`word`	Yes	One Estonian word in dictionary form, spelled as the dictionary spells it (kohv, not kohvi or Kohv).
`max_synsets`	No	Maximum number of word-sense synsets to return.

Output Schema

Name	Required	Description	Default
`synsets`	No
`synset_count`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.9.0Oct 24, 2026
- removedInput schema / properties / max_synsets / title
```
Removed value: -"Max Synsets"
```
- changedInput schema / properties / word / description
```
Previous value: -"A single Estonian word to look up WordNet synonyms for."New value: +"One Estonian word in dictionary form, spelled as the dictionary spells it (kohv, not kohvi or Kohv)."
```
- removedInput schema / properties / word / title
```
Removed value: -"Word"
```
- removedInput schema / title
```
Removed value: -"synonymsArguments"
```
- removedOutput schema / properties / synset_count / default
```
Removed value: -null
```
- removedOutput schema / properties / synset_count / title
```
Removed value: -"Synset Count"
```
- removedOutput schema / properties / synsets / default
```
Removed value: -null
```
- removedOutput schema / properties / synsets / items / additionalProperties
```
Removed value: -true
```
- removedOutput schema / properties / synsets / title
```
Removed value: -"Synsets"
```
- removedOutput schema / properties / word
```
Removed value: -{
-  "default": null,
-  "title": "Word",
-  "type": "string"
-}
```
- removedOutput schema / title
```
Removed value: -"_SynonymsResult"
```
First observedv0.2.4Jul 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world behavior, so safety is covered; the description adds the truncation contract (synset_count is the total before max_synsets cuts the list), which is genuinely new behavioral context. It also discloses that definitions and examples are optional ('any definition and any examples').

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

Conciseness4/5

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

Front-loaded with what is returned, then purpose, then semantics. The korpus/andmestik example is longer than strictly necessary but does concrete work by teaching how a gloss constrains usage, so it earns its place; register routing at the end is a tight pointer.

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?

With an output schema present the description need not enumerate return fields, yet it still explains their structure and the truncation counter. Two-parameter, read-only tool with nothing an agent needs left unstated.

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?

Schema coverage is 100%, so baseline is a 3, but the description adds meaning the schema lacks: it explains the relationship between max_synsets and the returned synset_count, which is the only non-obvious behavioral aspect of truncation. The word-form constraint is repeated from the schema rather than extended.

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?

Opening sentence names a specific resource (Estonian WordNet synsets), scopes it to one per sense, and enumerates the returned fields (lemmas, definition, examples). It does not explicitly differentiate itself from the closest sibling, find_related_words, but the 'synset per sense' framing is distinctive enough to separate it from morphological and related-word tools.

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?

It states the intended question ('is this the right word here?') and prescribes the method: read each definition against the context, not just lemmas. It also redirects register questions to check_officialese and classify_register, an explicit alternative routing. It stops short of saying when to prefer find_related_words instead.

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