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

Annotations already carry destructiveHint=true, and the description adds rich context beyond it: permanence ('Permanently remove'), the observable outcome for the user ('They can no longer sign in'), and a non-destructive preview mode when confirm is absent. It also scopes the blast radius by stating what survives deletion, which is exactly the kind of context a destructive tool needs.

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?

Four short sentences, each earning its place: core purpose, consequence, preview behavior, and blast-radius boundary. The decision-relevant fact that this is destructive is front-loaded, and the confirmation requirement is stated early rather than 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 destructive 5-parameter tool, the description covers purpose, the safe invocation flow, permanence, and what is not deleted, while the 100%-covered schema handles parameter semantics and the annotations handle safety flags. The one gap is that no output schema exists and the description never says what the preview response actually contains, though confirmName's 'copied from the preview' hints at its content.

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 100%, with all five parameters (userId, confirm, confirmName, dashboardId, customerRecordId) already documented. The description's preview statement is redundant with the confirm parameter's schema text and adds no new parameter-level meaning, so the high-coverage baseline of 3 applies.

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 action ('Permanently remove one login from a customer') with a concrete consequence ('They can no longer sign in'). The closing sentence ('The customer itself and their data access rule remain') differentiates it from the sibling delete_customer, so an agent can pick the right deletion tool even without inspecting 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?

Gives clear operational context: calling without confirm returns a preview, pointing to the two-call preview-then-confirm flow that the confirm/confirmName params enforce. It implies a boundary against customer-level deletion but never explicitly names delete_customer as the alternative when the entire customer must be removed.

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