Loading ToolBench
WordPress site agent for the Aura platform — MCP server providing tools for auditing and managing WordPress sites, with approval-gated execution of privileged operations.
SiteAgent defines 6 tools with clear, detailed descriptions (avg 180 chars, well above the 34-char minimum). All tools have explicit names starting with audit_ or backup_ verbs. However, critical gaps exist: 5 of 6 tools declare empty input schemas ({}), violating the schema requirement. The backup_plugins tool has a proper schema with type and description, but the audit tools lack any parameter documentation despite being read-only. No tool declares output schemas, error handling guidance, or recovery paths. Tool descriptions are strong on WHAT (e.g., 'Read-only privileged-account audit') but weak on WHEN and HOW to use them. No tool annotations (readOnlyHint, destructiveHint) are visible in the code, despite clear risk classifications (READ_ONLY, WRITE). The tool registry (class-aura-worker-tools.php) shows solid composition and permission gating via Aura_Worker_Rules, but tool definitions themselves lack the structured metadata needed for LLM-optimal selection.
Read-only privileged-account audit: lists administrators with registration recency, users holding admin capabilities outside the administrator role, per-admin application-password counts, and on multisite the network super admins (read from the site_admins option after a raw-size pre-check). Returns bounded facts; makes no changes.
Read-only audit of executable code an AI agent authored or can author on this site: Angie code snippets (recorded, agent-authored, and which are live in the environment the loader includes), the SiteAgent Power Pack's execute-php / file-write / wp-cli flags, and third-party exec stores (EMCP Pro sandbox, Atarim exec abilities). Reports counts and presence per source, never file contents and never a verdict. Makes no changes.
Read-only WP-Cron audit: bounded inventory of scheduled events (hook, schedule, interval, next run) with fact-flags for sub-60-second schedules and hooks whose callbacks are not registered in this request context (not proof of orphanhood). Pre-checks the raw cron option size; makes no changes.
Read-only audit of OTHER agent doors on this site: whether the WordPress Abilities API and an MCP adapter are active, which MCP servers besides SiteAgent are registered (id and route), and how many registered abilities a co-installed server would be able to reach — split by whether they mutate. Reports facts (server present, ability counts, exposure rule outcome), never a verdict. Makes no changes.
Read-only audit of operator rules: whether a signed ruleset is present and how old it is, 24h block/warn counts, rules that have expired but are still listed, and the enforcement points in this build. Makes no changes.
5 of 6 tools declare empty input schemas ({}). This violates pattern:constrained-input and pattern:tool-description, LLMs cannot infer parameter meaning or constraints from empty schemas.
No tool declares output schemas. LLMs cannot plan downstream calls or extract required fields without knowing what each tool returns. Baseline: 100% of A+ tools document return types.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in code, despite explicit risk classifications (READ_ONLY, WRITE). Tool registry enforces rules but does not expose annotations to the MCP protocol layer, limiting LLM awareness of side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Creates a zip backup of a specific plugin (by slug) or, if none is given, every active plugin — so changes can be rolled back. Returns per-plugin results and the current backup inventory.
Error handling is generic ('Parameter validation failed', 'Unknown tool'). No recovery guidance, no actionable error messages, no categorization (retryable vs. fatal). Violates pattern:recovery-guide.
Tool descriptions lack WHEN/HOW context. E.g., 'Read-only audit of OTHER agent doors' does not explain when an LLM should call this vs. another audit tool, or what to do with the results. Baseline: descriptions should answer What, When, and prerequisites.