Decline Task

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

Annotations only declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false; the description adds real behavioral context beyond that — the submission is not executed, a window is not consumed, and the task id is preserved in the approval record for later inspection. The closing clause ('the same way a decline is inspected afterwards') is garbled enough that the retention guarantee is slightly muddled, keeping this from a 5.

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?

Three short sentences with the core effect front-loaded, but the final sentence is awkwardly worded and partly restates the retention point without adding clarity. Tightening it would improve both length and comprehension.

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 single-parameter action with annotations and no output schema, the description covers the main outcome and the record-retention side effect, which is most of what an agent needs. It omits what happens on an already-declined or already-approved task, whether declining is reversible, and what the tool returns, leaving gaps an agent may hit in practice.

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 only parameter documentation is the name task_id and its regex pattern. The description contributes indirectly by saying the task id is kept in the approval record, implying which identifier is expected, but it gives no format, sourcing, or failure semantics for a malformed or unknown id.

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?

States a specific action and its effect: it ends a submission without running it and without spending a window, which clearly delimits it from approve_task among the siblings. 'Internal approval card action' frames the surface it belongs to. It stops short of naming the sibling alternative explicitly, but the verb+resource+effect combination 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?

'Internal approval card action' implies the context in which it is used (from an approval card), and the mention of not spending a window hints at the cost tradeoff versus approving. There is no explicit when-to-use versus approve_task, and no stated preconditions such as the task having to be pending.

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