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

Annotations give only the generic safety flags, but the description adds what actually matters: it is an irreversible physical print that consumes labels, jobs are refused above 5000 labels, the confirmation code expires in 5 minutes, works once, and is bound to the exact key/org/station/printer/items/profile/sheet/copies/cut. It also clarifies it returns job_id/status and explicitly does not return a PDF.

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 purpose and no wasted sentences — every clause carries operational meaning. It is a dense run-on wall of text, though; the confirmation workflow, parameter rules, and return behavior would be easier to parse if grouped rather than delivered as one continuous block.

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 12-parameter, non-idempotent mutation tool with no output schema, the description covers the prerequisite, the two-call protocol, per-parameter conditional rules, limits, and the return value plus the follow-up polling tool. Nothing an agent needs to invoke it correctly is missing.

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 carries the full burden and does: station_id optional only when exactly one station is online, printer_id falls back to the station default, cut_between_labels defaults true, and the profile branching (profile_id+copies_per_label only vs. exactly one of item_ids/all_items plus order, sheet_number, quality, copies_per_label, start_position). It also notes duplicate ids are ignored and the 5000-label cap.

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 and resource — queue labels on a physical Print Station — and makes the two-step validate-then-confirm nature explicit. It never names the nearest siblings (print_labels, start_print_job, print_shipping_mark), so the agent must infer the distinction from the 'Print Station' / 'physical print' framing rather than being told.

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?

Explicitly sequences the workflow: first call validates without confirmation_code and does not queue; show the summary and wait for user yes; do not call again in the same turn; second call repeats args plus confirmation_code. It also names the follow-up tool ('Poll get_station_print_job until status is done, error, or expired') and the prerequisite ('Requires print.org'), leaving nothing to inference.

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