Deletes the specified profile folder together with all its profiles.

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description still adds real value beyond them by disclosing the cascade scope (profiles inside the folder are destroyed) and the precondition that the ID must match an existing folder in the given workspace. It stops short of saying whether the deletion is recoverable, despite a recover_profile sibling existing.

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?

Two sentences, front-loaded with the destructive scope and with zero filler. The second sentence is slightly awkwardly worded ('must match the existing folder in the specified workspace') but remains compact and useful.

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?

With 100% schema coverage, full annotation coverage of the safety profile, and no output schema, the description supplies the one thing structured data cannot: what actually gets destroyed. The main residual gap is recoverability/irreversibility, which is relevant given the recover_profile sibling.

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 both parameters (including the -1 workspaceId default) are already fully documented in the schema, establishing the baseline of 3. The sentence about profileFolderId needing to match an existing folder adds a validation precondition, but it is framed as a general constraint rather than clarifying parameter behavior or format.

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+resource ('deletes a profile folder') and adds the critical scope detail that all contained profiles are deleted too, which distinguishes it in substance from the sibling delete_profile_folder. However, it never names that sibling explicitly, so the differentiation must be inferred from the 'and all profiles it contains' clause.

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 phrase 'and all profiles it contains' implies the use case (delete folder plus contents rather than folder alone), but there is no explicit when-to-use guidance, no mention of delete_profile_folder as the non-cascading alternative, and no note about prerequisites such as stopping running browser instances first.

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