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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is largely covered. The description still earns credit by disclosing the scope of destruction — the contact is removed from the list but preserved in the account — which is exactly the kind of consequence detail an agent needs before invoking a destructive write.

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?

A single front-loaded sentence plus the endpoint template, with the WRITE marker and the containment clarification placed first. No filler and nothing redundant.

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 two-parameter destructive write with no output schema, the description plus annotations cover what is removed, what is preserved, and that the call is idempotent. Only parameter-level detail (ID formats, error behavior) is left entirely to the schema, which is a minor gap.

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 description carries the burden for both parameters but adds little: 'one contact from one list' only loosely maps to list_id and contact_id, and the endpoint template restates the same two identifiers without type, format, or constraint detail. The heavy lifting is left undone.

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 states a specific verb and resource (remove one contact from one list) and immediately scopes it by clarifying the contact stays in the account, which separates it from siblings like sendlane_unsubscribe_contact and sendlane_remove_contact_tag. An agent can identify the operation without opening the 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?

The parenthetical '(the contact stays in the account)' implies this is a list-membership removal rather than an unsubscribe, which gives some contextual steering. However, it never explicitly names an alternative tool or states when to prefer this over unsubscribe_contact or remove_contact_tag, so the guidance remains inferred rather than stated.

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