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

Annotations only declare destructive/idempotent/readOnly hints; the description goes well beyond them. It discloses that no content is lost, that sub-folders move up and take the next free slug, that old addresses forward until reassigned, and that the response names every ended and started address — genuinely rare, decision-relevant detail for a destructive tool.

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?

The core consequence is front-loaded well, but the paragraph is dense and somewhat sprawling, and the address-tracking idea is stated twice ('old workspace-host address forwards to its new one' and 'names every address that ended and every one that started'). It is information-rich but not tight.

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, no-output-schema tool, the description covers preservation semantics, slug reassignment, address forwarding, permission requirements, and the workspace scoping needed to call it correctly. Nothing essential to correct invocation 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 coverage is 100%, with folder_id and workspace_id fully documented in the schema, including the multi-workspace requirement. The description adds no syntax or format detail about the parameters, so the baseline 3 applies where the schema does the heavy lifting.

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+resource up front ('Delete a folder') and immediately scopes it by explaining that contents survive and move to the parent. An agent can distinguish this from move_folder, rename_folder, set_folder_slug, and delete_site without opening any 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?

It provides a permission prerequisite ('Only someone who can manage the folder may delete it') and notes the Marketing-folder special case, which is useful usage context. However, it never says when to choose this over alternatives like move_folder or move_site_to_folder when the goal is reorganization rather than removal, so routing guidance is only implied.

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