Send work to a background agent

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

Annotations already flag idempotentHint=true and openWorldHint=true, and the description reinforces idempotency with concrete retry semantics (generate requestId once, reuse on retry, inspect rather than resend). It also adds context annotations cannot express — the work continues independently when Desktop apps close or freeze. The gap is destructiveHint=true: nothing explains what side effects are possible or what authorization guarantees make them safe, so the strongest annotation hint goes unelaborated.

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?

Four sentences, front-loaded with the positive action before the exclusions and the retry rule, with no filler. Mild cost: 'explicitly' appears three times and the authorization caveat is restated in both description and schema, making it slightly denser than needed.

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 destructive, open-world, idempotent queued job with no output schema, the description covers preconditions, retry discipline and the recovery tool. The one omission is what a successful call yields — a delivery identifier an agent then passes to read_worker_delivery — which is only inferable from the recovery instruction rather than stated.

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 baseline is 3. The description still adds meaning beyond the schema for requestId — generate once, persist across retries, and resolve ambiguity via read_worker_delivery rather than a new ID — which is a usage contract the pattern/format definition cannot convey. The 'explicitly authorized project' framing similarly adds an authorization bar to cwd that the schema only calls 'absolute path'.

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 names a specific verb and resource — queue authorized work to a separate background CLI worker in a selected project — and immediately draws the boundary against the Desktop-chat siblings ("does not address, open or resume any Desktop chat"). Between that exclusion and the pointer to worker-relay tools, an agent can distinguish this from delegate_to_codex, send_to_codex_thread and start_codex_thread without opening a schema.

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?

It gives explicit when-not guidance (no Desktop chat substitution), an explicit recovery path for a specific failure mode (uncertain result → read_worker_delivery, never resend under another ID), and routes follow-on delegation to the worker-relay tools. The preconditions — explicitly authorized project and explicitly selected cwd — are stated up front.

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