check_language

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

With no annotations, the description carries the full transparency burden and succeeds. It discloses the local LanguageTool dependency, the elicitation behavior when lang is uncertain, the strict input exclusivity, and the boundary that it only returns facts and suggestions, never a rewritten corrected version. This gives the agent accurate expectations beyond a bare read/write label.

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 core purpose is front-loaded, and every subsequent sentence adds operational value: language auto-detection behavior, output constraints, and input-format requirements. There is no tautology or filler, and the length is appropriate for a 5-parameter tool.

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 5 parameters, no annotations, and an existing output schema, the description appropriately covers input exclusivity, filename coupling, language elicitation, and output scope while leaving return details to the output schema. Minor omissions such as supported file types for path/text and the meaning of the MRTR acronym keep it from being perfect.

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%, so the description is the only source of parameter meaning. It explains all five parameters: lang has fallback/elicitation behavior, path is a filesystem path, text is raw text, content_base64 is inline file content, and filename is required alongside content_base64. Minor gaps remain, such as accepted file types for path/text and lang format conventions, but the compensation is strong overall.

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 scope — grammar/spelling/punctuation/style findings — and identifies the mechanism (local LanguageTool) and the anchor-based precision benefit. Sibling tools focus on structure, typography, PDF layout, and filename consistency, so this tool is clearly differentiated.

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 strong invocation constraints: exactly one of path, text, or content_base64 must be supplied, and filename is required with content_base64. However, it does not explicitly state when to choose this tool over siblings or name alternatives; selection is left to inference from the sibling names.

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