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

Annotations already declare readOnlyHint=true, and the description adds behavioral context beyond that: it notes the response is free, includes all listed fields in one response, and covers text-generation models only. No contradiction with annotations; the description supplements them with cost and response-aggregation details.

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 front-loaded with the key English purpose, but it is somewhat redundant: the Korean translation repeats the English statement, and '무료입니다' appears twice ('무료입니다. [무료]'). It could be tightened without losing meaning, but it is still reasonably compact and structured.

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 compensates by naming the exact fields returned (input/output unit price per 1M tokens, family, size, multimodal flag, tags, use_cases, max_context) and stating they come in a single response. It also explains the tool's relationship to llm_chat. This is adequate for a read-only catalog tool, though it doesn't describe response pagination or exact formatting.

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% with detailed descriptions for all four parameters (tag, family, use_case, multimodal), so the description does not need to compensate. The tool description adds context about output fields but not about parameter semantics beyond what the schema already provides, matching the baseline of 3.

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 opens with a specific verb and resource: 'List available text-generation LLM models with per-token pricing and max context.' It also differentiates from siblings by stating that the tool is used to find model input values for llm_chat, which distinguishes it from chat, image generation, and text processing tools.

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?

It provides clear context: 'llm_chat Tool의 model 입력값을 찾을 때 사용합니다' (use when finding model input values for llm_chat Tool). This tells the agent when to select this tool, though it does not explicitly state when not to use it or name alternatives as exclusions.

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