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

Annotations already cover read-only/idempotent/closed-world, and the description adds real semantic context: what 'form' codes mean ("" if uninflected, "0" = none), that `_` joins compound parts, that `analyses_count` >1 signals residual ambiguity, and practical guidance that `indeclinable` should be checked before declining a noun phrase. This is genuine behavioral value rather than a restatement of annotations.

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

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

Front-loaded with the purpose sentence, which is good, but the bulk is a dense catalogue of output fields that largely duplicates the existing output schema. Every sentence is informative in isolation, yet the overall proportion of redundant return-value detail is high.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An agent can tell what the tool returns in detail, but with an output schema already present that detail is partly wasted, and nothing addresses input behavior, output size, or how this differs from the many sibling analysis tools. Adequate but with clear gaps for a tool in a 27-sibling family.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters (text, all_analyses) are documented in the schema. The description mentions ambiguity and analyses_count but never explains the `text` input or the `all_analyses` toggle, so it adds nothing beyond the schema baseline.

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

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

States a specific verb+resource ('morphological analysis of each word') and enumerates the per-word fields produced, so an agent knows this is a full morphological parse rather than a tokenizer or tagger. It does not name or distinguish itself from close siblings like pos_tag, lemmatize, or paradigm, leaving the superset relationship to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit statement of when to call this instead of pos_tag, lemmatize, or paradigm, and no prerequisites or exclusions. The only implicit cue is that the field list overlaps those narrower tools, which the agent must infer on its own.

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

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

Annotations already declare readOnlyHint, idempotentHint and a closed world, and an output schema exists, so the safety and return-surface burden is largely pre-carried. The description adds genuine behavioral context by enumerating the non-flagging cases and the extra stem-vowel and Roman-ordinal rules, which no structured field conveys.

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

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

Three sentences, front-loaded with the flagging rule and its examples, then exceptions, then scope boundaries — each block earns its place. It is dense with examples and secondary rules but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter checker with an output schema and full annotation coverage, the description supplies the rule semantics an agent needs to interpret and trust the results. The only gap is that it never clarifies its division of labour with the sibling check_hyphenation, which matters given both exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter, 'text', with 100% schema description coverage, so the schema already tells the agent what to pass. The description adds no constraint on language, length, or expected input form beyond noting the examples are Estonian, leaving this at the baseline.

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

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

The description states a specific rule-based check with three worked examples (OÜle → OÜ-le, ÜROlt → ÜRO-lt, THIl → THI-l), so an agent knows exactly what pattern is being flagged. It does not, however, distinguish itself from the sibling check_hyphenation, which an agent could reasonably assume covers the same ground.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong positive and negative scoping: hyphenless forms like ELi, APIga, MCPst are explicitly declared correct and not flagged, and mixed-case stems and chloride formulas are excluded. What it lacks is any routing guidance against the alternative hyphenation/compounds checks that sit among the siblings.

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

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

Annotations already cover safety (readOnlyHint=true, idempotentHint=true, openWorldHint=false), so the bar is lower, yet the description adds real behavioral detail the annotations can't: which categories are suppressed (sentence-initial, all-caps acronyms) and which hits are likely false positives (line/list/quotation openers, proper names like Eesti Keele Instituut). That false-positive guidance is exactly what prevents an agent from over-reporting.

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

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

Front-loaded with the core action, then bulleted category rules with parenthetical examples, then a compact caveat block. Every sentence carries information (category definition, exception, or false-positive warning); no filler or restatement of the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is unnecessary; the description instead supplies the decision logic an agent needs — what counts as a hit, what is skipped, and when a hit should be ignored. Combined with the readOnly/idempotent annotations, nothing material is missing for correct invocation and interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

One parameter with 100% schema description coverage ('Estonian text.'), so the schema carries the parameter burden and baseline 3 applies. The description adds only implicit confirmation that input is Estonian prose subject to capitalization rules; it says nothing about handling markdown, HTML, mixed-language spans, or multi-paragraph input.

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

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

States a specific verb and resource ('Flags words wrongly capitalized mid-sentence') plus the Estonian orthography term, and immediately enumerates the exact categories it covers (weekday, month, nationality, language-adjective). It also explicitly excludes the sibling's territory ('English title case in headings is check_translationese's `title-case`'), so an agent can distinguish it from the 28 siblings without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear inclusion rules with examples (esmaspäeval, jaanuaris, eestlane) and explicit exclusions: sentence-initial words and all-caps acronyms are skipped, and line/list/quotation openers or proper names are 'usually false'. It routes one adjacent case to check_translationese. It doesn't state input-language prerequisites beyond the schema's 'Estonian text', but the when-to-use boundary is essentially complete.

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

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

Beyond the readOnly/idempotent annotations, it discloses the three attestation sources, the deliberate low recall, the narrow definition of `is_suspect` with the 0.55 threshold, the `signal: "none"` junk-neighbour case, and the crucial false-positive caveat that unattested is normal for specialist words. This is exactly the context annotations cannot carry.

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

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

Front-loads the purpose, then the core result interpretation, then edge cases — good ordering with no filler prose. It is dense and somewhat long for one parameter, but nearly every sentence carries decision-relevant information (thresholds, field names, fallbacks).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 needn't enumerate return values, yet it explains the key result fields (`attested`, `is_suspect`, `neighbours`, `neighbour_quality.signal`, `in_domain_glossary`) and their interpretation. Nothing an agent needs in order to call and interpret this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter with 100% schema description coverage, so the schema already documents `text`. The description adds no syntax, format or length guidance for the input, so it neither helps nor hurts — baseline 3.

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

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

Opens with a specific verb+resource: an attestation check for Estonian compound nouns, and immediately narrows scope ('use it on compounds you coined'), which separates it from sibling check_compounds and check_domain_terms. An agent can distinguish it from every listed sibling without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it (coined compounds), how to read the result ('Read `attested` first', 'Judge a flag from `neighbours`'), and names alternatives with their conditions (check_domain_terms for your own glossary, check_officialese for register). Also states exclusions: proper nouns are skipped.

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

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

Annotations already establish readOnly, idempotent, and closed-world behavior, so the bar is lower. The description still adds genuinely useful behavioral context the annotations cannot convey: an approximate 30-item curated list, high precision on hits, and likely false negatives otherwise.

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

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

Two sentences, zero filler: the purpose and example come first, and the coverage caveat follows where it is needed. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only checker with an output schema and rich annotations, the description covers what the tool does, what it returns conceptually, and its main limitation. Nothing an agent needs to call it correctly or interpret a null result is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single required parameter and it is already documented as 'Estonian text.' A bonus is that the description's worked example clarifies the expected unit of input (word/compound pair in context) rather than just a language tag, reinforcing the schema without contradicting it.

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

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

The description states a specific verb and resource ('Flags compounds wrongly written as two words'), gives the Estonian term, and shows a concrete input→output example (`kooli maja` → `koolimaja`). It does not explicitly contrast itself with the nearby `check_compound_familiarity` sibling, so it stops just short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence sets expectations for when results are trustworthy: a hit is reliable, but 'most compounds are not covered', which tells the agent how to interpret and when not to rely on a clean pass. There is no explicit routing to an alternative tool for broader coverage, so it is clear context rather than full when/when-not guidance.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnly/idempotent/closed-world, so safety is covered; the description goes well beyond them. It discloses the crucial caveat that a reported compound is not necessarily coined and may be ordinary Estonian (with a concrete example), that suggestions are spelling-similar rather than synonymous, what contains_glossary_term means, that proper nouns are skipped, and that the hosted server holds no glossary.

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

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

Purpose is front-loaded and nearly every sentence adds distinct information: definitions, caveats, the suggestions warning, the glossary requirement, and the proper-noun exception. It is dense and the opening sentence's clause order makes it harder to parse than necessary, but there is no filler to cut.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and the description still covers the interpretive burden: what a hit means, what it does not mean, how to act on it, and the configuration dependency on a supplied glossary. Nothing an agent needs in order to call this correctly and interpret results is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds operational meaning the schema does not: the server has no glossary, so the caller must supply one via `glossary`, and absent it the result degrades to a pure unattested list. It also clarifies how `suggestions` (driven by suggest_cutoff) should be read — spelled alike, not synonymous — which changes how the agent interprets that parameter's effect.

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

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

The first sentence names a specific verb and resource: it reports Estonian compounds that no lexicon or domain glossary vouches for, in text about an organisation's own systems. It also points at the related sibling check_compound_familiarity, so the agent can separate attestation checking from glossary comparison. The phrasing is convoluted ('compounds no lexicon or domain glossary vouches for, in Estonian you wrote about...'), which slows first-pass comprehension, but the substance is specific rather than tautological.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states when to act and when not to: where the compound names something the organisation has a term or identifier for, use theirs; otherwise leave it. It also explicitly warns that without a glossary this is only the unattested list and 'never on its own a reason to rewrite', which is a clear negative condition. Alternatives are named (check_compound_familiarity) and the glossary-passing requirement is spelled out.

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

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

Annotations already cover safety (readOnly, idempotent, closed-world), and the description goes further by disclosing the shape and constraints of the result: offsets kept at least 2 characters from either end, compound seams present but not flagged, and a caution about breaks that split a vowel residue. The maao-manik example is garbled enough that the exclusion rule is harder to apply than intended, keeping this from a 5.

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

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

The scope statement and both return fields are front-loaded, and every sentence carries information. The nested parenthetical examples make the middle dense, but nothing is plainly padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations covering safety and an output schema covering return shape, the description still supplies the interpretive guidance an agent needs to decide which breaks matter and to not expect a flagged compound seam. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema coverage ('One Estonian word, no whitespace'), so the schema already carries the semantics. The description adds nothing new about the parameter itself, so the baseline 3 applies.

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

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

States a specific verb+resource ('line-break positions in one Estonian word') and names the native term poolitamine, which makes it unambiguous against siblings like syllabify or check_abbreviation_hyphenation. An agent can tell what this returns without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly scopes usage ('use only when line breaks matter'), which effectively excludes general-purpose calls. It does not name a sibling alternative (e.g., syllabify) the way a 5 would, so the routing is clear but not fully disambiguated.

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

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

Annotations already carry readOnly/idempotent/closed-world, and the description adds genuinely useful recall caveats beyond them: the lexicons are starters, an empty or short issues list does not mean the text is plain, and an unlisted word can still be a term of art. That false-negative warning is exactly the kind of behavioral context an agent needs before trusting a clean result. The one ambiguity is whether the tool returns rewrites or merely flags them — "rewrites must keep the legal meaning" could be read either way.

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

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

Very dense and front-loaded: domain, output categories, caveats, then the sibling pointer, in four compact clauses. The telegraphic "issues:" / "terms_of_art:" fragment style is efficient but slightly harder to parse than full sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 needn't document return values, and it still summarizes both result lists plus their reliability limits. Combined with 100% parameter coverage and full annotations, an agent has nearly everything needed; only the flag-vs-rewrite question remains open.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter with 100% schema description coverage that already says "Estonian statute or contract text." The description restates the same domain constraint but adds no syntax, length, or formatting detail beyond the schema, so the baseline 3 applies.

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

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

States the specific resource (Estonian statutes and contracts), the function (plain-language aid / legalese detection), and enumerates the two result categories: issues (archaic filler, stock phrases, over-long or comma-heavy sentences) and terms_of_art to keep verbatim. It also names the sibling it is not (check_officialese), so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"For reports and business prose use check_officialese" gives an explicit alternative with the selecting condition, and "rewrites must keep the legal meaning" frames the constraint under which results should be applied. It stops short of stating exclusions such as non-Estonian input, but the domain scoping largely covers that.

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

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

Annotations already establish readOnly/idempotent/closed-world, and the description goes well beyond them: per-rule false-positive exclusions, the note that typeset mõttekriips is out of scope, and the disclosure that `suggestion` returns plain spaces where non-breaking spaces are ideal. That last point is genuinely useful output nuance; only the overall response shape is left to the output schema.

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

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

Front-loaded with a one-line purpose, then a scannable bullet per rule with arrow examples — dense but each line carries rule, conversion, and exceptions. The bullets are long and exception-heavy (the range-spacing bullet alone carries five skip categories), which is justified for a linter but borders on spec-dumping.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only linter with an output schema, the description supplies everything an agent needs: what counts as a violation per category, what is deliberately not flagged, and that suggestions may be imperfect on whitespace. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

One required parameter with 100% schema coverage ('Estonian text'). The description reinforces the input domain through its Estonian-language examples but adds no syntax, length, or formatting constraints for `text`, so the schema carries the semantics here.

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

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

States a specific verb and resource: flags number-writing slips (numbrite õigekirjutus) in Estonian text, then enumerates the six exact rule categories with before/after examples. This is clearly distinguishable from sibling linters like check_punctuation or check_hyphenation, which cover other orthographic domains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Each bullet defines the triggering condition plus explicit skips (code, paths, versions, scores, phone numbers, sums after =), and the closing line 'Spelling out small numbers is not checked' marks a real boundary. It never names an alternative sibling tool or says when to prefer this over, say, spell_check, so it stops short of full routing guidance.

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

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

The description goes well beyond the annotations by disclosing the exact rules, known exclusions, low recall by design, and the important caveat that a hit may be a subject or adverbial without a parser, so it should be treated as worth a second look. These are substantive behavioral details that annotations (readOnlyHint, idempotentHint, openWorldHint) do not cover.

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

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

The purpose is front-loaded, and the rule structure is clear, but the description is very long and dense for a single-parameter checker. Many examples and exclusions earn their place for behavioral transparency, yet the text could be tightened and made easier to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the grammar rules and the presence of an output schema, the description is complete enough for an agent to invoke and interpret the tool correctly. It covers the core rules, exceptions, false-positive behavior, and recall limitations without needing to explain return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the single `text` parameter is already documented as 'Estonian text.' The description does not add further parameter-level semantics such as input length limits, language constraints, or formatting expectations beyond what the schema provides.

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

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

The description clearly states a specific verb and resource: it flags a direct object in the wrong case and names the exact rule families (negation-requires-partitive, partitive-only-verb, teavitama-allative-recipient, teatama-partitive-person). It is highly specific, but it does not explicitly differentiate itself from sibling tools such as check_style, analyze_morphology, or paradigm.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the rule descriptions and by the note that recall is low by design, but the description never explicitly says when to use this tool versus alternatives or when not to call it. An agent must infer that it is for Estonian object-case proofreading from the purpose statement alone.

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

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

Annotations already cover readOnly/idempotent/openWorld, so the description is free to disclose genuine behavior — and it does: per-rule thresholds, which rules are document-wide (position 0), which senses are skipped, and precise false-positive carve-outs. The one gap is that the `metrics.nominalisations` explanation is a return-value detail rather than invocation behavior, and the description never states the output shape at a high level (though an output schema exists).

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

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

Purpose and rule inventory are front-loaded and machine-scannable via backticked rule names, but the second half collapses into a dense run-on paragraph of micro edge cases (the numeral viis, the fugue term, "Kohver viidi läbi", quote-line skipping). These are real precision aids but are unstructured and would read far better as bullets; the agent must parse a wall of prose to extract the exclusion rules.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Since an output schema exists, return values needn't be explained — yet the description still clarifies the one ambiguous field (`metrics.nominalisations`, its verb resolution, split-particle handling, and lexicalised exclusions). For a rule-engine style checker with 10+ rules and many carve-outs, this is materially complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter with 100% schema coverage, so the baseline is 4. The description reinforces the expected input domain (Estonian non-legal prose; kantseliit-bearing reports/academic/business text) which adds a small amount of guidance beyond the schema's own "Estonian non-legal prose (report, academic, business)."

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

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

Opens with a specific verb+resource+scope: "Flag Estonian kantseliit in reports, academic and business prose" and immediately names the boundary case ("statutes and contracts go to check_legalese"). An agent can distinguish this from check_legalese, check_style, and classify_register without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the alternative: legal texts go to check_legalese; this tool is for non-legal prose. It also states the tool's epistemic posture ("Both are style hints, not errors" and "no issues is not proof the text is plain"), which tells the agent how to interpret results rather than just when to call.

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

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

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

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

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

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

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

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

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

Annotations already cover read-only, idempotent and closed-world behavior, and the description adds real value beyond them: the exact detection taxonomy, the fact that each issue's `explanation` is in Estonian, and an honest recall limitation ('misses much redundancy a native speaker would hear'). It does not state severity levels or whether output is per-occurrence, but the conservativeness disclosure is substantive.

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

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

Front-loaded purpose statement followed by a tight bulleted taxonomy where each bullet earns its place by pairing a category code with concrete examples. The final sentence on conservativeness is short and load-bearing, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return structure need not be explained, and the description covers categories, explanation language, and known recall gaps. Minor gaps remain: nothing on input size limits or what happens with non-Estonian text. For a single-parameter checker this is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

One parameter with 100% schema description coverage, so the schema already documents `text` as Estonian text. The description adds nothing about the parameter itself (no length limits, no handling of mixed-language input). Baseline 3 applies when the schema does the heavy lifting.

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

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

Names a specific verb (flags) and a precise linguistic resource (redundant doubling / liiasus / pleonasm), then enumerates the exact three categories it detects with Estonian examples. Among the many check_* siblings this is unmistakably the redundancy checker, distinguishable without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: pass Estonian text and it reports doubling/pleonasm issues. There is no explicit when-to-use versus check_style, check_officialese, or check_compounds, nor any when-not guidance. The closing note about being conservative hints at when to distrust results, which is useful but not full routing guidance.

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

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

Annotations already declare readOnly/idempotent/closedWorld, so the description earns credit for what it adds: repetition counts scale with text length and return character offsets; attributive -tud participles are excluded from passive_voice into a named `attributive_excluded` bucket; hedging is a short fixed list (vist, pigem, ehk). This tells the agent exactly how numbers are computed, including the exclusion rule that would otherwise cause confusion. It stops short of describing anything else about the returned result shape.

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

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

Front-loaded one-line summary, then one bullet per metric with thresholds and measured baselines — no filler, and the offsets/exclusion caveats sit next to the metric they qualify. Slightly long for a one-parameter tool, but every bullet carries actionable interpretation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 only convey what each metric means and how to read its value, which it does for all four families including the minimum/maximum danger thresholds. Nothing an agent needs in order to call it or interpret the results is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter with 100% schema coverage ('Estonian text to measure.'). The description adds no syntax, format, length, or preprocessing guidance for the input beyond the existing 'Estonian' constraint, so baseline 3 applies.

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

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

States a specific verb+resource: heuristic Estonian style metrics, and enumerates the four metric families (repetition, passive_voice, sentence_length, hedging). The explicit 'no cliche detection' boundary and the pointer to check_officialese for kantseliit separate it from at least one noisy sibling. It doesn't cleanly distinguish itself from classify_register or check_redundancy, which also touch style, keeping it below a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete application context via interpretation thresholds (marketing copy passive under 15%, news sentences 10–15 words, hedging over 5% reads wishy-washy) rather than a bare 'measures style'. It also routes the kantseliit question to check_officialese, an explicit alternative. What's missing is a plain when-to-use statement for the sibling style tools.

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

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

Beyond the readOnly/idempotent annotations, the description discloses the two detection heuristics by name, the output fields (variants, counts, dominant, preferred, in_domain_glossary), the meaning of degraded: true and its consequence that empty output proves nothing, and an explicit known miss (synonyms sharing neither head nor synset). This is unusually rich behavioral context for a checker.

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

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

Purpose is front-loaded in sentence one and no sentence is filler; the rules, degraded mode, and glossary effects each appear once. The prose is telegraphic in places ('no groups is then no proof of consistency'), which costs some readability but not content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 detail return values, yet it usefully does. It covers limitations, degraded behavior, and glossary interaction; the main remaining gap is guidance on choosing this tool over the domain-terms and defined-terms siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining that supplying a glossary changes the returned data (in_domain_glossary flags, and a sole listed variant becoming preferred regardless of dominant). The glossary's per-call, non-stored nature is already in the schema, so no credit there.

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

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

The first sentence states a specific verb and outcome ('Flag a document that names one thing several ways') with a concrete Estonian example, so the agent knows exactly what class of problem it detects. It does not, however, distinguish itself from near-siblings such as check_domain_terms or check_defined_terms, leaving the agent to guess which check to run.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the two triggering rules and warns that 'some groups are distinct concepts and the tool does not pick the right term: read each first', which governs how to interpret hits. But it never says when to call this versus check_domain_terms, check_defined_terms, or check_redundancy, and gives no prerequisite about document language or size beyond the schema.

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

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

Annotations already declare readOnly/idempotent/closed-world, and the description adds substantial context beyond them: the exact rule inventory, which two rules are only style hints, which constructs are deliberately NOT checked (third-person possessives, negated verbs, questions), and a false-positive guard that accepted Estonian is never flagged. That is unusually rich behavioral disclosure for a checker.

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

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

Purpose and usage are front-loaded in the first two sentences, then the rule list. The rule block is long but each item carries distinct information (rule name plus example), so it earns its space; it is dense rather than padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 needn't explain return values, and it covers scope, rules, exclusions, and sibling routing. Minor gaps remain: no statement about behavior on non-Estonian or mixed input, and no mention of input size limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter and schema coverage is 100%, so the schema already fully documents `text`. The description's guidance (Estonian you wrote or translated) largely duplicates the schema description and adds no syntax, size, or format constraints for the input.

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

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

The first sentence names a specific verb (flag), a specific target (English structure in Estonian), and frames it as translationese detection. It also names the sibling it defers to for a related-but-different concern (check_officialese handles letter formulas), so an agent can separate it from check_style and check_officialese without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Run it on Estonian you wrote or translated" gives a clear usage condition, and the closing line explicitly routes letter formulas to check_officialese. It lacks a full when-not-to-use statement (e.g. versus check_style or check_legalese for register/rhetoric), so the alternative map is clear but not exhaustive.

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

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

Annotations already mark it read-only/idempotent/closed-world, and the description adds substantial beyond-schema behavior: the -1 to 1 score range, the correct label to quote (formaalne, not *formalne), what consistency.is_mixed means, and the exact conditions under which structure contributes (up to 0.4, from 25 words, never on net-colloquial text). This is unusually rich disclosure for a heuristic scorer.

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

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

Front-loads the core caveat ('directional hint, not a verdict') before the detail, and every sentence carries information about output fields or applicability. The backtick-fragment style is dense and slightly telegraphic, but nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a single-input scorer. The output schema exists, yet the description goes further by explaining how to read score, tier_estonian, consistency.is_mixed and structure, which is exactly what an agent needs to interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter and schema coverage is 100%, so the baseline is 3. The description still adds input-relevant meaning: address forms are unscored and the structure component only applies from 25 words up, which tells an agent how input length and content affect the result.

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

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

States a specific verb and resource ('Heuristic Estonian register score') plus the scope limit ('a directional hint, not a verdict'). It explicitly disambiguates from the nearest sibling, check_officialese, so an agent can choose without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real usage context: everyday prose scores neutral, address forms (sina/teie) are excluded, and per-issue kantseliit work should go to check_officialese instead. It lacks an explicit 'call this when...' trigger sentence, but the alternative routing is clear.

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

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

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

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

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

Front-loads purpose, then qualifies the output semantics in two tight follow-up sentences. Every clause carries distinct information (scope, field meaning, caveat) with no repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even though an output schema exists, the description supplies the interpretive layer an agent needs to act on the results correctly: what the frequency counts mean, that lemmas must be inflected, and that a miss is not a judgement. Nothing essential to correct invocation or interpretation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter's own description already says "one Estonian word, any inflected form." The description adds no parameter-level detail beyond that, so the baseline 3 applies; its added value lies in interpreting the output fields, which is scored elsewhere.

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

The description adds substantial behavioral context beyond the annotations: it names the fastText model and corpora, explains cosine-score ranking, discloses that senses are not separated, and warns that inflections may appear and should be deduplicated via lemmatization. This is exactly the kind of operational detail 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.

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

The description is three dense sentences, front-loads the core operation, and uses the remaining space for sibling differentiation and important caveats. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the annotations, output schema, and 100% parameter coverage, the description is complete: it explains model provenance, ranking, sense ambiguity, and edge-case behavior. No critical invocation detail is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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, including the `n` range. The description still adds useful meaning for the `word` parameter by stating that it accepts any Estonian word form, including typos, and by explaining that inflected neighbours may appear.

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

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

The description states a specific operation and resource: nearest neighbours of an Estonian word in a fastText model, ranked by cosine score. It explicitly distinguishes itself from the sibling `synonyms` tool by contrasting context-based neighbours with WordNet same-meaning synonyms.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly tells the agent when to use this tool instead of `synonyms`, and explains what kinds of relations to expect: near-synonyms, related concepts, inflections, and sometimes antonyms. It also notes that any string, including typos, will return neighbours, setting expectations for edge cases.

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

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

Annotations already declare readOnly, idempotent, and closed-world behavior, so the safety profile is covered. The description adds genuinely behavioral detail beyond that: lemmas come from the single most likely analysis (a disambiguation policy) and punctuation is omitted from output, both of which affect how the agent interprets results.

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

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

Two short sentences, zero filler, with the core output definition front-loaded ahead of the punctuation caveat. Nothing could be removed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 explain return values, and annotations cover the safety profile. What it supplies — per-word lemmas, most-likely-analysis selection, punctuation omission — is sufficient to call the tool correctly, though behavior on unknown or out-of-vocabulary words is unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single `text` parameter ('Estonian text.'), so the baseline is 3. The description's 'of each word' hints that input may be multi-word text, but it adds no format or language guidance beyond what the schema already says.

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

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

The description names the concrete resource produced (the lemma/dictionary form) on a per-word basis and specifies the disambiguation rule ('most likely analysis'). It is clear what the tool returns, but it never names its siblings (analyze_morphology, tokenize, pos_tag), so the agent gets no in-description help distinguishing lemmatization from full morphological analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this versus analyze_morphology, pos_tag, or tokenize, and no mention of prerequisites or excluded inputs. The agent must infer the use case from the noun phrase alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds useful behavioral detail beyond those annotations by clarifying the returned fields (type, start, end, text) and warning that text is the span as written and often inflected, which matters for interpreting results.

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

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

The description is two compact sentences, front-loaded with the entity categories and offsets. Every phrase contributes useful information without repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, read-only named-entity extraction tool with complete annotations, a complete input schema, and an output schema, the description is largely sufficient. It provides the entity types, offsets, and an inflection caveat; only explicit usage guidance is notably absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one input parameter, and schema description coverage is 100%, so the schema already documents the input adequately. The description mentions `text`, `type`, `start`, and `end`, but these appear to describe output fields rather than adding input-parameter semantics beyond what the schema provides.

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

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

The description clearly identifies the resource as named entities by naming the categories (people, places, organisations) and corresponding types (PER, LOC, ORG). It does not state an explicit action verb or explicitly differentiate from siblings, but the tool name and unique entity-recognition focus make its purpose clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance about when to use this tool versus alternatives such as tokenize or pos_tag. It implies usage through the entity categories but does not state conditions, exclusions, or alternatives.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description still goes well beyond them: it discloses that output is generative not normative, that non-inflecting words yield empty `forms` with an explanatory `summary_estonian`, and the crucial caveat that `adt` surfaces often coincide with singular partitives and do not confirm case. That is exactly the kind of trap-flagging an agent cannot infer from structured fields.

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

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

It is front-loaded with purpose and output shape, then the caveats, and every sentence carries substantive information about return structure or pitfalls. It is dense and jargon-heavy (form codes, `adt`, `sg p`) but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema existing, the description explains the return contract in detail: per-entry `form`/`form_estonian`/`surface`, list-valued surfaces with ordering rationale, `paradigm_key` naming the ranked type, `other_paradigms` coverage rules, and `ambiguity_estonian`. Nothing an agent needs to interpret or safely quote results is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter is fully described in the schema, so the baseline is already high. The description earns extra credit by explaining a non-obvious behavior the schema does not: passing an inflected form rather than the lemma selects which paradigm type is returned when `paradigm_count` > 1.

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

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

The description opens with a precise verb+resource: 'Inflection paradigm of one Estonian word from Vabamorf,' and immediately scopes the output ('generates what is possible, not necessarily idiomatic'). That is enough to separate it from morphological siblings like analyze_morphology or lemmatize, though it never names those alternatives explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives real operational guidance – 'Read `ambiguity_estonian` before quoting a form' and 'Pass an inflected form (koti) to select the type you mean' – which tells the agent how to steer the tool. But it never states when to reach for this tool rather than the sibling morphology tools, so the when-to-use decision is left implicit.

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

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

Annotations already cover read-only, idempotent, closed-world behavior, so the description is free to add real semantics: a single most-likely reading is returned per word, punctuation is dropped, and edge cases (X verb-bound words, Z words of 40+ characters too long for Vabamorf) are disclosed. This goes meaningfully beyond the annotation set without contradicting it.

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

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

The operational sentence is front-loaded and short, followed by an enum-key legend that is dense but earns its place since those tag codes would otherwise be opaque. No filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return structure need not be explained; the description supplies exactly the missing piece, the meaning of each tag code including the two special cases. The only gap is routing guidance against near-duplicate siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter, fully described in the schema as 'Estonian text.' The description adds no detail about input format, length limits, or whether multi-sentence input is allowed, so baseline 3 applies with schema coverage at 100%.

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

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

The description opens with a specific verb+resource: 'Part-of-speech tag of each word', and qualifies it with 'most likely reading'. It does not name or contrast with the closest sibling, analyze_morphology, so an agent cannot tell from the text alone which of the two to reach for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus analyze_morphology, tokenize, or lemmatize, and no exclusions or prerequisites. Usage must be inferred entirely from the tool name and the tag legend.

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

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

Annotations already declare readOnly/idempotent, but the description adds the crucial semantic caveat that a pass only proves well-formedness, not lexical reality, because Vabamorf accepts invented compounds. It also defines what an empty list means and when suggestions appear — behavior an agent could not derive from 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.

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

Two short paragraphs, front-loaded with the core action and the key caveat, with no filler. Minor waste in enumerating output field names (`text`, `spelling: false`) that an existing output schema already covers, though the ordering and conditional-presence notes do earn some of that space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 needs only to explain semantics and caveats, and it does exactly that — what a hit looks like, what empty means, and the false-positive risk on compounds. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both `text` and `suggestions` are already documented with a default. The description mentions `suggestions` only as an output field ("`suggestions` when Vabamorf has any"), which adds little to the parameter's own schema text; baseline 3 applies.

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

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

States a specific verb and resource ("Spell-check Estonian text") and immediately characterizes the output ("Lists only the misspelled tokens"). It also distinguishes itself from the compound-oriented siblings by naming check_compound_familiarity as the tool 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear condition for escalating to check_compound_familiarity when a compound is newly coined, which is real routing guidance against a large sibling set. It does not, however, explain how it relates to check_punctuation, check_capitalization, or check_style, so an agent must infer the boundaries of the other check_* family members.

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

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

Annotations already declare readOnly/idempotent/closed-world, and the description adds genuinely new behavioral context: the underlying engine is Vabamorf's guesser syllabifier and it can err even on common words, so the agent knows to treat results as approximate. It also decodes output semantics (välde 1-3, accent=stress) that annotations cannot convey.

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

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

Two dense sentences, front-loaded with what is returned, then output-field semantics, then the reliability caveat. No filler and nothing repeated from the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and a fully documented single parameter, the description only needs to add output semantics and caveats, which it does. The remaining gap is routing guidance against sibling tools, but that is minor for such a narrow utility.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter with 100% schema description coverage, so the schema already documents it fully ('One Estonian word, no whitespace'). The description's 'one Estonian word' reinforces but does not extend that, so the baseline 3 applies.

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

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

The description states a specific resource and transformation: lowercased syllables of exactly one Estonian word, plus what the returned `quantity` and `accent` fields mean. It is clearly distinct in substance from siblings like tokenize or analyze_morphology, though it never names or contrasts them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: if you need syllables, call this. The scope constraint 'one Estonian word' hints at the boundary (not phrases, not multiple words), but there is no explicit when-to-use, when-not, or pointer to alternatives such as tokenize.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is clear. The description adds useful tokenization behavior—preserving order and including punctuation—but does not go much further beyond what the annotations provide.

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

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

A single front-loaded sentence with no filler. It communicates the operation and output contract efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one parameter, an output schema, and annotations covering safety and idempotency, the description is largely complete. It adequately explains the output categories, though it does not explicitly mention deterministic behavior or input expectations, which are covered elsewhere.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has full description coverage for the single `text` parameter, so the baseline is 3. The description implies the input is Estonian text but adds no format, length, or encoding details beyond the schema.

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

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

The description states a specific verb and resource: 'Split Estonian text into sentences and words.' It also clarifies the exact output semantics ('every token in order, punctuation included'), making the tool's purpose immediately distinguishable from linguistic-analysis siblings such as 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the clear purpose, but there is no explicit guidance on when to use tokenize versus alternatives like analyze_morphology or syllabify. No exclusions or prerequisites are mentioned.

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