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

Annotations already declare destructiveHint=true, but the description adds far more: no trash, no undo, no recovery even via turbopress support, create_database only restores an EMPTY database, server-side name validation scoped to this subscription, and honest reporting semantics (explicit success confirmation vs. 'unverified' when the list could not be re-read).

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?

Long and dense, but front-loaded with the single most important fact (irreversible data loss) before procedure and response semantics. For a destructive irreversible operation the length is defensible; only minor tightening is possible.

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?

No output schema exists, and the description compensates by describing the response contract (explicit confirmation of removal, or 'unverified' if the list could not be re-read). Combined with preconditions and irreversibility warnings, an agent has everything needed to call this safely.

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 baseline is 3, but the description adds real semantics beyond the schema: the database name is validated server-side against this subscription's databases and deletion happens via the identifier from that list, so a guessed or foreign name never reaches the hosting system.

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?

Opens with a precise verb+resource: 'LÖSCHT eine MySQL-Datenbank samt Inhalt'. It explicitly positions itself against the sibling create_database ('der Weg zurück zu create_database') and distinguishes itself from other delete_* siblings by naming the exact object (database, not user/DNS/email).

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 explicit preconditions: run get_databases first to size the database and check for a WordPress installation, tell the customer both facts, and explicitly ask about their own backup. It also explains what NOT to infer (a previously unavailable list means nothing was deleted).

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