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

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description still adds real value beyond them: it discloses the estimation methodology (weights + 20% runtime overhead), warns that throughput is not modeled, and signals that rental prices are current/snapshot-in-time.

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?

Front-loaded with the core question, followed by the quant enumeration, the estimation caveat, and the limit bound. The long quant list is justified because the schema supplies no enum, and no sentence is redundant.

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 an output schema present, return values need not be described, and the methodology caveat covers the main interpretive risk. However, for a 3-parameter tool with zero schema descriptions, leaving the required model parameter's expected format unspecified is a meaningful gap.

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 0%, so the description must carry parameter meaning. It does well for quant — enumerating all 18 accepted values that the schema leaves as a bare string — and bounds limit to 1-10, but it never explains the format expected for model (name? ID? huggingface slug?) nor what limit actually caps.

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?

States a concrete question the tool answers — GPU count to self-host an open-weight LLM at a given quantization — plus a secondary output (cheapest rental setups). The scope ('open-weight LLM', 'estimates memory only, not throughput') is specific enough to separate it from siblings like cheapest_gpu or find_model, though it never names those siblings explicitly.

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?

Usage is implied: it is a sizing/costing lookup for self-hosting a model. There is no explicit when-to-use vs. when-not-to-use guidance and no routing to cheapest_gpu or find_model, so an agent must infer the boundary from the sibling names.

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