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

Annotations only declare destructiveHint=true, readOnlyHint=false and non-idempotency. The description goes well beyond: it enumerates honest execution outcomes (applied, failed with reason, expired, uncertain-but-decision-stands), explains the confirm:true gate and no-op preview, discloses admin-only access, and states two invariants (no self-decision; the queue never queues its own operations). This is exactly the behavioral context the agent needs for a destructive, non-idempotent operation.

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?

Content is front-loaded (purpose, then per-action semantics, then invariants, then usage and an example), and every clause carries load-bearing detail. It is nonetheless a dense, long single paragraph, and the trailing 'When to use'/'Example' lines partly restate the intro, costing some tightness.

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 6-parameter, multi-action, destructive tool this is complete: it covers permissions (admin-only), safety (confirm gate), execution semantics (applied/failed/expired/uncertain), decision constraints, and self-policy behavior. An output schema exists, so return-shape detail is correctly left out, and nothing an agent needs to invoke it correctly is missing.

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 100%, so the baseline is 3, but the description adds real semantics the schema lacks: the confirm:true requirement implies 'without it the call changes nothing and returns a preview naming the tool, target, requester and age', id is ignored by list, note stores with either decision, and status scopes the list. That exceeds what the field descriptions convey.

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 opening sentence names a specific resource (the workspace's governance approval queue) and explains its origin (requests a require_approval policy captured instead of running). The three actions are individually defined — list returns pending plus recently decided requests; approve records the decision then runs the captured call as the requester; deny closes it without running. An agent can distinguish this from every sibling (e.g. cancel_subscription, manage_members) without opening another schema.

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?

A dedicated 'When to use' block states the trigger (an admin viewing or deciding queued requests from the conversation rather than Settings → Governance) and the effect (approving runs the captured action). It also gives two hard exclusions: the requester can never decide their own request, and a require_approval policy on this tool blocks rather than queues it. Alternative paths and negative conditions are both explicit.

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