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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds the material behavior that matters — the action is queued, never executed, and derived_from is checked against a 15-minute read window for tainted inputs surfaced in tainted_inputs for the reviewer. It does not cover re-submission behavior when the same idempotency_key is reused, nor what compensation_payload does on rollback.

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 short sentences, front-loaded with the core behavior and the approval constraint before the taint detail. Minor waste in the awkward line break and parenthetical phrasing, but essentially no filler.

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?

An output schema exists, so return values like tainted_inputs needn't be documented. For an 8-parameter mutation-queueing tool, though, the description leaves the reviewer/agent without guidance on idempotency_key semantics and the role of compensation_payload, which are significant gaps for correct invocation.

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% across 8 parameters, so the description must carry the load — yet it explains only derived_from (including its taint-checking semantics and read window). Required fields action_type, target_url and idempotency_key, plus payload, namespace, session_batch_id and compensation_payload, get no meaning added at all.

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 verb and resource ("Queue an external action") plus the decisive scope qualifier "for human approval; never executes directly." That distinguishes it from direct-execution tools and from generic human-review siblings, though no sibling is named explicitly.

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?

Usage is implied by the phrase "for human approval" — the agent can infer this is the path when an external side effect needs gating rather than immediate execution. However, there is no explicit when-not guidance or pointer to alternatives such as request_human_review or agent_escalate_to_human, so the routing decision is left partly to inference.

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