Loading ToolBench
MCP server for WordPress content management, providing tools to create, update, delete, and list posts, manage categories and tags, and upload media to WordPress sites via the REST API.
WordPress MCP server demonstrates solid schema coverage and consistent naming conventions. All 8 tools use clear verb-noun patterns (create_post, update_post, get_post, list_posts, delete_post, list_categories, list_tags, upload_media). Tool descriptions are present and adequate (ranging 50-120 chars), explaining what each tool does. Input schemas are complete with proper JSON Schema structure, types, and parameter descriptions. However, there are notable gaps: (1) Output schemas are NOT documented, the source code shows tool definitions but no return type specifications; (2) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite having tools with clear risk profiles (create_post=WRITE, delete_post=DESTRUCTIVE); (3) Error handling guidance is absent from descriptions, tools like delete_post and update_post do not explain recovery paths or confirm-before-execute patterns; (4) Parameter relationships (e.g., categories and tags in create_post accept integer IDs but there is no guidance on obtaining valid category/tag IDs); (5) Pagination is implemented (per_page, page) but list_posts does not document the total count or next_cursor in the response schema; (6) Security: credentials (WP_USERNAME, WP_PASSWORD) are correctly injected via environment variables and not exposed as parameters, which is good. Missing: per-tool descriptions do not mention prerequisites (e.g., 'Call list_categories() first to obtain valid category IDs'), and tool descriptions lack explicit statements about state modification side effects.
Create a new WordPress post. Can be published immediately or saved as draft.
Delete a WordPress post (moves to trash or permanently deletes).
Get details of a specific WordPress post by ID.
List all WordPress categories.
List WordPress posts with optional filtering.
List all WordPress tags.
Update an existing WordPress post.
Output schemas are not documented. Tools return structured data but the response schema is not specified anywhere in the code or descriptions. LLMs cannot plan downstream tool calls or extract required fields (e.g., post_id from create_post result) without documented return types.
Tool annotations missing (readOnlyHint, destructiveHint, idempotentHint). Risk metadata exists in the assessment (WRITE, DESTRUCTIVE, READ_ONLY) but is not exposed in tool definitions. The MCP spec allows tools to declare risk classification, this enables agents to reason about safety and retry logic.
No error handling guidance in tool descriptions. delete_post and update_post are destructive/modifying operations but descriptions do not explain what errors may occur, what they mean, or how to recover (e.g., 'Post not found' → call list_posts with search filter).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 72 | 2026-07-28+ | v2 |
Upload a media file to WordPress. Note: This expects a file path or URL.
Parameter relationships undocumented. create_post accepts category and tag ID arrays but does not explain how to obtain valid IDs. Descriptions should include: 'Call list_categories() first to obtain valid category IDs.' This prevents invalid calls and guides multi-step planning.
Pagination response schema incomplete. list_posts, list_categories, and list_tags accept per_page and page parameters but the response schema is not documented. Unclear whether the response includes total_count, has_more, next_cursor, or other pagination metadata. This blocks proper result limiting and context-window awareness.
upload_media file_path parameter description lacks format constraints. Should specify: 'Local file path (string). Supported formats: JPEG, PNG, GIF, PDF. Max size: 100MB.' Current description says 'Local file path or URL' but the inputSchema only lists file_path as a string with no validation hints.
No dry-run or confirmation pattern for destructive operations. delete_post with force=true permanently deletes posts. The pattern should offer a dry-run mode or require explicit confirmation to prevent accidental data loss when agents make mistakes.