Loading ToolBench
MCP server providing WordPress security skills for malware removal, security auditing, and hardening. Includes tools for detecting SEO-spam cloaking, scanning for malware signatures, auditing code vulnerabilities, and applying hardening actions.
6 tools with READ_ONLY and WRITE risk classifications. Tool descriptions are detailed (100-300 chars) and explain purpose well. However, input schemas are present but lack critical structure: no explicit type definitions visible for most parameters (e.g., 'url', 'wp_path' lack 'type': 'string' declarations in visible schema). Parameters lack descriptions in the schema itself, descriptions appear only in the tool docstring, not in the JSON Schema. The 'harden_actions' tool accepts a 'force' boolean but no guidance on consequences. Error handling is absent from tool definitions. No output schemas documented. Tool names are action-oriented (cloaking_diff, code_auditor, hardening_audit, posture_score, reinstall_clean, harden_actions) but some are compound (reinstall_clean, harden_actions) suggesting multiple concerns. Composition is reasonable, each tool has a single primary responsibility, but chaining is unclear (e.g., does posture_score require specific JSON field names from hardening_audit output?).
Detects SEO-spam CLOAKING: an infection that serves gambling/pharma content to search-engine and social crawlers while showing clean WordPress to normal visitors. Fetches each URL as Googlebot, facebookexternalhit, and normal browser, comparing titles, og:image, and body fingerprints.
Audits WordPress plugin/theme/custom code for VULNERABILITIES. Looks for insecure patterns in legitimate code (SQLi, XSS, CSRF, broken access control, file upload/inclusion, SSRF, object injection, open redirect, dynamic exec). Returns candidates verified in context, distinguishing third-party vs custom code.
Idempotent, reversible WordPress hardening actions. Provides SAFE/RISKY/MANUAL classified actions for hardening a WordPress site. Emits exact apply/verify/rollback commands for any gateway (SproutOS/MCP). Actions include disabling file editor, turning off debug, capping revisions, enabling auto-updates, rotating salts, blocking PHP in uploads, disabling directory listing, adding security headers, fixing permissions, forcing SSL, enabling HSTS, and more.
Audits a WordPress site's hardening/exposure via HTTP checks (REST user enumeration, XML-RPC exposure, security headers, directory listing, public debug.log, author enumeration, version disclosure, SSL). Read-only. Lists gateway-required checks for account/file verification.
Aggregates audit findings (hardening_audit, code_auditor, wordfence_client) into a security posture score (A-F grade) and prioritized action list. Weights reflect real-world breach vectors: stolen admin credentials (Access Hygiene) carry the most weight, followed by known vulnerable components.
Input schemas lack explicit 'type' declarations and parameter descriptions. Parameters are documented in tool docstrings but not in the JSON Schema structure itself. This forces LLMs to infer types and constraints from prose rather than machine-readable schema.
No output schemas documented. LLMs cannot predict what fields to expect from tool responses (e.g., does cloaking_diff return a boolean, a JSON object with 'cloaked' and 'evidence' fields, or a report structure?). This breaks downstream tool chaining and forces agents to guess field names.
No error handling guidance in tool definitions. If a tool fails (e.g., 'URL unreachable', 'invalid JSON file'), the definition does not specify what error messages to return or how the LLM should recover. This violates the recovery-guide pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
Verifies against and reinstalls from clean official sources. For WordPress core: fetches official md5 checksums from WordPress.org API, compares local files, reports MODIFIED/MISSING/EXTRA files. For plugins: resolves clean download URL for a given version.
Tool 'harden_actions' accepts a 'force' boolean parameter but provides no description of what 'force' does or what consequences it has. The docstring mentions 'RISKY actions' but the schema does not explain the risk or when to set force=true.
Tool 'posture_score' requires three input files (hardening.json, audit.json, vulns.json) but does not document the expected schema of each file. If hardening_audit outputs 'findings' but posture_score expects 'issues', the chain breaks silently.