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

Goes well beyond the annotations (which only cover readOnly/openWorld/idempotent/destructive) by disclosing cost (1 credit per answered text, blanks and duplicates free), the 2-255 option limit, internal chunking at 40 (schema), the constraint that the model reads text only with no math/counting/dates, and that English works best. These are exactly the operational facts an agent needs before calling a paid classification tool.

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?

Purpose and return value are front-loaded, followed by usage, cost, and limits, so every sentence earns its place. It is delivered as a single dense block rather than broken into scannable clauses, which costs a little readability but nothing is redundant.

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?

With an output schema present, return-format detail is unnecessary, and the description still covers cost, limits, language constraints, and the sample-key parameter. For a paid, chunked batch-classification tool, nothing material for correct invocation 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 100%, so the baseline is 3, but the description adds real meaning: the worked example options list ['billing: invoices and charges', 'refund', 'bug', 'other'] and the rationale for the 'label: description' form (disambiguating short labels). That is more than a restatement of the schema's type/enum info.

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 ('sort a batch of short texts into one of your own categories') and pins the return shape ('the chosen option plus how confident the model is, not generated prose'), which separates it from prose-producing siblings like hunch_ask. An agent can tell what this tool produces without opening the 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 concrete use cases (route tickets, classify feedback, tag leads) and an explicit alternative with a trigger threshold: 'Prefer it to judging the texts yourself once there are more than about 25.' It never names a sibling tool (e.g. hunch_ask or hunch_multi) as the competing option, so routing among the hunch_* family still requires inference.

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