Loading ToolBench
WordPress AI agent tool system that integrates MCP (Model Context Protocol) servers and provides native WordPress tools for content management, SEO, media, comments, and site information
ClawWP provides 8 tools for WordPress management with generally complete JSON schemas and reasonable descriptions. However, several tools lack critical schema visibility, descriptions are inconsistent in depth, and error handling guidance is absent. Tools 7-8 (manage_woocommerce, manage_wallet) are inferred rather than directly visible in source code, triggering the hard cap. Most tools follow verb_noun naming correctly. Parameter descriptions are present but often generic. Output schemas are not documented. The server lacks MCP protocol implementation evidence (transport unknown, no MCP-specific features detected).
Get WordPress site information including stats, health status, active plugins, theme, recent activity, and content counts.
List, approve, spam, trash, or reply to WordPress comments. Great for content moderation.
List, search, and get details about items in the WordPress media library. Can also update alt text and captions.
Create, edit, list, or delete WordPress pages.
Create, edit, list, search, schedule, or delete WordPress posts. Use action parameter to specify the operation.
Get or update SEO meta for posts and pages: meta title, meta description, focus keyword. Works with Yoast SEO, Rank Math, or stores in custom fields.
Listed as registered in core tools but source code not fully provided.
Tools 7-8 (manage_woocommerce, manage_wallet) are registered but source code not provided. Only tool name and file path visible; no schema or description present.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract typed fields from responses. All tools should declare expected return structure (fields, types, pagination info).
No error recovery guidance. Tool descriptions state what they do but do not explain what to do if errors occur, whether to retry, or how to self-correct. E.g., 'manage_posts' could explain 'If category/tag lookup fails, use search_posts() to verify names first.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Listed as registered in core tools but source code not fully provided.
Descriptions lack depth on parameter dependencies and constraints. E.g., 'manage_posts' action 'schedule' requires 'date' parameter, this should be documented. 'status' enum values allowed differ by action (e.g., 'schedule' implies 'future' status) but not explained.
manage_media and manage_seo descriptions are generic and under 80 characters. 'Get or update SEO meta for posts and pages...' lacks actionable context on WHEN to use audit vs update, or what 'audit' returns. Descriptions should be 50-200 characters for LLM clarity.
Parameter 'search' in manage_posts and manage_pages is described as 'Search query', vague. Does it search titles only, or content too? Are wildcards supported? Does it support boolean operators? LLM cannot know without explicit constraints.
Numeric limit parameters lack min/max bounds. manage_posts allows 'limit' with 'default 10, max 50' in description, but no JSON Schema minumum/maximum constraints. An LLM might try limit=500 anyway. All numeric params should include explicit bounds in both description AND schema.
manage_comments 'reply_content' parameter is optional but only meaningful for 'reply' action. Undocumented parameter dependency: 'reply_content' is ignored for 'approve', 'spam', 'trash' actions. Should state 'Required if action=reply; ignored otherwise.'
No dry-run or confirmation for destructive operations. 'manage_posts delete', 'manage_pages delete', 'manage_comments trash' are irreversible but lack safety mechanisms. Consider adding optional 'confirm' or 'dry_run' parameter for destructive tools.
manage_posts and manage_pages support both 'categories' and 'tags' arrays, but do not specify: Can you pass non-existent category names (auto-create)? Or only existing IDs/slugs? LLM needs this distinction to avoid failures.