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

With no annotations, the description carries the full burden and does well: it discloses the delete is soft, that the lead vanishes from the pipeline, that restoration is possible only through support (a real constraint the agent should communicate), and that explicit user approval is required. It stops short of stating return value, permission requirements, or what happens to associated notes/activities.

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 tight sentences. The behavioral consequence ('disappears from the pipeline') and the constraint ('restorable by support only') are front-loaded before the approval gate, so the most decision-relevant facts land first.

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 single-parameter mutation tool with no output schema and no annotations, the description covers the essentials an agent must know: soft semantics, restore path, and the approval prerequisite. Only the return value and side effects on related records are unaddressed, which are secondary here.

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%, so the schema only tells the agent that `id` is a required string. The description never clarifies that this is the lead ID (versus, say, an activity or stage id), nor its format. Because there is only one, highly inferable parameter in a tool whose name names the resource, the gap is minor but real.

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 ('Soft-delete a lead') and immediately clarifies the semantics of that verb — the lead disappears from the pipeline. This cleanly distinguishes it from siblings like delete_crm_stage, crm_update_lead, and archive, which would otherwise be plausible alternatives.

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?

Explicitly names the prerequisite tool path: only call after the user reviewed `preview_delete_crm_lead` output and explicitly approved. This is exactly the when-to-use/when-not-to-use guidance an agent needs for an irreversible-feeling operation.

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