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

The description adds substantial behavioral context beyond annotations: invalid output returns 422 without charge, exhausted daily capacity returns 503 without charge, no calibrated probabilities are provided, and calls are paid via x402 with a specific retry mechanism. This is exactly the operational detail an agent needs for a paid, external-model 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?

The description is dense but front-loaded: classification task, inputs, outputs, error behavior, model/runtime, capacity, pricing, and HTTP equivalent are all delivered without filler. Every clause earns its place for an agent that must decide whether and how to call the tool.

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?

There is no output schema, but the description explains the return shape: one label or all applicable labels, always from the supplied list, plus a one-sentence reason. It also covers failure modes and payment flow, leaving no critical invocation detail 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 75%, so the schema already documents text length and label count. The description compensates for the undocumented multi_label parameter by explaining that multi_label=true returns every applicable label, though it does not elaborate on the optional instructions parameter beyond what the schema provides.

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 states a specific verb and resource: zero-shot classification of text into user-provided labels. It clearly distinguishes the operation from siblings like ai_extract and ai_embed by focusing on constrained label selection and explaining both single-label and multi-label behavior.

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 description gives clear usage context: send text plus 2-50 labels, set multi_label=true to return every applicable label, and expect a one-sentence reason. It does not explicitly compare against alternatives such as ai_extract or explain when not to use classification, which keeps it below a 5.

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