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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds valuable non-blocking behavior and the queuePosition semantics (1 = next, null once started), which go beyond the annotations. It could mention additional status values beyond 'queued', but the provided context is strong.

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?

Two sentences with no filler. The core purpose is stated first, followed by essential usage nuance (non-blocking, polling) and queue detail. Every sentence contributes to the agent's correct invocation.

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?

The description covers the essential invocation details: how to identify the task, when to poll, and what queuePosition means. With no output schema, it could have briefly noted the possible status values (e.g., queued, running, completed) to set expectations, but the provided guidance is sufficient for an agent to call it correctly.

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 100%, so each parameter is already fully documented. The description adds the alternative usage pattern (any of the three identifiers) and the linkage to assign_to_coding_agent, but this is largely redundant with the schema text for codeAgentTaskId and taskId. No meaningful extra value beyond the schema.

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 clearly states the verb 'Get' and the resource 'current execution status of a coding agent task', with explicit lookup keys (codeAgentTaskId, taskId, taskKey). It distinguishes itself from siblings like assign_to_coding_agent by being the status getter, leaving no ambiguity about its role.

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 explicitly tells the agent to use this after assign_to_coding_agent, clarifies it is non-blocking and should be polled, and provides context on queue behavior. This gives clear when-to-use guidance and sets expectations for repeated calls, differentiating it from a one-shot operation.

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