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

No annotations are supplied, so the description carries the full burden, and it does substantial work: it discloses billing granularity (per started 1 000 chars), the exact price (€0.01 per 1 000 chars), and that charges attach to the bearer token in the Authorization header. What it omits is equally relevant behavior: maximum input size, failure/refund semantics, and whether a rejected language code is still billed.

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 value proposition and constraints before the parameter list, and every clause is load-bearing — preservation guarantees, language count, price, auth, then parameter formats. The trailing parameter run-on is dense and slightly hard to scan, and the "Parameters —" header duplicates what the schema already enumerates.

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 values need not be explained, and the description covers the remaining questions an agent would have before calling: what is preserved, what the cost model is, where the charge lands, and what every parameter accepts. Length limits and required-field expectations are minor residuals against an otherwise complete brief for a single-endpoint transform.

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 must compensate, and it largely does: target language is defined as an ISO code with examples (en, de, uk), tone is given an enumerated value set with a stated default (neutral) that the schema does not itself declare, and glossary is given a concrete source=target, comma-separated format. The text parameter is documented only tautologically ("text: text"), and no length or escaping guidance is given for 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 opening clause states a specific verb and resource (translation) plus the differentiating properties: preserves Markdown, placeholders and tone, supports glossaries, and covers 38 languages. This distinguishes it cleanly from siblings such as rewrite, detect_lang and summarize without the agent needing to open 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?

Usage is only implied — the agent can infer it should call this when text needs to move between languages. There is no explicit when-not guidance, no mention of alternatives like rewrite for same-language edits, and no statement of prerequisites such as a valid target language or a working API key balance.

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