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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety bar is partly met. The description adds genuinely non-derivable behavior: the delete is non-cascading ('records stay as they are') and it carries a per-call cost that is waived on failure — exactly the kind of operational detail annotations cannot express. It stops short of stating what happens on a repeat delete or a nonexistent segment.

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 clauses, front-loaded with the action, and both the non-cascade note and the cost are stated in minimal words. Nothing is wasted and nothing essential is buried.

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 2-parameter, non-nested tool with no output schema and annotations covering the destructive profile, the description supplies the two surprises an agent needs (no cascade, failure is free). The remaining gap is identification semantics — how to obtain a valid segment name/id and the object-type requirement.

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 only 50%: `segment` is documented as 'Name or id', but `object` (enum contact/company/deal) has no description. The description never mentions the object type or the name-vs-id resolution, so it does not compensate for the coverage gap on a tool where choosing the wrong object could target the wrong segment.

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?

Specific verb+resource ('Delete a saved segment') with an added scope clarification that the underlying records survive, which distinguishes this from record-deletion siblings. It does not explicitly differentiate from the adjacent crm_delete_tag / crm_delete_pipeline / crm_delete_field siblings, but the resource is unambiguous.

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?

Usage is only implied: you call it to remove a saved segment while keeping the records. There is no explicit when-to-use vs. crm_list_segments / crm_save_segment, no prerequisite (e.g. does the segment need to exist, must you know its id from crm_list_segments), and no note on whether the segment can be recreated.

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