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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real value beyond them: it discloses the return shape (price units — fixed, per second, or token; variants for options like resolution), the presence of routing tags, and a prerequisite workflow (consult get_model_guide first). No pagination, ordering, or result-count behavior is mentioned.

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?

One dense sentence front-loads the resource and payload, followed by a short help pointer. Parenthetical clauses make it heavy to parse, but every element (price units, variants, tags, guide prerequisite) carries information an agent needs.

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?

With no output schema, the description carries the return-value burden and does so by enumerating price semantics, variants, is_default, routing tags, and guide. Minor gaps remain around result ordering and whether all models or only enabled ones are paginated, but nothing critical is missing for a read-only one-parameter list call.

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% and the single 'type' parameter is fully documented with a pattern and example values, so the description adds nothing beyond 'one generator type'. Baseline 3 is appropriate; the description correctly signals single-type scoping but supplies no additional syntax or constraints.

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 names a specific resource (enabled models for one generator type) and enumerates the payload fields returned (price in credits, is_default, routing tags, guide), which lets an agent distinguish it from get_pricing and list_templates. It never states an explicit verb or contrasts itself against those siblings, so it falls short of a 5.

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 only procedural guidance is downstream ('read get_model_guide before prompting a model the first time') plus a pointer to get_tool_help, which tells the agent what to do after calling, not when to call this instead of get_pricing. Usage is implied by the 'enabled models for one generator type' scope, but no exclusions or alternatives are given.

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