Delete or trash authorized WordPress content by resource and ID; use force=true for permanent deletion when required for media or terms.
Trash an object when supported. force=true permanently deletes it. Media and terms generally require force=true. Only delete objects authorized by the operator.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| site | No | Configured site name from aism_sites. Omit for the default site. | |
| force | No | ||
| resource | Yes |
Changes observed during successful MCP inspections.
v1.4.1Input schema / properties / siteAdded value: +{
+ "description": "Configured site name from aism_sites. Omit for the default site.",
+ "pattern": "^[a-zA-Z0-9_.-]{1,64}$",
+ "type": "string"
+}v1.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=false, so the bar is lower; the description still adds real context beyond them — that deletion is a trash operation unless force=true, that some resource types require force, and that operator authorization is a precondition. It does not say whether trashed items are recoverable or what happens on failure.
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?
Three tight sentences, front-loaded with the default trash behavior before the force override. Hedges like "when supported" and "generally" cost a little precision but no sentence is wasted.
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?
Adequate for a destructive 4-parameter tool whose annotations cover the safety profile, but an agent still lacks recoverability details, error behavior, and any indication of what the call returns, which matters for a delete operation.
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 only 25%, but the description compensates for the most consequential parameter by explaining force=true's permanent-deletion effect and its resource-dependent requirement. The `id` and `resource` parameters receive no semantic explanation (e.g., valid resource names), leaving a gap.
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 (trash/delete) with the key distinction between soft trash and permanent deletion via force. The resource is generic ("an object") and resolved only by the `resource` parameter, so the tool isn't sharply differentiated from aism_content_update without reading the schema, but the delete semantics are clear.
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 useful conditional guidance (media and terms generally need force=true) and an authorization constraint, but never states when-not to use it or which sibling to prefer for retrieval/verification before deleting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.