Skip to main content
Glama

check_style

Read-onlyIdempotent

Measures Estonian text for repetition, passive voice, sentence length, and hedging to flag style issues such as monotonous prose or officialese.

Instructions

Heuristic Estonian style metrics; no cliche detection.

  • repetition: content lemmas used threshold+ times (scales with length), with character offsets.

  • passive_voice: umbisikuline tegumood share of verbs (attributive -tud participles go to attributive_excluded). Marketing copy: aim under 15%; under 5% may read forceful. Reports: over 40% is the clearest kantseliit sign (see check_officialese).

  • sentence_length: words per sentence; a stddev under 30% of the mean reads monotonous. News and web text: at most 10 to 15 words a sentence (the state's web-writing guide). Measured averages: e-mail about 9, news about 14, statutes about 25.

  • hedging: share of words on a short fixed list (vist, pigem, ehk); over 5% reads wishy-washy, 0% does not rule hedging out.

Input Schema

NameRequiredDescriptionDefault
textYesEstonian text to measure.

Output Schema

NameRequiredDescriptionDefault
hedgingNo
repetitionNo
passive_voiceNo
sentence_lengthNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed18 schema fields changedv0.9.0
    • changedInput schema / properties / text / description
      Previous value: -"Estonian text to compute style metrics for (repetition, passive voice, sentence length, hedging)."New value: +"Estonian text to measure."
    • removedInput schema / properties / text / title
      Removed value: -"Text"
    • removedInput schema / title
      Removed value: -"check_styleArguments"
    • removedOutput schema / properties / hedging / additionalProperties
      Removed value: -true
    • removedOutput schema / properties / hedging / default
      Removed value: -null
    • removedOutput schema / properties / hedging / title
      Removed value: -"Hedging"
    • removedOutput schema / properties / note
      Removed value: -{
      -  "default": null,
      -  "title": "Note",
      -  "type": "string"
      -}
    • removedOutput schema / properties / passive_voice / additionalProperties
      Removed value: -true
    • removedOutput schema / properties / passive_voice / default
      Removed value: -null
    • removedOutput schema / properties / passive_voice / title
      Removed value: -"Passive Voice"
    • removedOutput schema / properties / repetition / additionalProperties
      Removed value: -true
    • removedOutput schema / properties / repetition / default
      Removed value: -null
    • removedOutput schema / properties / repetition / title
      Removed value: -"Repetition"
    • removedOutput schema / properties / sentence_length / additionalProperties
      Removed value: -true
    • removedOutput schema / properties / sentence_length / default
      Removed value: -null
    • removedOutput schema / properties / sentence_length / title
      Removed value: -"Sentence Length"
    • removedOutput schema / properties / text
      Removed value: -{
      -  "default": null,
      -  "title": "Text",
      -  "type": "string"
      -}
    • removedOutput schema / title
      Removed value: -"_StyleResult"
  2. First observedv0.2.4

TDQS

A4/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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

With an output schema present, the description need 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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.