Loading ToolBench
Semantic WordPress authoring MCP server with personality-based tool filtering
The server defines 5 tools with visible schemas and descriptions, but exhibits significant quality gaps that prevent production readiness. All tools have descriptions and input schemas, but the descriptions are generic and lack LLM-optimized guidance. Parameter descriptions are sparse or missing context. Most critically, output schemas are completely undocumented, the server defines what it accepts but not what it returns, forcing LLMs to guess at response structures. Tool naming uses compound descriptors (e.g., 'content-management') rather than action verbs, reducing clarity. Error handling is mentioned in descriptions but not implemented in visible code. The server prioritizes breadth (5 tools) over depth (quality per tool).
[Block Editor] Edit content using WordPress blocks. Write clean HTML - most AI-generated HTML passes validation easily. Content is stored as simple block comments: <!-- wp:paragraph --><p>Your content</p><!-- /wp:paragraph -->. TROUBLESHOOTING: If sync fails with "Cannot create property on string", use individual parameters (level: 2) instead of attributes objects. If validation fails, read the block first to inspect its current state.
[Content Management] Create, edit, and manage posts and pages. TROUBLESHOOTING: If sync action fails, check error message for specific recovery steps. Common fixes: delete problematic blocks and recreate them, use simple parameters instead of complex attributes.
[Media Management] Upload and manage media files
[Publishing Workflow] Review, approve, and publish content
[Site Administration] Manage site settings, users, and configurations
No output schemas documented for any tool. Tools specify input parameters but never declare what fields agents will receive in responses. Forces LLMs to infer response structure, inviting parsing errors and wasted tokens on exploratory calls.
Tool names do not start with action verbs. 'content-management', 'block-editor', 'publishing-workflow', 'media-management', and 'site-administration' are noun phrases, not verb_noun patterns. LLMs infer intent from verb-first names, these ambiguous titles reduce clarity and composability.
publishing-workflow and media-management have minimal descriptions (<30 chars). '[Publishing Workflow] Review, approve, and publish content' and '[Media Management] Upload and manage media files' lack WHEN-to-use context, prerequisites, or what agents should expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 32 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
site-administration description is 37 characters and generic. '[Site Administration] Manage site settings, users, and configurations' does not explain what actions are available, when to call it, or what the agent gets back. No guidance on permissions required.
Many parameters lack descriptions or have placeholder-like text. In content-management: 'excerpt' has description 'Brief summary' (13 chars); 'status' has 'Publish status' (15 chars). In publishing-workflow: 'intent', 'status', 'contentType' have descriptions like 'edit|review|publish|comment|any' with no explanation of what these mean or when to use each. Parameters under 20 chars force LLMs to guess semantics.
Enum parameters lack context on when to use each value. content-management action enum includes ['draft', 'publish', 'edit', 'pull', 'sync', 'trash', 'page', 'markdown-to-wp', 'bulk'], but the description does not explain what distinguishes 'pull' from 'sync', or when 'markdown-to-wp' vs 'bulk' applies. LLMs must guess.
No documented error handling or recovery paths. content-management and block-editor descriptions mention 'TROUBLESHOOTING' sections with fixes ('delete problematic blocks and recreate them', 'use individual parameters'), but the tool schema has no error field, no status indicators, and no documented failure modes. Recovery guidance is aspirational, not implemented.
content-management action enum is overloaded. A single action parameter handles ['draft', 'publish', 'edit', 'pull', 'sync', 'trash', 'page', 'markdown-to-wp', 'bulk']. This violates single-responsibility: some are state transitions (draft→publish), some are I/O (pull, sync), some are format conversions (markdown-to-wp). Should split into separate tools (create_post, edit_post, publish_post, import_markdown, etc.).
block-editor action enum ['list', 'read', 'edit', 'insert', 'delete', 'reorder', 'validate', 'add-section', 'add-subsection', 'add-paragraph', 'add-list', 'add-quote', 'add-code', 'add-separator', 'continue-writing'] mixes low-level operations (edit, insert, delete) with high-level abstractions (add-section, continue-writing). Unclear parameter routing and implicit context switching. The 'add-*' variants should be separate tools.
publishing-workflow parameters are underspecified. 'query' has description 'Search terms' but no indication of whether it matches titles, content, metadata, or all; 'intent' enum has ['edit', 'review', 'publish', 'comment', 'any'] with no guidance on what each filters for; 'status' enum includes 'any' without explaining what 'any' returns (all statuses, or default set?).
content-management filePath parameter uses oneOf with string or array, but the description does not explain when to use each form or whether both are valid simultaneously. 'recurse' parameter only mentions validity for 'directories with type=page', but type is not documented, and the schema does not enforce this constraint.