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

Annotations already declare destructive/non-idempotent/non-read-only, but the description adds real context: enforced permission/sender-role/team-review/quota/provider limits, the fact that cancelResponse cannot recall accepted emails, and where to verify delivery. The 'retry an unchanged request with identical values' note is a useful dedupe hint that sits alongside (not against) idempotentHint=false.

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?

Information-dense but front-loaded with the precondition, and each sentence carries operative content (confirmation gate, cardinality, enforcement, alternatives, status check, guide pointer). It is terser than an agent typically needs, with 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?

For a no-output-schema mutation with nested payload, the description covers the confirmation gate, failure/enforcement conditions, cancel path, retry rule, and where to observe delivery. Only the relationship between the named IDs and the `payload` wrapper is left implicit.

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 67%, and the description names required payload fields (threadId, messageId, expectedRevision, reviewHash), which adds value. However, these are nested inside the `payload` object rather than top-level, and the schema already documents `action`, `payload`, and `confirmed`, so the description only marginally exceeds 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 names the concrete action (sendResponse) and its key identifiers (threadId, messageId, expectedRevision, reviewHash), making the operation distinguishable from generic send tools. It leans on jargon rather than plainly stating 'sends an approved email reply,' so it is clear but not maximally self-contained.

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?

Explicit preconditions ('After showing the exact review to the organizer and receiving confirmation'), cardinality rule ('One approved response per incoming message'), retry semantics, and the cancelResponse alternative are all stated. It also routes the agent to getResponse/the conversation for status and to a workflow guide resource.

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