think

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

With no annotations provided, the description carries full burden and delivers substantial behavioral context: it explains computational resource usage ('local GPU', 'falls back to remote'), cost implications ('zero API costs'), model selection logic based on depth, and automatic thinking mode activation. It doesn't mention rate limits or error handling, but covers most key behavioral aspects.

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 well-structured with clear sections (purpose, usage guidelines, args, routing, returns, examples) and front-loaded key information. While comprehensive, some sections like 'ROUTING' could be more concise, but overall it maintains good information density with minimal redundancy.

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?

Given the tool's complexity (reasoning engine with resource management), no annotations, and 0% schema coverage, the description provides exceptional completeness: it covers purpose, usage, parameters, behavioral traits, routing logic, return format, and examples. The presence of an output schema reduces need to explain returns, and the description fills all other gaps effectively.

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 0% schema description coverage, the description fully compensates by providing detailed parameter semantics: it explains each parameter's purpose, marks 'problem' as required, describes 'context' as supporting information, and provides a comprehensive breakdown of 'depth' values with model specifications and behavior differences. This adds significant meaning beyond the bare schema.

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 clearly states the tool's purpose as 'Deep reasoning for complex problems using local GPU with extended thinking' and distinguishes it from siblings by specifying it's for 'complex multi-step problems requiring careful reasoning' rather than batch processing, delegation, or system operations. It explicitly contrasts with quick actions by emphasizing extended thinking.

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 includes a dedicated 'WHEN TO USE' section with explicit guidance: it lists specific use cases (architecture decisions, debugging strategies), provides clear alternatives (different depth levels), and distinguishes when to use this tool versus other approaches. The examples further clarify appropriate contexts.

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