Delete old WordPress post revisions for a site while keeping a specified number per post. Reduce database clutter by retaining only the revisions you choose.
Delete old post revisions
| Name | Required | Description | Default |
|---|---|---|---|
| keep | No | Revisions to keep per post | |
| site | Yes | Site id (see list_sites) |
Changes observed during successful MCP inspections.
v3.4.0Input schema / properties / siteAdded value: +{
+ "description": "Site id (see list_sites)",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "site"
+]v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies destructive data loss but never states that revisions are permanently removed and unrecoverable, what permissions are required, whether the operation touches all posts on the site, or how the default retention count interacts with the deletion.
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?
A single four-word phrase, front-loaded with the action and resource and carrying no filler. It is efficient, though it is arguably too terse to be maximally 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?
For a destructive, unrecoverable maintenance operation with no annotations and no output schema, the description should disclose irreversibility, scope across the site, and whether a dry run or confirmation exists. None of that is present.
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 description coverage is 100%: the schema already documents 'keep' (revisions to keep per post, default 5) and 'site' (site id, see list_sites). The description's word 'old' loosely gestures at the retention semantics but adds no syntax, format, or default behavior beyond the schema, so the baseline of 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 (Delete) and resource (old post revisions) with a scope qualifier ('old') that maps to the keep parameter. It is clear on its own, but it never distinguishes itself from the similarly-named sibling mcp_clean_comments or explains how it relates to revision listing/restore tools.
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?
No when-to-use guidance, no prerequisites, no mention of alternatives or when deletion should be avoided. The agent is left to infer entirely from the name that this is a maintenance/cleanup operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.