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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds substantive context beyond them: what is preserved (assigned users, devices, API key scopes), what breaks (scripts/SDK calls/agents targeting the old slug stop reaching the channel), and the failure condition (new slug already taken). This is exactly the kind of behavioral disclosure annotations cannot carry.

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?

Purpose is front-loaded, and each of the five sentences carries distinct information (scope, preservation, consequence, param patterns, failure, return). It is dense but not padded; slightly long, which keeps it from a 5.

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 mutation with full annotation coverage and an output schema, the description supplies the caveats an agent needs before invoking: preservation of attachments, breakage of old-slug senders, the failure mode, and the two valid parameter shapes. Nothing material is missing.

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%, and the schema itself documents the convoluted dual-mode slug semantics. The description restates the two identification patterns ('public_id or current_slug ... as slug' vs. 'current slug as slug and new name as new_slug') without adding syntax or normalization detail beyond what the schema already provides, so the baseline 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?

The description opens with a specific verb+resource ('Rename a channel by changing its slug') that immediately distinguishes it from siblings like rename_api_key, create_channel, or delete_channel. The exact mutation mechanics are stated, not implied.

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?

It clearly states when this applies and adds an explicit caution ('confirm with the user first') plus a concrete consequence for downstream senders. It does not name an alternative sibling (e.g., delete_channel vs. this rename), so it falls short of the explicit alternatives criterion for a 5.

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