run

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

With no annotations provided, the description carries the full burden, and it delivers. It discloses timeout behavior (task becomes blocked, never silently resubmitted), budget behavior (task failed with budget_exceeded), idempotency, verify enforcement ('worker cannot pass by editing them'), and the critical nuance that run() success only means SUBMITTED, not done. These are behavioral traits well beyond what any scaffold would imply.

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 front-loaded with the core purpose and is organized as a parameter-by-parameter list, making it scannable. It is long, but each line earns its place given 14 parameters and zero schema descriptions. A small deduction for length, but the structure is effective.

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 14 parameters, 0% schema coverage, no output schema, no annotations, and sibling tools for follow-up, the description is remarkably complete. It covers submission semantics, return meaning, timeout/budget edge cases, and explicitly points to wait()/inspect() for next steps. Nothing an agent needs to call it correctly is missing.

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%, so the description must compensate entirely, and it does. Each of the 14 parameters is explained with purpose and constraints—e.g., session_ref requires same agent+workspace, verify prefers list form, scope_files must be relative. The description adds meaning far beyond the raw schema names and types.

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-resource pair: 'Submit a complete work unit to a worker agent and return its task_id.' This clearly distinguishes the tool from siblings like agents, wait, inspect, and cancel by naming the submission action and the immediate return. The scope is 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 explicit requirements and behavior for each parameter, including constraints like 'complete work unit; do not ping-pong per file/line' and 'absolute or escaping paths are rejected.' It also tells the agent to follow up with wait()/inspect() after a successful submission, which is clear when-to-use guidance versus the siblings.

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