WP MCP Server has 31 tools with consistent naming (verb_noun pattern: wp_*) and complete input schemas. All tools are registered with descriptions and capability checks. However, descriptions are often generic or lack actionable context for LLM selection. Parameter descriptions are sparse, many lack guidance on valid ranges, formats, or dependencies. Output schemas are not documented. Error handling is minimal. Security concerns exist around direct database access (wp_db_execute) without sufficient safeguards. The server follows basic structure but lacks the depth and LLM-optimization expected of production-grade tools.

• Document output schemas for all tools. For each tool, specify the structure of the returned object, field types, and which fields are safe to pass to downstream tools. E.g., wp_create_post should return {post_id: integer, title: string, url: string, status: string}.
• Enhance parameter descriptions with constraints and examples. Replace 'Máximo 50' with 'Integer, 1 - 50 (default 10). Limits results per page.' Add enum explanations: 'status: one of draft (unpublished), publish (live), pending (awaiting review), private (visible to admins only).'
• Add error recovery guidance to tool descriptions. E.g., wp_create_post: 'If a category does not exist, call wp_create_term first. Returns error 'category_not_found' if category name is invalid.'
• Implement a dry-run or confirmation step for destructive operations (wp_delete_post, wp_delete_user, wp_db_execute). Return a confirmation token that must be passed in a second call to execute. This prevents accidental data loss.
• Refactor wp_db_execute to require explicit table and column whitelists, or remove it entirely in favor of domain-specific tools (wp_update_post, wp_update_user). Direct SQL access is a security and maintainability liability.