list_printers

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

Annotations already establish that this is a safe, idempotent, closed-world read, and an output schema exists, so the description is not obligated to explain safety or return values. It still contributes useful behavioral context by noting the cardinality rule ('one per printer + nozzle') and the field set, though it says nothing about ordering, limits, or how an empty result behaves.

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?

Two sentences, front-loaded with what the tool returns and followed by the parameter hint; nothing is padded. The first sentence is a dense field dump, but every item listed is genuine content an agent would want.

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 zero-required-parameter list tool, the description covers the resource, the entry shape, and the filtering parameter, while annotations handle safety and an output schema handles returns. The only real gap is routing guidance against list_presets, which is a modest omission rather than a blocking one.

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 0%, so the description must carry the single parameter — and it does, explaining that 'query' filters by words and giving a concrete example ('P1S 0.4'). It stops short of stating matching semantics (substring vs token, multi-word AND/OR) or how a null query behaves, but it is well above the low-coverage baseline.

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 states the resource precisely — installed printer presets, one per printer + nozzle — and enumerates the fields each entry carries, so an agent knows exactly what it gets back. It does not explicitly differentiate itself from the sibling list_presets, so a reader must infer the printer-vs-process distinction from the noun alone.

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?

There is no when-to-use statement and no named alternative, despite the near-neighbour sibling list_presets existing. The only usage hint ('query filters by words') describes the parameter, not when this tool should be selected over another.

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