estonian-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.7
Disambiguation5/5
Each tool targets a distinct linguistic task: morphological analysis, specific error checks (capitalization, compounds, hyphenation, numbers, object case, punctuation, redundancy), style/register, and lexical resources (synonyms, related words, paradigms). Even similar-seeming tools like check_compounds and check_compound_familiarity address different problems (split compounds vs. unfamiliar coinages). No ambiguity.
Naming Consistency4/5
Most heuristic checks follow a consistent `check_*` prefix (e.g., check_capitalization, check_compounds). Other tools use simple verbs or nouns (lemmatize, pos_tag, syllabify, tokenize). A few deviate (find_related_words, classify_register), but overall the pattern is clear and readable.
Tool Count4/5
21 tools is slightly above the ideal range, but each tool serves a specific function for comprehensive Estonian language processing. The scope covers morphology, syntax, style, and typography, justifying the count without feeling bloated.
Completeness4/5
The tool set covers a broad spectrum of Estonian language tasks: analysis, error detection, generation, lexical resources, and text statistics. Phase-1 limitations are acknowledged, but most common needs are addressed. Missing advanced features like dependency parsing are out of scope for this server's stated purpose.
Average 4.5/5 across 21 of 21 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 39 commits in the last 12 weeks
- Last stable release on August 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds character cap and output format beyond annotations; annotations already indicate read-only and idempotent.
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?
Three concise sentences: purpose, output format, input limit. No wasted words.
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?
For a simple one-parameter tool with output schema, description covers key aspects: output format and input limit.
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%; description adds character cap and output format but parameter meaning is already clear.
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?
Clearly states it returns lemma for each word, but does not differentiate from siblings like analyze_morphology or pos_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true and idempotentHint: true, establishing safety and idempotency. The description adds behavioral details: input capped at 100k characters, use of a fastText model, and the diagnostic (non-authoritative) nature of output, which go beyond the annotations.
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?
The description is well-structured: it front-loads the main purpose, then explains technical details, output interpretation, and limits. While slightly long, every section adds value, and there is no waste. A 4 reflects good clarity with minor room for trimming.
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?
Given the tool's complexity (fastText model, diagnostic logic), the description adequately covers how the tool works, how to interpret results, and limitations (legitimate OOV compounds). The presence of an output schema is noted, so the description doesn't need to detail return values. Score 4 reflects sufficient completeness.
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?
Only one parameter 'text' with schema description 'Estonian text whose compound nouns are checked for calque / translationese risk.' Schema coverage is 100%, so description adds minimal extra meaning beyond the schema. Baseline 3 is appropriate.
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 clearly states it is a 'fastText-based diagnostic for compound-noun familiarity in Estonian'. It specifies the key outputs (top fastText neighbours, top_score, neighbour_quality, is_suspect with reasons) and distinguishes this tool from siblings like check_compounds and analyze_morphology by focusing on calque-risk detection.
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?
The description provides explicit guidance on interpreting results ('semantically coherent neighbours mean the compound is fine; neighbours that recycle the input's morphemes or are junk tokens mean a likely coinage') and notes the tool is diagnostic. However, it does not explicitly compare to sibling tools or state when to use this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds the important constraint of a 100,000-character input limit and defines the POS tag set, which are behavioral details not covered by annotations.
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?
The description is two sentences: the first concisely states the purpose, and the second adds essential details (tag set and input limit) without waste. It is front-loaded and efficient.
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?
Given the tool's low complexity, one required parameter, and presence of an output schema, the description is complete. It covers purpose, input constraints, and tag set; output schema handles return values.
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?
The input schema provides 100% coverage of the single parameter with a clear description. The tool description does not add new parameter-specific semantics beyond the schema, so baseline 3 is appropriate.
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 clearly states the tool returns a part-of-speech tag for each word, providing a specific verb and resource. The POS tag set disambiguates from sibling tools like analyze_morphology or lemmatize, which handle different linguistic analyses.
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?
The description does not explicitly specify when to use this tool versus alternatives. It only describes the function, leaving the agent to infer suitability from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and idempotentHint; description adds the input character limit and return format (dict with sentences and words). No contradiction and useful behavioral context beyond annotations.
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?
Three concise sentences: purpose, return format, and input limitation. No fluff; each sentence serves a purpose.
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 simple single-parameter tokenizer, the description covers purpose, return structure (supported by output schema), and a practical constraint (100k chars). No missing critical information.
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%; the schema already describes the text parameter. The tool description essentially repeats that, providing no additional semantics or nuances.
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 clearly states the verb 'Split' and the resources 'Estonian text into sentences and words.' It distinguishes from 21 sibling tools like analyze_morphology or spell_check, which are more analytical or corrective.
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?
Implies usage for tokenization but offers no explicit when-to-use guidance or comparisons to siblings such as lemmatize or pos_tag. The 100,000 character cap is mentioned but not as a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, signaling a safe, read-only operation. The description adds further transparency by stating input is capped at 100,000 characters and that hits are high-confidence but absence does not confirm correctness. No contradiction with annotations.
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?
The description is concise and well-structured, with clear sections for purpose, examples, limitations, and input constraints. Every sentence adds value, and there is no redundant or vague wording.
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?
Given the tool's complexity (heuristic check with limited coverage), the description adequately communicates purpose, limitations, input cap, and confidence of results. An output schema exists (not shown), so return values do not need to be described. The description is sufficiently complete for an agent to select and use this tool correctly.
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% (only one parameter 'text' with a description). The description's mention of 'Estonian text' adds no new meaning beyond the schema. There are no extra details about format, encoding, or constraints, so baseline of 3 is appropriate.
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 clearly states the tool checks for wrong splits of Estonian compound words (liitsõnaõigekiri), provides concrete examples (e.g., 'kooli maja' → 'koolimaja'), and clarifies it is heuristic with a limited lexicon, distinguishing it from sibling tools like spell_check or check_hyphenation.
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?
The description explains when to use the tool (check for wrong splits) and notes its limitations (capped at 30 bigrams, not a full solver). It implies that for comprehensive compounding, other tools or methods are needed, but does not explicitly list alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the tool is safe. The description adds context on input character limit and output format, going beyond annotations to inform agent behavior.
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?
Two sentences, no extra words, front-loaded with purpose. Efficiently conveys all necessary information.
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 single-parameter NER tool with output schema present and annotations covering safety, the description fully covers input constraints, output structure, and tool purpose.
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% with a clear description of the 'text' parameter. The description adds value by specifying the output format and character limit, which are not in the schema.
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 clearly states it extracts named entities (PER/LOC/ORG) using EstNLTK's CRF model, with a specific verb and resource. It distinguishes from sibling tools like pos_tag or tokenize by focusing on entity extraction.
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?
The description implies use for Estonian text only but does not explicitly state when not to use or provide alternatives. Sibling tools exist for other linguistic tasks, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, and the description adds valuable behavior: it returns `issues` and `terms_of_art`, explains the kinds of detected legalese, emphasizes that legal terms must be kept verbatim, and discloses that the tool is heuristic with non-exhaustive lexicons. No contradiction with annotations.
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?
The description is concise, front-loaded with the main purpose, and structured around the two return types. The examples (`käesolev` → `see`) and caveats (`not exhaustive`, `precision-first`) earn their space without any wasted words.
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 single-parameter read-only tool with an output schema, the description is complete: purpose, outputs, safe usage, constraints, limitations, and unique terms-of-art behavior. The only minor gap is explicit comparison to sibling tools, but the behavior is described precisely enough that an agent can safely select and invoke it.
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?
The schema already fully describes the single `text` parameter, so the baseline is 3. The description still adds the useful 100,000-character input cap that is not encoded in the input schema, and the output definitions clarify what kinds of Estonian legal texts the parameter is expected to contain.
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?
The description clearly identifies the tool's job: analyze Estonian legal text and return both simplification suggestions and terms of art that must be preserved. It distinguishes the tool from other lingustic analyzers by its unique output structure, though it does not explicitly compare it to sibling tools like check_officialese or check_style.
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?
The description says the `terms_of_art` list should be used as a 'do-not-touch list while you simplify,' which is concrete and actionable. It implies when to use the tool (when simplifying Estonian legal text) and warns about the 100,000-character input cap, but it does not explicitly list when not to use it or which alternative sibling tool to prefer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral context: results are corpus-bounded, non-prescriptive, derived from an offline index, and gated on ESTNLTK_MCP_LEGAL_INDEX for the full corpus. This clearly tells the agent what kind of signal it is receiving and its limitations.
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?
The description is front-loaded with the core purpose and uses concrete examples effectively. The final 'Input is a single word' is helpful but redundant given the schema, and a slightly tighter version would be possible without losing value.
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?
Given the single parameter, available annotations, and existing output schema, the description covers everything needed: what the tool returns, how it behaves, its limitations, its intended role, and how the corpus index is configured. There are no meaningful gaps for an agent to misuse this tool.
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?
The input schema already fully documents the 'word' parameter with examples and coverage at 100%, so the baseline is appropriate. The description reinforces 'Input is a single word' and supplies examples, but it does not add substantive semantic details beyond what the schema already provides.
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 clearly identifies the tool as returning canonical legal collocations for a term, with an explicit mechanism: term frequency plus neighboring words in Estonian legal text. Concrete examples ('hagi' → 'esitama hagi') anchor the meaning and make it easy to distinguish from siblings like synonyms or related words.
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?
The description states when to use the tool: when the AI needs real, idiomatic legalese rather than invented collocations. It also gives important caveats about the corpus being proof-of-concept and not prescriptive, but it does not explicitly name alternatives or say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds significant behavioral context: it uses Vabamorf POS+form analysis, heuristic scope (phase-1, only 'Y' tags), character limit (100k), and limitations (custom acronyms not flagged). No contradictions.
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?
Every sentence is informative and earns its place. The description is front-loaded with the rule, examples, mechanism, limitations, and a scope note. No redundancy or filler.
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 single-parameter tool with a limited scope (specific hyphenation check), the description provides sufficient context: what it checks, how it works, limitations, and input constraints. An output schema exists but is not shown; the description does not need to cover return values.
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?
The schema already fully describes the single parameter 'text' (100% coverage). The description adds an example of input text but no additional syntax or constraints beyond the character limit, meeting the baseline.
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 clearly states it performs a heuristic check for a specific Estonian rule (case-ending hyphenation on abbreviations), provides concrete examples (MCPst -> MCP-st), and distinguishes from sibling tools by targeting a particular error type.
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?
The description gives clear context on when to use (checking abbreviation hyphenation) and what it covers (Vabamorf-tagged abbreviations), but does not explicitly state when not to use or name alternatives, though siblings are available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, so the tool is safe and idempotent. The description adds significant behavioral details beyond annotations: it's a lexicon-based heuristic (not full EÕS), it ignores sentence-initial capitalization and all-caps acronyms, it returns issues with specific fields (rule code, Estonian label, explanation, correction), and it notes a Phase-1 limitation. This fully informs the agent about behavior.
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?
The description is concise and well-structured: a clear header statement, bullet-like list of error types, clarifications on what is ignored, return format, input limit, and limitations. Every sentence adds value. No redundant or filler content.
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?
Given the tool's complexity (Estonian capitalization rules), the description is comprehensive. It covers input constraints (Estonian text, 100k char limit), output structure (rule code, Estonian label, explanation, correction), handling of special cases (sentence-initial, all-caps), and limitations (heuristic, not full EÕS, other checks exist). An output schema exists, so return values are documented elsewhere. The description is complete for agent usage.
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?
The single parameter 'text' is described in the schema as 'Estonian text to check for capitalization errors (Algustäheortograafia).' Schema coverage is 100%, so baseline is 3. The description does add some context about what the checker does, but the schema already conveys the required purpose. No additional semantic details beyond the schema are provided.
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 clearly states the tool's purpose as an Estonian capitalization checker (Algustäheortograafia), lists specific error types it detects (weekday, month, nationality names, country/language adjectives), and distinguishes itself from sibling tools by explicitly stating what it does not cover (compounds, punctuation, hyphenation). The verb 'scans' and resource 'Estonian text' provide a specific, actionable purpose.
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?
The description provides context for when to use the tool: for checking Estonian text for AI-generated capitalization errors per EKI's Reeglid. It mentions input character limit (100,000) and that the tool is a heuristic, implying it's for quick checks. It also mentions that compound, punctuation, and hyphenation checks are separate tools, giving guidance on alternatives. However, it doesn't explicitly state when not to use it or provide a clear 'use case' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing heuristic nature, phase-1 limitations, lack of syntactic parser, skipping of proper nouns, and 100,000 character input cap. No contradiction with annotations (readOnlyHint, idempotentHint).
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?
Well-structured with bullet points explaining two rules and a limitations section. Every sentence adds value; front-loaded with purpose.
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?
Given the complexity (heuristic rules), existing annotations, and presence of output schema, the description is complete. It covers rules, limitations, and input constraints without needing to detail return values.
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% with a clear parameter description. The tool description adds context about Estonian text but does not provide additional semantics beyond what the schema already states.
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 clearly states it is a 'Heuristic Estonian object-case-government check' that catches direct object case errors after negation or partitive-governing verbs. This specific verb+resource+scope distinguishes it from siblings like spell_check or check_compounds.
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?
The description explains limitations (no syntactic parser, false positives possible) and advises to 'Treat hits as "worth a second look", not authoritative'. It implies use for Estonian text but does not explicitly state when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description richly discloses behavioral nuances: the tool does not choose a 'correct' variant, it returns groups with counts and dominant variant, it degrades when WordNet is missing, and it sets `degraded: true` and adjusts `rules_run`. It also warns the user against misinterpreting an empty result from a degraded run. This is far more contextual than typical.
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?
The description is well-structured: hook, example, two bulleted rules, output semantics, a warning about degraded mode, followed by a known gap and a capacity note. Every section earns its place; the scannable formatting helps an agent quickly locate the critical 'check degraded before trusting an empty result' warning.
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?
The description is complete for a read-only analysis tool. It explains what the output contains (variant groups, counts, dominant term), what can go wrong (degraded runs, known gaps), and what the tool deliberately does not do (deciding correctness). The presence of an output schema further reduces the need to document return value details.
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?
The schema already has 100% coverage for the single `text` parameter, so the description need not repeat its meaning. It does not add new parameter-specific details other than the 100,000-character cap, which is more of a global behavior than a parameter semantic. Baseline 3 is appropriate.
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 clear, specific action: 'Flag a document that calls the same thing several different names.' It then elaborates with concrete rules (`shared-compound-head`, `shared-wordnet-synset`) and a concrete example, making the tool's purpose unmistakable and distinct from sibling checking 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?
The description gives clear context for when the tool is valuable — long documents where paragraph-by-paragraph editing misses term drift — and explicitly tells agents to check `degraded` before trusting empty results. It does not explicitly name alternative tools or state 'don't use when X', but it is clear enough about the intended scenario and limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds output format details and input restrictions (capped length, no whitespace), providing full behavioral disclosure.
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?
Three concise sentences front-load purpose, then output format, then constraints. No wasted words; efficient and structured.
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?
Given a single parameter, clear output format in description, and simple use case, the description is fully complete for correct invocation.
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% with parameter 'word' already described. The description repeats the constraint but adds no new semantics, so baseline 3 is appropriate.
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?
Description clearly states the action ('Split a single Estonian word into syllables') and the result ('with quantity and accent'), distinguishing it from siblings like 'tokenize' or 'lemmatize'.
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?
Input constraints (200 chars, no whitespace) are specified. While explicit when-to-use vs alternatives is absent, the linguistic task is narrowly defined, and siblings cover different operations, making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as readOnly and idempotent. The description adds substantial behavioral context beyond that: default first-analysis behavior, ambiguity count and flag, usage_note codes, Estonian rendering guidance, indeclinable classification, and the input character cap. There is no contradiction with annotations.
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?
The description is long but effectively structured: a lead statement, a default-vs-all_analyses clarification, a bulleted output-field list, and a targeted usage warning. It could be folded slightly, but the length is justified because most of the parameter and output semantics are not otherwise fully outlined in the visible schema.
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 two-parameter analyzer with an output schema, the description is complete. It covers input restrictions (100k chars), output fields and their semantics, machine vs human-readable usage notes, and a caveat about indeclinables that affects downstream inflection. An agent has enough information to call it correctly and reason recursively about its output.
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 both text and all_analyses are already documented. The description improves on this by clarifying default behavior ('By default returns the first most likely analysis'), the meaning of True for all_analyses, the 100,000-character input cap, and practical output semantics tied to the boolean parameter.
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 resource: 'Run full morphological analysis on Estonian text.' It then enumerates exactly what is returned (lemma, part-of-speech, grammatical form, root, ending, clitic, compound parts, ambiguity, usage flags), which clearly distinguishes it from narrower siblings like lemmatize or pos_tag.
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?
The description clearly conveys when to use the tool: when full morphological analysis is needed, with a default single analysis and an optional all_analyses mode. It also gives application guidance around indeclinable words and inflection. It does not explicitly compare against sibling tools like lemmatize or spell_check, so it stops one step 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds significant behavioral context: it is heuristic, flags only clear-cut cases, has phase-1 limitations, and caps input at 100,000 characters. No contradictions with annotations.
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?
The description is well-structured with bullet points and clear sections, each sentence adding value. It is appropriately sized for the complexity of the tool, though slightly verbose in explaining limitations.
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?
Given the presence of an output schema, the description provides complete context about input, checked cases, skipped cases, and input constraints, leaving no ambiguity for an AI agent.
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% with a single 'text' parameter described. The description adds meaning beyond the schema by detailing what the tool checks within the text and its limitations, providing richer context for parameter usage.
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 clearly states it is a heuristic Estonian number-writing check that flags two specific cases: decimal comma vs period and thousands space vs comma. It distinguishes itself from sibling tools like spell_check by focusing specifically on number formatting conventions.
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?
The description explains when to use it (for Estonian text number formatting) and explicitly mentions what it intentionally does not handle (spell-out-vs-digits guidance) due to false positive concerns, providing helpful exclusion criteria. However, it does not explicitly contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds substantial behavioral context beyond annotations: inflections crowding results, antonyms appearing, polysemy not disambiguated, single-word input, and 200-character cap. This fully discloses behavior.
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?
The description is well-structured with paragraphs and bullet points, but it is somewhat verbose (multiple paragraphs with known quirks). It front-loads purpose and usage, but some details could be more concise. Still, it earns its length due to informativeness.
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?
Given the complexity of the tool (embedding model quirks, domain-specific Estonian), the description is complete. It covers purpose, usage, limitations, and behavioral quirks. The output schema exists, so return values are not needed in the description.
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%, so the schema already documents both parameters with descriptions. The description does not add extra meaning beyond what the schema provides, so baseline 3 is appropriate.
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 clearly states it finds Estonian words semantically similar via fastText, with specific verb 'find' and resource 'related words'. It distinguishes from sibling 'synonyms' by explaining the difference between fastText similarity and WordNet synonyms.
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 describes when to use (breaking repetition, finding alternative phrasings, expanding vocabulary) and when not (when exact synonyms are needed), and contrasts with the 'synonyms' tool. Provides clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true, idempotentHint=true), the description adds genuinely valuable behaviors: implementation details like 'Regex-based', privacy claims 'PII-free (nothing is stored)', the raised 500,000-character input cap, and the fact that the echoed `text` is truncated to a 2,000-character preview. These are exactly the behavioral traits the agent needs to know and that the annotations do not provide.
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?
The description is front-loaded with a one-line scoping summary, followed by the extraction/flagging behavior and then operational constraints (regex, PII, size caps). Every sentence carries information — no filler or restatement of the tool name — and it is compact relative to the amount of useful behavior it conveys.
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?
The tool has one parameter, a fully populated input schema, a partial output schema (so return values need not be spelled out), and safe annotations. The description covers what is analyzed, what kinds of errors are flagged, input scale limits, privacy, and echo truncation behavior — nothing an agent needs to decide whether and how to invoke this tool 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?
Schema description coverage is 100%, so the baseline is 3; the description adds parameter-relevant semantics beyond the schema by disclosing the 500,000-character input cap (telling the agent it can pass an entire document in one call) and the 2,000-character echo truncation (reducing concern about huge responses). It does not rehash the schema, but enriches it with practical size constraints.
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 states a specific verb and resource structure: 'extracts every term defined with `(edaspidi «X»)`', 'counts how often each is actually used', 'lists § / lõige / punkt / artiklom cross-references', and 'flags defined-but-unused or doubly-defined terms'. The opening line, 'Structural map of a long Estonian legal document', crystallizes the scope and differentiates it from sisters like tokenize, spell_check, and même check_term_consistency.
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?
Clear context exists for when to use: analysis of long Estonian legal documents/contracts, with 'Input cap is raised to 500,000 characters so a whole contract fits in one call' reinforcing the intended whole-document use case. There is a clear context, but no explicit exclusions or named alternatives, so the closely related sibling check_term_consistency is never addressed, which prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, and the description adds rich behavioral detail: no-orphan-edge rule, phase-1 limitation (pure syllable-boundary based), compound-boundary preference not applied, input constraints (single word, no whitespace, 200 chars). No contradictions.
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?
The description is concise with no fluff: a clear opening, effective sibling comparison, behavioral rules, and limitations. Every sentence is necessary and well-organized.
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?
Given low complexity (1 required param), presence of output schema, and thorough coverage of input constraints, behavioral traits, and sibling differentiation, the description is complete for an AI agent to correctly invoke the tool.
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?
The sole parameter 'word' is fully described in the schema (100% coverage). The description adds value by specifying the 200-character cap, which is not in the schema, and reinforces the Estonian language and no-whitespace constraint.
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 clearly states it returns safe line-break positions for an Estonian word, using the specific verb 'return' and resource 'line-break positions'. It distinguishes itself from the sibling 'syllabify' by noting the phonological vs. typesetting purpose.
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?
The description explicitly compares with 'syllabify' and explains when to use this tool (for character offsets for typesetting) vs. the other tool (phonological syllable boundaries). It provides constraints like no-orphan-edge rule and limitations, but does not exhaustively list all alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds detailed behavioral context: heuristic nature, single-rule coverage, list of included/excluded conjunctions, and input character limit. This fully informs the agent of the tool's capabilities and constraints.
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?
The description is well-structured: a succinct headline, followed by a list of conjunctions and limitations. Every sentence adds value, and the information is front-loaded. No redundant text.
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?
Given the tool's specific focus and the presence of an output schema, the description is complete. It covers the rule, exceptions, limitations, and input restrictions, providing sufficient context for correct use.
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% with a clear parameter description. The tool description adds extra context about the conjunctions and exclusions, enhancing understanding beyond the schema. A score of 4 reflects this added value.
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 clearly states the tool's purpose: 'Heuristic Estonian punctuation check — comma-before-clause rule.' It specifies the exact rule and lists the conjunctions covered, distinguishing it from sibling linguistic tools that handle morphology, spelling, etc.
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?
The description provides clear context on when to use the tool (for checking Estonian comma-before-clause rule) and what is excluded (other punctuation rules, specific conjunctions). It mentions phase-1 limitations and input cap. However, it doesn't explicitly state when not to use or suggest alternative sibling tools for other punctuation tasks, though none exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing heuristic rules (phase-1, high-precision), specific patterns checked, and the conservative design. It also discloses input limitations (100k chars) and that absence of flags does not guarantee tight prose, adding valuable behavioral context not captured in readOnlyHint or idempotentHint.
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?
The description is well-structured with bullet points and clear categories, making it easy to scan. Every sentence provides essential information without unnecessary verbosity, including examples and limitations.
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?
Given the presence of an output schema (not shown but noted), the description covers all necessary aspects: purpose, specific rules, conservative design, input constraints, and what results mean. It is comprehensive for the tool's complexity.
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?
The sole parameter 'text' has a clear description in the schema ('Estonian text to check for pleonasm / redundant word pairs'), which is consistent with the tool's purpose. The main description provides additional context about what the check looks for, but the schema already covers 100% of parameters, so the added value is moderate.
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 clearly states the tool checks Estonian pleonasm/semantic-doubling, provides specific examples (doubled 'also' particles, double superlative, fixed pleonasm phrases), and distinguishes itself from sibling tools like spell_check by focusing on a specific class of AI-produced redundancy.
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?
The description explains it is conservative and high-precision, noting that absence of flags is not proof of tight prose, which guides appropriate use. It mentions the input cap of 100,000 characters. However, it does not explicitly compare with sibling tools or provide when-not-to-use scenarios, missing some contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains each metric's behavior (lemma-aware repetition, passive voice ratio with threshold, sentence length stats, hedging word list) and discloses phase-1 limitations (heuristic only, no cliché detection, input cap). Annotations confirm readOnly and idempotent, and the description adds valuable context beyond annotations.
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?
The description is well-structured: a clear purpose, followed by a bullet list of metrics with precise behavioral details, then limitations. Every sentence adds value, and it is appropriately sized for the tool's complexity.
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?
Given the simple input schema (single required parameter) and the existence of an output schema, the description covers everything needed: metric definitions, behavioral details, limitations, and input constraints. It is fully complete for an AI agent to use correctly.
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?
Only one parameter 'text' with schema coverage 100%. The description adds value by specifying the text must be Estonian and capped at 100k characters, and explains what metrics will be computed, enhancing understanding beyond the schema description.
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 clearly states the tool provides 'Heuristic Estonian style metrics for newsletter / ad / email copy' and lists four specific metrics (repetition, passive_voice, sentence_length, hedging). It distinguishes itself from sibling tools like spell_check or pos_tag by focusing on style analysis.
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?
The description says it is for 'newsletter / ad / email copy' and lists the metrics, implying when to use it. However, it does not explicitly state when not to use it or mention alternatives, though sibling tools provide context for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly, idempotent, and openWorld annotations, the description discloses critical behavior: exactly what forms are produced, the ambiguity handling with `paradigm_key` and `other_paradigms`, the use of Vabamorf form codes, and Phase-1 scope restrictions. This gives an agent a rich and accurate model of what the tool will and won't do.
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?
The description is lengthy but every paragraph serves a purpose, and the core purpose is front-loaded in the first sentence. It uses readable paragraph breaks to cover the main behavior, ambiguity, and usage constraints without redundancy.
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?
Given the combinatorial complexity of Estonian inflection and multiple word classes, the description is complete enough for an agent to use the tool correctly. It covers ambiguous lemmas, forms structure, Estonian labels, input disambiguation, scope limits, and output guidance, with an output schema also present for the rest.
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?
The schema already documents the single `word` parameter at 100% coverage, so the baseline is 3. The description adds valuable usage nuance: passing an inflected form instead of a bare lemma selects the exact paradigm, and input is capped at 200 characters. This goes beyond the schema without overcomplicating it.
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 'Generate the full inflection paradigm for an Estonian word', giving a clear verb, resource, and scope. It further distinguishes nominal versus verb paradigms and is easily differentiated from sibling tools like analyze_morphology and lemmatize, which do analytical rather than paradigm-generation work.
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?
The description gives strong usage context: which parts of speech inflect, that non-inflecting words return empty `forms`, and that inflected lemmas should be passed to disambiguate. It does not explicitly name alternatives or say when not to use the tool relative to sibling tools, but the practical guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by stating the tool is heuristic and precision-first, that absence of flags does not prove plain language, and by detailing counting rules for each metric (e.g., negated impersonals included, attributive -tud participles excluded). It also discloses the 100,000-character input cap.
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?
The description is front-loaded with the core purpose, then a short sibling-disambiguation, then bulleted metric details. Every sentence and bullet adds distinct value; the structure makes a sizable amount of information easy to scan.
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?
Given the tool's combinatorial and metric-rich output, the description is remarkably complete: it enumerates the issue field structure, each computed metric with its interpretation, examples of filler substitutions, caveats, and the input limit. The presence of an output schema reduces pressure to describe return values, but the description still covers them.
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?
The schema already fully describes the single text parameter, so the baseline is high. The description adds further useful semantics by emphasizing non-legal prose, explaining the sibling exclusion, and stating the character limit, which are not visible in the schema.
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 resource: 'Flag Estonian kantseliit in reports, academic and business prose.' It later names the sibling tool check_legalese and explicitly distinguishes it, making its identity unmistakable.
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?
It gives explicit when-to-use guidance: use this tool for anything that is not a statute or contract, and explains why check_legalese would fail there due to its legal-tuned lexicon and length gate. This is a clear condition plus a concrete alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses the heuristic nature, limitations, return fields, score range, the role of syntactic signals, and the 100,000-character input cap. It even explains that a score of 'neutral' is common for newsletter prose, which is exactly the behavioral nuance an agent needs.
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?
The description is longer than most, but each paragraph earns its place: purpose, outputs, use cases, limitations, and alternative routing. The only minor inefficiency is the denseness of the `structure` sentence; still, it is an effective and organized front-loaded definition.
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-parameter read-only heuristic classifier, this description is effectively complete. It explains the output semantics, score bounds, limitation, pointer to check_overwrite, and input cap. No output schema exists, but the description gives enough on returns that an agent can understand them without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter and 100% schema description coverage, the schema already covers what `text` is. The description raises semantics by specifying the 100,000-character cap, the Estonian-only expectation, and the lexical scope (legal-administrative and academic/report vocabulary). The mention of `structure` is a slight oddity as it is not a schema parameter, but it reads as an internal behavior note rather than an input directive.
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 opening sentence states the exact function: 'Heuristic register classifier for Estonian (formal vs colloquial)', which is a specific verb+resource pair. It also lists the concrete outputs (tier, score, markers), and the later note referencing check_officialese distinguishes it from the most similar sibling.
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?
The description explicitly says when the tool is useful: sanity-checking marketing copy and contract drafts. It also gives a strong when-not and alternative: 'Use the result as a directional hint, not a verdict; for a full kantseliit breakdown with per-issue suggestions, call check_officialese.' Input cap and neutral-score limitation further shape safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool accepts any morphologically well-formed word including invented compounds, which is a key behavioral trait not covered by annotations (readOnlyHint, idempotentHint). No contradiction with annotations.
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?
Description is concise, front-loaded with purpose, then output format, input limit, and critical caveat, with no wasted words.
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?
Given annotations (readOnly, idempotent) and output schema existence, the description fully explains output format, input constraints, and caveats, and references an appropriate sibling tool for further verification.
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 covers both parameters with basic descriptions; the tool description adds value by specifying the character limit and the effect of the suggestions parameter on output, providing context beyond the schema.
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?
Description clearly states it checks Estonian spelling per word with optional suggestions, and distinguishes from sibling tools like check_compound_familiarity by noting its limitations for coined compounds.
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 explains when to use (Estonian spell-check) and when not to rely solely (for unusual compounds) by directing to check_compound_familiarity, and notes the 100,000 character input limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses important behaviors: polysemous words return multiple synsets, word-sense ambiguity is preserved, input is capped at 200 characters, and glosses may carry domain constraints that affect interpretation. These add real value over the annotations alone.
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?
The description is long but every section earns its place: the core purpose is front-loaded, the return type is explained, use cases are concrete, and the word-fit warning directly impacts how an agent should interpret results. No filler or repetition of the schema fields.
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 two-parameter tool with an output schema and helpful annotations, the description provides complete operational context: how results are structured, how to reason through the results, what constraints apply, and which sibling tools to use instead. An agent can correctly select and invoke this tool without additional information.
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% and both parameters are already described adequately. The description adds extra semantics not present in the schema, such as the 200-character input cap and the fact that max_synsets limits the number of word-sense synsets. This goes beyond baseline, but the schema still carries most of the parameter meaning.
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-object pair ('Look up Estonian synonyms via WordNet') and defines the return type (synsets with definitions and example usages). It also differentiates itself from nearby sibling tools by referencing WordNet and by directing register-related questions to check_officialese and classify_register.
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?
The description gives explicit when-to-use guidance: picking a different word with the same meaning, e.g., swapping an overused verb. It also gives a detailed when-not-to-use rule—for 'is this the right word here?' questions it instructs reading and testing definitions against user context, and for register issues it points to sibling tools check_officialese and classify_register.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![estonian-mcp MCP server](https://glama.ai/mcp/servers/silly-geese/estonian-mcp/badges/card.svg)](https://glama.ai/mcp/servers/silly-geese/estonian-mcp)

Score Badge

Copy to your README.md:

[![estonian-mcp MCP server](https://glama.ai/mcp/servers/silly-geese/estonian-mcp/badges/score.svg)](https://glama.ai/mcp/servers/silly-geese/estonian-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/silly-geese/estonian-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server