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

Annotations declare readOnly/idempotent/non-destructive, and the description adds genuinely useful context beyond them: the classification is rule-based with no AI model, the same input always yields the same answer, risk moves down a fixed evidence ladder, and evidence types (interviews, signups, deposits, payments) affect scoring. It does not disclose size limits, pagination, or latency, but for a pure-compute read tool the behavioral picture is largely covered.

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 purpose clause is correctly front-loaded, and enumerating return contents has value given there is no output schema. But the body is a single run-on sentence that strings nine output categories together with commas, making it hard to scan. A structured list of the return fields would convey the same information more efficiently.

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 complex tool (18 parameters, no output schema) the description carries the return-value burden well, spelling out the classification output, scoring dimensions, red flags, stage, build rules and weekly test, plus the determinism guarantee. What it omits is any statement of expected input shape or how the many optional inputs change the output, but overall it is sufficient to invoke the tool correctly.

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 description coverage is 94%, so the schema already explains nearly every parameter. The description adds only one semantic layer over it: that the evidence parameter feeds the fixed evidence ladder that lowers risk and that billing/price/evidence inputs shape the score. That is a marginal addition on top of an already-complete schema, matching the baseline.

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 opening clause gives a specific verb+resource: classify a product or business idea using fixed rules (explicitly no AI model). It goes on to enumerate concrete outputs (10 product types, 9 buyer types, 10 scored assumptions, riskiest assumption, red flags, stage, build rules, weekly test). However, it never contrasts itself with siblings like validation_plan, kill_or_continue or explain_method, so the agent must infer where classification ends and those begin.

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?

There is no when-to-use, when-not-to-use, prerequisite, or named alternative anywhere in the description. The closest thing is the implied flow that evidence gathered lowers risk along a ladder, but that describes behavior, not tool selection. An agent gets no help choosing between classify_idea and its six siblings.

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