delegate

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

With no annotations provided, the description carries full burden and delivers comprehensive behavioral disclosure. It explains the 3-tier model selection logic, routing decisions based on content size and GPU availability, fallback mechanisms, load balancing, and what the return includes (metadata footer). This goes well beyond basic function description to reveal how the tool behaves under different conditions.

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 logic, returns, examples) and every sentence adds value. At ~300 words, it's appropriately detailed for a complex tool with 9 parameters. Minor deduction because some sections could be slightly more concise (e.g., the 'WHEN TO USE' bullets have some 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?

For a complex tool with 9 parameters, 0% schema coverage, no annotations, but with an output schema, the description provides complete context. It covers purpose, usage guidelines, detailed parameter semantics, routing behavior, return format, and includes examples. The output schema handles return values, so the description appropriately focuses on usage and behavior.

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?

Given 0% schema description coverage and 9 parameters, the description compensates fully by providing detailed semantics for each parameter. It explains how 'task' determines model tier with specific mappings, clarifies 'model' accepts both tier names and natural language descriptions, defines the purpose of 'language', 'context', 'symbols', 'include_references', and 'backend_type', and notes which parameters are required vs optional.

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: 'Execute a task on local/remote GPU with intelligent 3-tier model selection. Routes to optimal backend based on content size, task type, and GPU availability.' This specifies the verb (execute), resource (GPU), and key differentiators (3-tier model selection, backend routing) that distinguish it from sibling tools like 'think' or 'models'.

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 'WHEN TO USE' section provides explicit guidance with three bullet points covering local/private processing, specific task types (code review, generation, analysis), and general local hardware preference. This clearly tells the agent when to choose this tool over alternatives like 'think' (which might be for pure reasoning) or remote-only tools.

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