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

Annotations only declare the safety profile (not read-only, not idempotent, not destructive, closed-world); the description adds the behavior an agent actually needs: quota charged UPFRONT, one operation per row, failed rows are not refunded, and rows per job are capped by plan. This is exactly the non-obvious cost/irreversibility context that annotations cannot convey.

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 dense sentences, front-loaded with the operation and inputs, then the cost/limit caveats, then the return value and next step. Every clause (upfront charge, no refunds, plan cap, status check) carries information an agent would otherwise have to discover.

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 mutating, quota-consuming job submission with no output schema, the description covers prerequisites, billing semantics, failure behavior, size limits, and the return value (job id) plus the follow-up tool. Nothing material is missing for correct invocation.

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 100%, so zpl, rows, dpmm, output, width_in and height_in are all documented in the schema itself; that sets the baseline at 3. The description reinforces the template-to-row placeholder relationship but adds no syntax, defaults, or constraints beyond what the schema already states, and says nothing about dpmm/output/dimensions.

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 ('Submit a bulk label production job') and immediately defines the two core inputs: a ZPL template with {{variable}} placeholders plus one data object per label. The closing pointer to bulk_status distinguishes it cleanly from that sibling and from bulk_list.

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 the prerequisite (an API key whose plan includes bulk jobs), the cost model, and the follow-up call ('check bulk_status, small jobs usually finish within seconds'). It does not explicitly say when to choose this over looping single-label submissions or point to a non-bulk alternative, so it stops short of full when/when-not guidance.

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