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

With no annotations, the description carries the full disclosure burden. It usefully states the non-opening, diagnostic behavior, but says nothing about whether the check touches hardware, whether it can fail/block, or any side effects beyond not opening the printer.

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 short sentences, front-loaded with what is checked, then the constraint and the routing cue. No filler.

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 zero-arg diagnostic with an output schema covering return values, the description is nearly sufficient: it says what is inspected, that it is non-invasive, and when to reach for it. The remaining gap is clarifying its relationship to the overlapping status/list_ports siblings.

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?

The tool takes zero parameters, so the baseline is 4; the description is consistent with a no-argument diagnostic and adds no param detail beyond the empty schema.

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?

Specific verb ('Check') plus three concrete resources (local config, serial ports, transport) clearly state what the tool does, and the negative statement 'Does not open the printer' sharpens the scope. It doesn't explicitly distinguish itself from the overlapping sibling labelprint_list_ports, 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?

'Use this first when setup is unclear' gives an explicit triggering condition, which is real routing guidance. It stops short of naming alternatives (e.g., list_ports or status) or stating when not to use it.

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

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

With no annotations provided, the description carries the full behavioral burden. 'List ... device nodes visible on this machine' implies a non-destructive, read-only enumeration scoped to the local host, but it does not explicitly confirm read-only behavior or mention anything about ordering, filtering, or handling of no ports found.

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?

A single front-loaded sentence with no filler; every word (list, serial, device nodes, this machine) earns its place.

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?

An output schema exists, so the description need not explain return values, and a zero-param read tool is simple enough that the sentence covers the essentials. The only gap is the absence of any routing hint versus the status/doctor siblings.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless operation.

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 uses a specific verb ('List') and a precise resource ('serial device nodes visible on this machine'), so an agent knows exactly what comes back. It is implicitly distinct from siblings like print/render, but it never names or contrasts them, leaving differentiation to inference.

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 statement of when to call this versus alternatives such as labelprint_status or labelprint_doctor, which could plausibly surface similar machine information. The phrase 'visible on this machine' narrows scope but does not tell the agent when this tool is the right choice.

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

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

With no annotations, the description carries the full burden and does disclose the critical traits: it 'consumes physical labels' (irreversible real-world side effect) and is gated behind confirm=true, which is exactly the safety information an agent needs. It omits failure modes, printer selection, and whether copies multiplies consumption, so it is strong but not exhaustive.

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?

Three short sentences, front-loaded with the core action, then the physical-consumption warning, then the confirmation gate and preview routing. No filler and nothing buried.

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?

An output schema exists, so return values need not be described, and the high-risk behavioral notes are present. However, for a 9-parameter, 0%-coverage, unannotated tool, the dimension/quantity parameters and printer targeting are left for the agent to guess.

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 compensate. It explains the mode split (image_path is a pre-made PNG vs. title/body/QR being rendered) and the meaning of confirm, but leaves copies, density, width_mm, and height_mm entirely undefined in both schema and prose.

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+resource ('Print') and precisely delineates its two input modes: an existing PNG via image_path, or rendering title/body/QR inline. It explicitly positions itself against the sibling labelprint_render, so an agent can route without opening either schema.

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 a hard precondition ('confirm must be true') and a clear workflow ordering ('Preview with labelprint_render first'), which names the alternative tool explicitly. It stops short of stating when NOT to use it (e.g., when no printer is configured), so it is clear context rather than full when/when-not coverage.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the key non-mutating trait: no print is issued. It is silent on whether the render writes to disk (the out_path parameter implies a possible file side effect), what permissions are needed, or whether output is returned inline, leaving meaningful gaps for a tool with side effects.

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 short sentences, no filler, with the core action front-loaded and the disambiguating constraint second. Every clause earns its place.

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?

The output schema exists, so return values need not be explained. But for a 6-parameter tool with zero schema descriptions and no annotations, the description leaves three parameters and the file-write behavior unexplained, which is only marginally sufficient.

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% across 6 parameters, so the schema contributes no descriptions at all. The description names only title, body, and qr, leaving out_path, width_mm, and height_mm completely undocumented in either source.

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 specific verb (render) and resource (preview PNG) and enumerates the content it composes (title, body, and/or QR). The clause "Does not print" explicitly differentiates it from the sibling labelprint_print, so an agent can route between them without opening a schema.

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 phrase "Does not print" strongly implies this is the preview path and that printing belongs to another tool, which is useful routing context. However, it never names labelprint_print or states the when-to-use condition explicitly, so the guidance is implied rather than declared.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that media size is not fetched from the internet (local/offline behavior), but does not say whether 'opening' the printer has side effects, what happens if no printer is configured, or whether the operation is safe/read-only.

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 short sentences with the core action front-loaded. The trailing print/barcode guidance is somewhat off-topic for a status tool, adding minor noise, but overall it is tight.

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?

An output schema exists, so return-value explanation is not required, and the description names what data comes back. For a zero-parameter status tool this is nearly sufficient, missing only error/failure conditions and the safety profile that absent annotations would otherwise supply.

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?

The tool takes zero parameters and the schema is empty, so the baseline is 4. The mention of width_mm/height_mm refers to a different tool (labelprint_print) and is not a parameter of this one, but it does not misrepresent this tool's schema.

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 verb+resource ('open the configured local printer') and enumerates the returned data (identity, power, on-device media chip). An agent can distinguish it from labelprint_print or labelprint_render, though it never explicitly contrasts itself with the closest sibling, labelprint_doctor.

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 guidance ('If a barcode is present, match it against the local config table or pass width_mm/height_mm when printing') describes downstream printing behavior rather than when to call this status tool versus labelprint_doctor or labelprint_list_ports. No prerequisites, no when-not-to-use conditions.

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