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

Adds substantial context beyond the annotations: a required print.org scope, a 50-page ceiling derived from carton range × sets, and the preferred output channel (a signed https download_url on a cloudlabels.io host). It does not explain why destructiveHint is set true, which an agent might reasonably wonder about for a print operation.

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 hard prerequisite ('Requires print.org') and then packed with terse, non-redundant facts. Dense but every sentence carries information; 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?

Covers auth scope, page limits, and the return channel, which is good for a tool with no output schema, but with 15 undocumented parameters and no annotation explanation of the destructive flag, an agent still lacks enough to fill the fill-in fields confidently.

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?

With 15 parameters and 0% schema coverage, the description carries the full burden, yet it explains only customer_id, order_id's auto-fill behavior, profile_id implicitly, and the sets/carton page interaction. Fields like pcs, meas, size, color, quality, net_weight, gross_weight, and order_number get no meaning at all.

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 ('Print a shipping-mark profile with fill-in fields') and rules out one adjacent concept with '(not the Items table)'. It is distinguishable from generic printing, but it does not explicitly contrast with close siblings like print_order_shipping_marks or create_shipping_mark_from_template.

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 real operational guidance — ask the user for missing fill-in values, omit order_id-derivable arguments, prefer download_url — but all of it is about how to call the tool, not when to choose it over the shipping-mark and label printing siblings. Tool selection is left to inference.

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