spawn_subagent

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this thoroughly: no memory between calls, the agent has no other context than the task, side effects of `write_files:true` (saving code blocks into a work_directory that is auto-created), the default non-destructive behavior, and a detailed list of return fields. It even explicitly flags the destructive condition with a warning emoji. This goes well beyond what a typical description provides.

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 a single dense paragraph with five sentences, each earning its place: the core action, usage guidance, alternatives, a critical side-effect warning, and a complete return specification. It is front-loaded with the primary purpose and never meanders. No word is wasted.

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?

Despite having 7 parameters, nested objects, and no output schema, the description provides a comprehensive picture: use cases, alternatives, side effects, default behavior, and a full enumeration of return fields. This equips the agent to decide when to invoke the tool and understand its consequences, making it contextually complete for the tool's complexity.

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?

The schema has 100% parameter description coverage, so the baseline is 3. The description adds meaningful semantic context that enriches the schema: it explains that `task` should contain file paths and acceptance criteria because the agent has no other context, clarifies the default behavior of `write_files` in terms of resource usage ('adds tokens'), and states the auto-creation/default path for `work_directory`. These additions improve parameter understanding, though not every parameter gets extra treatment, hence a 4.

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 opens with a specific verb ('Spawn') and resource ('one AI agent with a predefined role + system prompt') and clearly states the action ('run it to completion on a single task'). It also distinguishes the tool from siblings by naming `parallel_agents` and `council` as alternatives for different use cases, which removes ambiguity about what this tool is for.

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 explicitly states when to use the tool ('Use when the work fits a clear role...') and provides concrete examples. It also tells the agent when NOT to use it and what to use instead ('For multi-agent TDD parallelism with quality gates, use `parallel_agents`. For multi-backend consensus on a question, use `council`.'). This is exactly the kind of when/when-not guidance the rubric rewards.

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