deepseek_task

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

With no annotations, the description carries the burden of explaining behavior. It does this well: it clarifies the one-shot execution model, the return style ('returns the final answer (with reasoning, if produced)'), and the default/environment-configurable model. It doesn't cover failure modes or side effects, but the behavior of a delegation tool is well-scoped.

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 modestly long but every sentence carries weight: the first defines the operation and result, the second clarifies the use cases and scope, and the third provides model configuration with an override example. It is structured and front-loaded, without filler.

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?

The tool is a one-shot delegation with no output schema and no siblings. The description adequately conveys its oracle-style behavior, expected result, and the extent of inputs. It could give example output shape or failure handling, but not that could be unique; the essentials are present.

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 all parameters are already documented. The description restates some parameter-level guidance ('supplies a task description and optional context') but adds no new meaning beyond the schema. The mention of the env-var model override is useful but relates to configuration rather than the input parameters. Baseline 3 is appropriate.

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 uses a specific verb ('Delegate'), a clear resource ('sub-task to DeepSeek as a sub-agent'), and explicitly frames the return value ('get back its result'). It further distinguishes the tool by noting the work is done independently as a sub-agent without polluting the main conversation — making the purpose unambiguous.

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 provides a clear list of when the tool is appropriate (research, drafting, code review, refactoring, analysis, writing, any self-contained task) and states that it is for independent work. It does not explicitly list exclusions or alternatives, but there are no sibling tools to differentiate from, so the guidance is contextually sufficient.

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