List locales

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

No annotations are provided, so the description carries the burden. It describes this as a read/list operation implicitly through the verb 'Lists', and clarifies the scope of what's returned. However, it doesn't describe return format, whether the optional locale filter changes response shape, or any side effects (though for a list tool these are minimal).

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?

Single, information-dense sentence with zero waste. It communicates the subject (languages), the action (lists), and the returned content (fixed texts with enumerated examples).

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 simple list tool with one optional parameter fully documented in the schema, the description is adequate. It names the return content (fixed texts) and the subject. It could add a note about the default behavior when no locale is given (all locales vs. all), but with the schema covering the parameter and a list tool's inherent simplicity, this is reasonably complete.

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 coverage is 100%, so the schema documents the 'locale' parameter as 'Return the labels of a single locale.' The description doesn't add additional meaning about the locale parameter beyond the schema, but it does contextualize that the full output includes fixed texts, which helps infer the filter behavior. Baseline 3 is appropriate since schema carries the documentation load.

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?

Clear verb+resource: 'Lists the supported languages' combined with what data is returned (fixed texts like salutation, closing, enclosures, page numbering). Distinguishes from siblings like list_fonts and list_profiles by naming its subject 'locales/languages'. Doesn't explicitly differentiate from all siblings but the resource is clearly unique.

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 implies when to use it (need to see supported languages and their fixed texts), but gives no explicit when-not-to-use or alternatives. It's a simple list tool among create/preview/letter tools, so the context is clear, but no exclusions are stated.

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