WordPress MCP server demonstrates solid engineering with 25 well-structured tools covering comprehensive site management. All tools have descriptions (10 - 140 chars, averaging ~80 chars, below the 194-char baseline but acceptable for action-oriented tools). Input schemas are present and properly typed for all tools. Parameters use Pydantic Field annotations with descriptions, and most include sensible defaults. Key strengths: consistent naming patterns (list_*, read_*, create_*, update_*, delete_*), good use of enums in status/orderby fields, comprehensive parameter coverage. Weaknesses: (1) Output schemas are NOT documented, tool descriptions mention what they return in prose but lack formal JSON Schema definitions in source, violating critical check D; (2) No error handling guidance, no recovery patterns, retry classification, or actionable error messages visible in code; (3) No pagination details in output (total count, next_cursor) despite list_posts/list_categories/list_tags/list_users accepting pagination inputs; (4) Destructive operations (delete_post, delete_category, delete_tag, delete_user) lack confirmation/dry-run patterns; (5) rank_math parameter in create_post/update_post is a free-form object, should enumerate valid SEO field names. Despite these gaps, the tool suite is production-grade for read operations and competent for mutations.

• Add formal JSON Schema output definitions to every tool definition. Document the structure of response objects, field types, and whether lists include pagination metadata (total, next_cursor, has_more). E.g., list_posts should document: {"posts": [{"id": int, "title": string, ...}], "total": int, "page": int}.
• Implement a confirmation-request pattern for all destructive operations. Instead of delete_post accepting a force boolean, split into delete_post (move to trash, default safe) and permanently_delete_post, or add a preview_deletion or confirm_deletion tool that shows what will be deleted and requires explicit confirmation.
• Add error handling patterns to tool descriptions. Specify what error conditions are possible (e.g., 'post_id not found', 'authentication failed', 'rate limited'), classify them (retryable, user-fixable, fatal), and suggest recovery actions (e.g., 'If post not found, try list_posts with search= to find the correct ID').
• Document pagination output metadata in list_* tools. Specify that responses include fields like total_items, current_page, per_page, and has_next_page so agents can implement pagination loops correctly.
• Add schema validation to rank_math parameters. Convert the prose list of valid SEO fields into a documented object schema with optional subfields: {"title": string, "description": string, "focus_keyword": string, "canonical_url": string, ...}. Validate inputs and return clear errors for unknown fields.
• Add idempotency documentation to create_* tools. Specify that if the tool is called twice with the same inputs, it will either return the same ID (true idempotency) or update the existing record, and what distinguishes creation from update (e.g., by checking for duplicate titles or slugs).

Inferred effective spec: <=2025-11-25.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained