Loading ToolBench
Secure WordPress MCP operations platform that exposes WordPress site content, media, menus, fields and Elementor documents as typed operations.
SiteHelm exposes 11 tools with broad WordPress domain coverage (content, media, menus, Elementor, ACF, system). However, critical definition gaps severely limit LLM usability. Tool names lack action verbs (e.g., 'content-read' vs 'get_posts', 'media-write' vs 'upload_media'). Descriptions are present but generic, they list capabilities without explaining WHEN to use each tool or what distinguishes them. No visible input schemas, parameter types, or output structures in the provided source. The code shows tool registration in McpServer.php but actual schema definitions are not included in the sample. Without schemas, LLMs cannot validate inputs or understand return types. Error handling and recovery guidance are absent. Security-critical tools (content-write, media-write) lack permission declarations or audit trail documentation.
Reads posts, pages and any post type, taxonomies and terms, comments, redirects, SEO metadata and audits, forms and their entries, and shop products, orders and customers.
Writes posts, pages and any post type, taxonomies and terms, comments, redirects, SEO metadata, user roles, site settings, shop products, code snippets, and plugins and themes - installing, updating, activating and switching them.
Reads Elementor documents, their element trees, widget availability, control schemas, global tokens and classes, templates and page settings.
Builds and edits Elementor documents: adding, updating, moving and removing elements, page settings, global colours, typography and classes, templates, popups and theme templates.
Reads Advanced Custom Fields and Meta Box field groups, definitions and values.
Writes Advanced Custom Fields and Meta Box field values.
No input schemas visible in source code. All 11 tools scored 0 for schema. LLMs cannot validate parameters, infer types, or understand required vs optional fields. This is a hard blocker for production use.
Tool names lack action verbs. 'content-read' should be 'list_posts' or 'get_posts'; 'media-write' should be 'upload_media'. Verb-less names force LLMs to guess intent and conflate similar tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | 2025-06-18+ | v2 |
Reads the media library and the image sizes this site generates.
Uploads, imports, resizes and re-describes media, and attaches it to content.
Reads navigation menus, their items and their theme locations.
Creates and edits navigation menu items, reorders them, and assigns menus to theme locations.
Reads this connection, the site environment, integration health, users, site settings, the audit log, installed plugins and themes, operation schemas, SEO settings and logs, and code snippets. Its system-operation-find searches every dispatcher for the operation that does a thing, from the words you would use for it.
Descriptions are capability lists, not LLM-optimized guidance. 'Reads posts, pages and any post type...' (content-read) lists features but does not explain WHEN to call it vs other tools or what the output structure is. Descriptions should be 50 - 200 chars and answer: what, when, why.
Destructive tools (content-write, media-write, menu-write, elementor-write, fields-write) lack confirmation/dry-run patterns and permission declarations. No audit trail or error recovery guidance. Agents can silently corrupt WordPress sites.
No error handling or recovery guidance visible. Tools do not document what errors are retryable, user-fixable, or fatal. LLMs have no guidance on next steps when a call fails.