Loading ToolBench
Native Model Context Protocol (MCP) server for WordPress to create draft posts, manage media, read/update posts, and handle custom prompts.
WP Post MCP demonstrates solid tool definition quality with complete JSON schemas, clear descriptions, and proper parameter typing across all 6 tools. All tools follow verb_noun naming conventions (list_*, create_*, update_*, read_*, upload_*). Descriptions are substantive (100-200 chars typical), explaining WHAT the tool does and WHEN to use it. Input schemas are well-formed with required fields, enums, and oneOf constraints. However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Error handling guidance is absent; tools lack recovery hints. Security considerations (permission gates, audit trails) are not visible in definitions. Tool composition is sound: list_categories/tags enable discovery before create_draft_post; upload_media chains to create_draft_post via featured_image_id. No tool combines multiple concerns.
Creates a new post in WordPress strictly in "draft" status. Supports full HTML and Gutenberg block markup in content.
Retrieves existing categories in WordPress so you can choose an existing category ID for a post.
Retrieves existing post tags from WordPress for discovery and suggestions.
Retrieves the content, title, excerpt, metadata, and taxonomy terms of an existing WordPress post (draft or published) by ID.
Updates an existing draft post in WordPress. Allows updating title, content, excerpt, category, tags, and featured image.
Uploads an image from the user PC / AI client into the WordPress Media Library via Base64. Sets Title, Alt Text, Caption, and Description.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for list_categories, list_tags, create_draft_post, upload_media, read_post, update_draft. This breaks tool chaining, agent cannot know if create_draft_post returns post_id or post.id.
No error handling guidance. Tools lack recovery hints (e.g., 'If post not found, try read_post with a different ID' or 'Invalid category_id, call list_categories first'). Agents cannot self-correct on failures.
upload_media accepts Base64 strings without documented size limits or format constraints. Description says 'can include or omit data:image/...;base64, prefix' but does not specify max file size, allowed MIME types, or dimension constraints. LLMs may pass oversized or invalid files.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
create_draft_post and update_draft accept category_id and tags with flexible types (integer|array or string|array) but lack guidance on behavior when both single and array forms are passed. Undocumented parameter relationships increase misuse risk.
No permission gates or scope declarations visible. Tools like create_draft_post, update_draft, upload_media are destructive/write operations but lack documented permission requirements (e.g., 'requires write:posts, write:media'). Audit trail and logging not mentioned.