Check and correct grammar, spelling, punctuation, and style errors in text. Use fix-only or clarity mode and review changes through a track-changes diff view.
Check and fix grammar, spelling, punctuation, and style errors. See exactly what changed with a track-changes diff view. Two modes: fix errors only, or improve clarity and style. (~1 credits)
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| text | Yes |
Changes observed during successful MCP inspections.
v1.0.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses the track-changes diff output and the approximate credit cost (~1 credits), which are real behavioral facts an agent needs. It does not say whether the result is returned as text/diff, whether the source text is preserved, or any length limits — gaps remain for a no-annotation tool.
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 short sentences, front-loaded with the core capability before the mode detail and cost. Nearly zero waste; the parenthetical credit note and diff-view mention each carry information. Slightly fragmentary but efficient.
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 no annotations, no output schema, and 0% schema description coverage, the description should do more. It covers the capability, two modes, diff output, and cost, which is a reasonable core, but omits exact mode values, input limits, and output format specifics. Adequate but with clear gaps for a zero-structured-data tool.
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 0% and both parameters ('mode', 'text') have empty descriptions in the schema. The description partially compensates by describing the two mode behaviors, but it never gives the literal enum values an agent must pass, and 'text' semantics are only implied. Coverage gap is only half filled.
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 specific verbs and resource scope — 'Check and fix grammar, spelling, punctuation, and style errors' — and explicitly names its two operating modes. This clearly separates it from siblings like aaddyy_paraphraser, aaddyy_humanizer, and aaddyy_synonym_finder, which rewrite rather than correct.
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 does indicate the two modes ('fix errors only' vs 'improve clarity and style'), which gives implicit guidance on selection. However, it never says when to choose this tool over the adjacent rewriting tools (humanizer, paraphraser), nor any prerequisites or exclusions. Usage is implied, not directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.