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

Annotations already provide readOnlyHint=true, so the agent knows it's a read-only operation. The description adds that each entry has 'defaultCompiler' and 'compilerCount', but does not disclose other behavioral aspects like the number of languages, pagination, or rate limits. For a simple list endpoint with no side effects, the combination of annotations and description is minimally adequate, earning a 3.

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 description is extremely concise at two short sentences (25 words). The first sentence states the core purpose, and the second provides key structural details. Every word earns its place with no redundancy or extra fluff. This is an excellent length for such a simple 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 the tool has no parameters, no output schema, and annotations covering read-only intent, the description provides just enough to understand its role: it lists languages and their associated compilers. The mention of 'defaultCompiler' and 'compilerCount' partially compensates for the missing output schema. The tool is simple, so completeness is high. For a more complex tool, this might be insufficient, but here it works well.

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?

With 0 parameters and 100% schema description coverage, the schema already documents all necessary info. The description adds no parameter details because there are none. Per guidelines, 0 params baseline is 4, and the description does not detract from that. The mention of 'defaultCompiler' and 'compilerCount' is a bonus, hinting at the structure of the response, which is beyond the schema's scope.

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 clearly states the purpose: 'List supported languages'. It also specifies the shape of each entry ('defaultCompiler' and 'compilerCount'), which is specific and informative. The tool name is 'list_languages' and the title is 'List languages', aligning perfectly. No sibling tool has a similar purpose, so it is well-distinguished.

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 not provide guidance on when to use this tool versus alternatives. Given siblings like 'list_compilers' and 'list_libraries', a user might benefit from knowing if this tool is a prerequisite for others. However, the tool is simple enough that usage is implied: call it to see available languages before using other tools. The lack of explicit guidance keeps it at a baseline 3.

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