spawn_agent

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

No annotations are provided, so the description carries the full behavioral burden, yet it only adds 'background' and 'backend runner'. It says nothing about the significant behavioral flags present in the schema — human-in-the-loop approval (hitl_enabled defaults true), permission bypass (skip_permissions), retry budget, or how a spawned session is later cancelled via kill_agent.

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?

It is a single front-loaded sentence with no filler, which is structurally sound. However, this brevity is under-specification rather than discipline — the one sentence is all the agent gets for a 9-parameter session-spawning tool.

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?

An output schema exists, so return values need not be explained, but everything else is missing: no annotations, no parameter documentation, and no lifecycle or safety context for an action tool that can spawn background agents with permissions skipped. It is far too thin 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?

Schema description coverage is 0% across 9 parameters, and the description explains none of them — model, agent_type, reasoning_effort, session_id, workspace_path, max_retries, hitl_enabled, and skip_permissions are all left undefined. 'Backend runner' loosely gestures at the runner parameter but adds no semantics beyond its name.

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 states a specific verb and resource ('create a new background subagent session') plus the target ('on the given backend runner'), so the core action is clear. It gives no differentiation from siblings such as execute_run, submit_goal, or list_agents, and the 'legacy' framing leaves the agent unsure how this relates to the newer execution path.

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?

'Legacy helper' hints that alternatives may be preferable but names none of them, and there is no statement of when to use this versus execute_run or submit_goal. The agent must infer the routing decision entirely on its own.

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