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

Annotations indicate mutation and destructiveness, and the description adds meaningful behavioral context: trust the returned actual_tool_output instead of adding a state-recovery call, follow retry/idempotency rules, and require fresh user confirmation before invoking. This goes well beyond the annotation flags and provides safety-relevant guidance.

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?

The core purpose is front-loaded in the first sentence, and the remaining guidance is clearly labeled with Prerequisite, Canonicality, Idempotency, and Confirmation boundary. The line 'plus every prerequisite stated above' is vague, but overall the description is compact and scannable.

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 destructive, no-output-schema tool, the description provides prerequisites, confirmation requirements, retry guidance, and output-trust behavior. It lacks explicit sibling comparison and a precise definition of formationId, but the essential operational context is present.

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 low at 33%, with only _corply_context documented. The description implies the email belongs to the cofounder being nudged, but it never explicitly maps formationId or explains its role in the operation, so it only partially compensates for the schema gap.

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?

Description states a specific action ('Re-send the signature reminder email'), a specific target ('a cofounder who hasn't signed yet'), and a clear condition ('Only when the lead asks'). This clearly differentiates it from siblings like request_signature or invite_cofounders.

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 explicit usage conditions: only when the lead asks, only with fresh explicit confirmation, and only with authenticated active organization access. It does not explicitly name alternative sibling tools or spell out negative cases beyond 'hasn't signed yet', so it stops slightly short of full routing guidance.

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