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

With annotations only covering safety hints, the description adds real behavior: it returns 'go, stop, or wait plus approval_id', the timeout policy is 'stop', and it must be followed by polling get_approval. That is substantive context an agent cannot get from readOnlyHint/destructiveHint. It omits what happens on denial or how approval_id is consumed.

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?

Terse and dense with no filler; nearly every clause carries an instruction (return values, timeout, polling, enforcement). The lead sentence 'Same as check_action (Ask)' wastes the highest-value position on a pointer instead of a self-contained statement, which is the main structural weakness.

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 5-parameter, 3-required gate with no output schema, the description compensates well on outputs (go/stop/wait, approval_id, timeout) but leaves the input contract completely unexplained. Because required parameters like action_type and preview are undocumented, the definition is not quite sufficient to invoke the tool 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 coverage is 0% across 5 parameters (3 required), and the description explains none of them — risk, target, preview, summary, and action_type go entirely undefined in structure or format. An agent must guess what values are valid, particularly for action_type and risk. Marginal semantics leak from words like 'action' and 'preview' in the prose, but the required-parameter burden is essentially unmet.

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 scope: 'Stop and ask before a consequential non-money action.' This clearly distinguishes it from money-related siblings like check_transfer and create_checkout. The opening 'Same as check_action (Ask)' is a cross-reference rather than a definition, which slightly muddies an otherwise clear purpose.

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 usable trigger ('consequential non-money action') and an explicit exclusion (non-money, and it does not forward email/Slack/CRM). It also names the enforcement alternatives email.send, slack.post, and crm.write. It does not, however, say when to prefer ask_human over sibling check_action or attach_human.

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