WordPress MCP server has solid parameter schemas and consistent naming conventions (verb_noun pattern: wp_*). All 13 tools have descriptions and input schemas with types. However, descriptions are often generic and lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Output schemas are not documented. Error handling is present but minimal, no recovery guidance or actionable error messages. Missing tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in metadata. No pagination guidance in descriptions despite tools accepting per_page/page parameters.

• Expand all descriptions to 100-200 chars. Include: (1) what the tool does, (2) when to use it vs. similar tools, (3) what it returns. Example: 'List WordPress categories with optional filtering by parent, search term, or sort order. Returns category ID, name, slug, and post count. Use before wp_categories_create to check if a category exists.'
• Document output schemas for all tools. Add a 'returns' section to each tool's description or register a separate schema. Example for wp_categories_list: returns array of {id: int, name: string, slug: string, count: int, parent: int}.
• Add tool annotations to schema. For destructive tools (wp_media_delete), include destructiveHint: true. For read-only tools, include readOnlyHint: true. For idempotent tools, include idempotentHint: true.
• Implement actionable error messages. Instead of returning raw API errors, catch and reformat: 'Category not found (ID 123). Call wp_categories_list to find valid category IDs.' This guides LLM recovery.
• Add pagination guidance to descriptions of list tools. Example: 'Returns up to per_page items (default 10, max 100). Use page parameter to iterate. Returns total count so LLM can determine if more pages exist.'