MCP server that exposes WordPress post, page, category, tag, and media management as abilities for Claude integration via MCP protocol
This server has solid foundational work: all 6 tools are explicitly registered with complete JSON Schema input definitions and meaningful descriptions. However, there are notable gaps in output schema documentation, error handling guidance, and some parameter descriptions lack specificity. Naming follows verb-noun convention consistently. Most parameters are well-typed and have descriptions, but several lack range constraints and format guidance. The server registers with tool annotations (readonly/destructive hints) for some tools, which is good, but not all. Overall, this is fair-to-good work that would benefit from output schema documentation, stricter validation rules in descriptions, and error recovery guidance.
Create a new post category with optional parent and description.
Create a WordPress page with optional parent page and template.
Get a list of WordPress pages.
Get a list of blog posts filtered by status. Includes scheduled publish times.
Create a blog post. Supports immediate publish, draft, or scheduled publishing via publish_date.
Update an existing blog post. Supports rescheduling via publish_date.
Output schemas not documented. No specification of what fields are returned by any of the 6 tools, their types, or structure. LLMs cannot plan chaining calls (e.g., passing returned post_id to update-post) without knowing what fields exist in responses.
Parameter descriptions lack constraint guidance. Examples: 'limit' parameter in list-posts and list-pages states 'max 50' and 'max 100' in description but no minItems/maxItems in schema; publish_date format is described as 'ISO 8601 or MySQL format' but no pattern validation is present; no guidance on which status values are valid for which operations (e.g., 'future' requires publish_date).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | 2025-06-18+ | v1 |
No error handling guidance. Tools have no documented recovery paths. What should the LLM do if a post is not found? If publish_date is invalid? If category IDs don't exist? No error classification (retryable vs. user-fixable vs. fatal) is provided.
Tool annotations incomplete. publish-post and list-posts have 'annotations' with readonly/destructive hints, but update-post, create-page, list-pages, and create-category are missing these hints. Agents rely on annotations to understand tool safety.
No dry-run or confirmation pattern for destructive operations. publish-post, update-post, create-page, and create-category all write data without a preview or confirmation step. Agents making mistakes cannot be easily undone.
Parameter interdependencies undocumented. publish-post requires publish_date when status='future', but this constraint is not formalized in the schema (no conditional constraints). update-post similarly has this requirement but doesn't enforce it at the schema level.
Vague parameter descriptions. 'author_id' in both publish-post and create-page states 'defaults to current user' but does not explain what happens if the provided ID does not exist or the caller lacks permission to publish as that user. Similarly, 'categories' and 'tags' accept integer arrays but do not explain what happens if an ID is invalid.