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

Annotations already flag destructiveHint=true, but the description goes further with what the agent cannot learn from them: 'Anything still using it starts failing immediately', 'cannot be undone', and the 'Manage API keys' permission granted on the approval screen. That is exactly the extra context a destructive call 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?

Three sentences, irreversibility and blast radius front-loaded, then the guardrail, then the permission prerequisite. No sentence is redundant and nothing 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?

An output schema exists so return values need no explanation, and the description covers the remaining gaps an agent needs: irreversibility, downstream breakage, the confirmation step, and the required permission. Nothing material is missing for a single-parameter destructive tool.

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 100%, so the single public_id parameter and its 16-character constraint are already documented, including its 'from list_api_keys' provenance. The description's only added signal is the instruction to confirm the key name with the user, which is a procedural caution rather than parameter semantics, 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?

States a specific verb ('Permanently delete') and resource ('ActivitySmith API key') in the first four words, which cleanly separates it from create_api_key, rename_api_key and list_api_keys without needing to name them.

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 a concrete precondition ('Confirm the key name with the user before deleting a key you did not create in this session') and a permission requirement, which tells the agent when the call is legitimate. It stops short of naming an alternative such as rename_api_key when the intent is a modification rather than removal.

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