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

The single annotation stating readOnlyHint: true handles the primary behavioral safety trait. The description adds no unique behavioral information (like rate limits or data constraints) beyond what is implied by the name and the read-only hint.

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?

While short, the structure is highly misleading. It uses its limited space to describe the API usage of sibling functions rather than defining its own function, which is poor definition hygiene.

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?

Despite having zero parameters, the description is not complete because it provides no functional description of the data that will be returned, which is the core expectation for a list 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?

As the tool has zero input parameters, the parameter semantics dimension defaults to high. The description adds no specific clarifying information about the non-existent parameters.

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 is fundamentally flawed as it does not explain what the list_languages tool does. Instead, it discusses parameter acceptance for unrelated sibling tools (get_quote and create_order), making the purpose of this tool completely unclear.

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?

There is absolutely no guidance on when to use list_languages versus any of the other list or creation tools available. The description focuses entirely on external tools, offering zero usage context.

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