This WordPress plugin MCP server exposes 20 tools with significant definition quality gaps. While all tools have names, descriptions, and visible schemas, the descriptions are often minimal (many under 100 chars) and lack guidance on when/why to use each tool or what to do on failure. Parameter descriptions are present but often generic (e.g., 'Post meta data'). No output schemas are documented. Security-critical operations (plugin install/update/delete, options update, elementor data) require confirmation tokens but lack clear guidance on obtaining them. The server accepts 'confirm_dangerous_action' as a parameter for irreversible operations, a security anti-pattern that leaks potential confirmation strategies into logs. Tool naming is clear and verb-first (create_post, update_page, delete-item), but some are overly specific to WordPress internals (meta/update-post-meta, menus/upsert-item) that may not be intuitive to non-WP agents. Schemas are present for all tools (good), but error handling and output documentation is entirely absent from the visible code.

• Remove 'confirm_dangerous_action' parameter from all tools. Instead, implement Multi-Round-Trip Requests (MRTR): agent calls plugin/delete with just the plugin ID, server returns {success: false, input_required: true, message: 'Confirm deletion of <plugin>?', confirmation_needed: 'delete_plugin_<slug>'}. Agent confirms via a second call with the confirmation token from server state (never exposed to LLM).
• Document output schema for every tool. Add a 'Returns' section to each description. Example: 'Returns {success: boolean, post_id: integer, message: string, permalink: string}'. Use JSON Schema in the tool definition.
• Expand meta parameter descriptions with examples and constraints. Example for meta_input: 'Object with WordPress meta keys as keys and values as any JSON type. Examples: {_featured_image: 123, _product_sku: "SKU-001"}. Do not include keys starting with underscore unless explicitly supported by WordPress.'
• Describe error cases and recovery paths in each tool description. Example: 'Create a new post. Returns success: bool, post_id: int. On error: if title is empty, error will be "title_required". If post type is invalid, try content/search to discover valid post types.'
• Add minimum/maximum constraints for numeric parameters (e.g., per_page: 1-100, page: 1-N) directly in descriptions and schemas.
• Add enum constraints to status and content_write_mode parameters. Already present for content_write_mode ('full_rebuild', 'guarded'), but status options are undefined, add enum: ['draft', 'publish', 'pending', 'private'] or link to WordPress docs.