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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds cost context, but that context is self-contradictory: the header says "Free (0 credits)" while the trailing bracket says "see your plan — endpoint not in the public credit manifest." An agent cannot tell whether this call is free or metered, which undercuts the one behavioral fact the description tries to add.

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 first sentence is tight and front-loaded and is the only sentence that matters. The bracket block restates group and endpoint metadata the agent already has from the tool name and transport, and its cost line duplicates and contradicts the "Free (0 credits)" claim above it.

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 no-required-parameter reference endpoint with full annotations and an output schema, the description covers what is needed; the return shape is described by the schema, not the text. The only completeness blemish is the conflicting cost statements, which leave the agent uncertain about billing.

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 (fields, precision compact-mode controls) are fully documented inline, so the baseline is 3. The description contributes nothing about these parameters, but it does not need to.

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 with an exact cardinality: "List the 21 supported language codes + names." An agent immediately knows this is a static reference lookup. It does not, however, explicitly distinguish itself from the nearby siblings translate_glossary_lang, translate_astro, and translate_batch, which are the tools an agent might realistically confuse it with.

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 "Free (0 credits)" note implies this is a cheap, safe discovery call to make before a translation tool. But there is no explicit when-to-use statement, no pointer to translate_astro/translate_batch as the follow-up, and no exclusions. Usage is implied rather than guided.

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