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

Annotations already declare destructive=true and idempotent=false, and the description goes far beyond them: an automatic verified backup precedes every change, deletion is aborted if no backup can be created or proven, deleted data is recoverable only via that backup, autosaves of the last 7 days are preserved, database size may not shrink immediately because no OPTIMIZE runs, and there is a hard rate limit of 5 runs per day.

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?

Front-loaded with the destructive scope and the backup guarantee before the finer caveats, and nearly every sentence carries operational weight. It is dense and slightly long for a single tool, with some repetition around the explicit-consent requirement for comments.

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, non-idempotent, open-world tool with no output schema, the description covers everything an agent needs: backup precondition, abort paths, multisite and no-op behaviour, partial-run outcome plus the instruction to tell the customer to rerun, and the daily run limit.

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: site_url is required specifically when multiple WordPress installations share a domain, and kommentare must only be set on explicit customer request. That meaning goes beyond the schema text, though domain itself gets no further elaboration.

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 and resource (Datenbank aufräumen) and enumerates exactly what is removed: ALL post revisions including the full version history, expired transients, and spam/trash comments only on request. It is clearly distinguishable from siblings such as clear_wordpress_cache, create_wordpress_backup, or delete_wordpress_backup.

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?

Explicitly says NOT to call it for inspection ("NICHT zum Nachsehen aufrufen") because anything to clean is secured and deleted immediately, and requires the customer's explicit wish to run. It also names exclusion conditions (Multisite, unreadable install, nothing to clean) where the tool exits without action, and separately gates the comment deletion on explicit customer consent.

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