List CPU Lines

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

Annotations already declare a safe idempotent read, so the description correctly spends its space on domain semantics instead: what a line is (vendor + product line + generation with fixed ddr_type, 0 = unknown), the fallback when no line is supplied, and what max_vcpus_per_pod/max_ram_per_pod represent. No contradiction with the readOnlyHint.

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?

Four front-loaded sentences, each adding something distinct: purpose and pricing, definition of a line, downstream usage, capacity fields, and the spot tier. Dense but no filler; slightly heavy with backticked field names read in flow.

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 a single optional parameter, a full output schema, and safe-read annotations, the description supplies everything needed to call it and act on the result: the meaning of cpu_line, the no-argument default behavior, capacity limits, and the optional tier switch.

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% and rental_type has no enum or description, so the description carries the load: it explains that 'spot' selects the cheaper preemptible tier, which is exactly the meaning the schema omits. Only the default 'demand' path is left implicit via the schema default.

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?

Opens with a specific verb and resource: 'Show the CPU lines a CPU pod can run on right now,' including pricing units (per vCPU core, per GiB RAM). The CPU framing implicitly contrasts with the 'gpus' sibling, but it never names that alternative, so sibling differentiation is only implied.

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?

Gives clear downstream routing: 'Pass its cpu_line to estimate_pod or create_pod; without one the cheapest line that fits is used.' It also states when to pick the spot tier. It stops short of stating when to use this versus the gpus or machines siblings.

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