Queue another instruction in the same native session

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

Adds genuinely useful behavior beyond the annotations: the call returns durable operation/rpc IDs and a queue receipt, not execution completion, which frames it as an async accept/reject rather than a synchronous run. It also gives retry-safety guidance for the idempotencyKey. It does not explain what the destructiveHint=true mutation actually destroys or whether queueing displaces pending work, leaving one meaningful gap against a destructive, open-world annotation set.

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 tight sentences, front-loaded with the action and scope, then return semantics, then disambiguation and retry rule. No filler; the only thin spot is the unelaborated 'Distinct from steer_run' clause, which reads as a placeholder.

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?

There is no output schema, so the description usefully covers return values, and it addresses the retry/uncertainty case that matters for a destructive, open-world, non-idempotent call. What it omits is the operational difference from steer_run and what happens when the referenced run is no longer active.

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 only 25%, and runId and content carry no schema description at all. The description partially compensates by explaining the idempotencyKey contract ('reuse the same idempotencyKey and never resubmit under another key') and implying content is a next-turn instruction, but it says nothing about runId or the accepted content shapes, so the low-coverage gap is only half filled.

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 verb+resource+scope is specific: 'Append a next-turn instruction while the run is active,' and it names the sibling it is not ('Distinct from steer_run'). However, it asserts the difference without saying how queue_run differs from steer_run, so the disambiguation is labeled rather than explained.

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?

Gives a precondition ('while the run is active') and concrete disposition guidance for the failure case ('Query queue/history after an uncertain response; reuse the same idempotencyKey and never resubmit under another key'). It names steer_run as the alternative but never states the condition that selects one over the other, which keeps it short of a 5.

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