Skip to main content
Glama

wp_delete_post

Delete WordPress posts permanently or move them to trash. Specify a post ID and choose between trash or force deletion for content management.

Instructions

Deletes a WordPress post with options for trash or permanent deletion. Includes safety confirmations and detailed feedback on the deletion action.

Usage Examples: • Trash a post: wp_delete_post --id=123 (moves to trash) • Permanent deletion: wp_delete_post --id=123 --force=true • Bulk operations: Use multiple calls with different IDs

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteNoThe ID of the WordPress site to target (from mcp-wordpress.config.json). Required if multiple sites are configured.
idYesThe ID of the post to delete.
forceNoWhether to bypass trash and force deletion (default: false, moves to trash).

Implementation Reference

  • Core handler function that executes the wp_delete_post tool logic: validates the post ID, calls WordPressClient.deletePost (with optional force for permanent delete vs trash), formats success response with details or handles specific errors like 404.
    export async function handleDeletePost(
      client: WordPressClient,
      params: { id: number; force?: boolean },
    ): Promise<{ deleted: boolean; previous?: WordPressPost } | string> {
      try {
        const postId = validateId(params.id, "post ID");
        const result = await client.deletePost(postId, params.force);
    
        if (result.deleted) {
          const action = params.force ? "permanently deleted" : "moved to trash";
          let response = `✅ **Post ${action} successfully**\n\n`;
    
          if (result.previous) {
            response += `**Title**: ${result.previous.title.rendered}\n`;
            response += `**ID**: ${result.previous.id}\n`;
          }
    
          if (!params.force) {
            response += `\n**Note**: Post moved to trash. Use \`force=true\` to permanently delete.`;
          }
    
          return response;
        } else {
          return `Failed to delete post with ID ${params.id}. It may not exist or you may not have permission.`;
        }
      } catch (_error) {
        if (_error instanceof Error && _error.message.includes("404")) {
          return `Post with ID ${params.id} not found. Please verify the ID and try again.`;
        }
        throw new Error(`Failed to delete post: ${getErrorMessage(_error)}`);
      }
    }
  • PostTools class method that acts as the bound handler for wp_delete_post, extracts and type-casts input parameters from MCP call, then delegates to the core handleDeletePost implementation.
    public async handleDeletePost(
      client: WordPressClient,
      params: { id: number; force?: boolean } | Record<string, unknown>,
    ): Promise<{ deleted: boolean; previous?: WordPressPost } | string> {
      // Extract only the relevant parameters
      const deleteParams: { id: number; force?: boolean } = {
        id: params.id as number,
      };
    
      if (params.force !== undefined) {
        deleteParams.force = params.force as boolean;
      }
    
      return handleDeletePost(client, deleteParams);
    }
  • MCPTool schema definition for wp_delete_post including name, detailed description with usage examples, and inputSchema specifying required 'id' (number) and optional 'force' (boolean).
    export const deletePostTool: MCPTool = {
      name: "wp_delete_post",
      description:
        "Deletes a WordPress post with options for trash or permanent deletion. Includes safety confirmations and detailed feedback on the deletion action.\n\n" +
        "**Usage Examples:**\n" +
        "• Trash a post: `wp_delete_post --id=123` (moves to trash)\n" +
        "• Permanent deletion: `wp_delete_post --id=123 --force=true`\n" +
        "• Bulk operations: Use multiple calls with different IDs",
      inputSchema: {
        type: "object",
        properties: {
          id: {
            type: "number",
            description: "The ID of the post to delete.",
          },
          force: {
            type: "boolean",
            description: "Whether to bypass trash and force deletion (default: false, moves to trash).",
          },
        },
        required: ["id"],
      },
    };
  • Registration of wp_delete_post handler in PostTools.getHandlerForTool switch statement: maps tool name to this.handleDeletePost method, which is then attached during getTools() for MCP tool registration.
    private getHandlerForTool(toolName: string) {
      switch (toolName) {
        case "wp_list_posts":
          return this.handleListPosts.bind(this);
        case "wp_get_post":
          return this.handleGetPost.bind(this);
        case "wp_create_post":
          return this.handleCreatePost.bind(this);
        case "wp_update_post":
          return this.handleUpdatePost.bind(this);
        case "wp_delete_post":
          return this.handleDeletePost.bind(this);
        case "wp_get_post_revisions":
          return this.handleGetPostRevisions.bind(this);
        default:
          throw new Error(`Unknown tool: ${toolName}`);
      }
    }
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: includes safety confirmations, provides detailed feedback on deletion action, explains the default behavior (moves to trash when force=false), and mentions bulk operation capability. It doesn't cover permissions needed or rate limits, but provides substantial operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with a clear purpose statement followed by usage examples. The examples are helpful but could be more concise. The structure is front-loaded with the core functionality stated first, though the examples section could be integrated more tightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no annotations and no output schema, the description provides good operational context but lacks information about return values, error conditions, or what happens to related content (comments, revisions). It covers the deletion mechanics well but leaves gaps in the complete usage picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema - it mentions the 'force' parameter in examples but doesn't provide additional semantic context. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Deletes') and resource ('a WordPress post'), specifying it's for deletion with options for trash or permanent removal. It distinguishes from sibling tools like wp_delete_page, wp_delete_comment, etc., by explicitly targeting posts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (deleting WordPress posts) and includes usage examples for different scenarios (trash vs permanent deletion, bulk operations). However, it doesn't explicitly state when NOT to use it or mention alternatives like wp_update_post for modifying instead of deleting.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/docdyhr/mcp-wordpress'

If you have feedback or need assistance with the MCP directory API, please join our Discord server