Loading ToolBench
MCP server for WordPress Coding Standards - comprehensive code quality, security, performance, accessibility, and submission readiness checks for Claude AI
WPCS MCP Server provides 14 well-defined tools with consistent naming patterns (all start with verb 'wpcs_'), clear descriptions (avg ~180 chars), and proper input schemas with type declarations. However, output schemas are completely undocumented, no schema definitions visible for any tool's return values, forcing LLMs to reason about response structure blindly. Error handling strategy not evident from code. Parameter descriptions are adequate but lack validation constraints (enums for php_version, format options). Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profile in metadata. Schema quality is dragged down by lack of output documentation.
Check all PHP files in a directory against WordPress Coding Standards. Automatically excludes vendor/, node_modules/, and build/ directories.
Check a single PHP file against WordPress Coding Standards.
Check PHP files for compatibility with specific PHP versions (8.1, 8.2, 8.3, 8.4). Uses PHPCompatibilityWP to detect deprecated functions, removed features, and syntax incompatibilities. Essential for ensuring your plugin/theme works across PHP versions.
Check all staged PHP files against WordPress Coding Standards. Use this before committing to ensure code quality. Automatically excludes vendor/, node_modules/, and build/ directories.
Detect dead code and hook issues: unused/undefined functions, orphan callbacks, duplicate definitions, hook priority conflicts, accepted_args mismatch, wrong-context hooks.
Auto-fix WordPress Coding Standards violations in a PHP file using phpcbf. Fixes spacing, formatting, and other auto-fixable issues.
No output schemas documented for any tool. LLMs cannot infer response structure, field types, or available downstream references. Breaks tool composition and forces agent guessing on what fields to extract.
php_version parameter accepts free-form strings but lacks validation constraint or enum. Description says 'e.g. 8.1, 8.2' but LLMs may invent invalid versions (8.0, 9.0). Should declare enum or pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Check HTML/CSS/JS consistency and accessibility: file naming, class naming (BEM), vendor prefixes, responsive design, ARIA role validation, heading hierarchy, skip links, form label association, button types, tabindex.
Run comprehensive WordPress code check: WPCS + PHP Compatibility + Quality (security, performance, deprecated) + Frontend (accessibility, responsive) + Code Analysis (dead code, hooks) + Submission readiness. Use before release or WordPress.org submission.
Generate a comprehensive report in JSON, Markdown, or summary format. Runs all enabled checks and outputs a graded report (A-F). Optionally writes to a file for CI/CD integration.
Run PHPStan static analysis (if installed). Uses WordPress stubs for better type checking. Falls back gracefully if PHPStan is not installed.
Pre-commit workflow optimized for WordPress plugins/themes: Auto-fix staged PHP files, re-stage them, and report remaining issues. Automatically excludes vendor/, node_modules/, and build/ directories. Returns whether commit should proceed.
Advanced quality checks: hook usage, enqueue timing, security (SQL injection, XSS, SSRF, nonce mismatch, shell exec), performance (N+1 queries, unbounded queries, missing timeouts), accessibility, deprecated WP functions. Catches issues WPCS misses.
WordPress.org pre-submission audit: GPL license, stable tag match, changelog version, no tracking without consent, dismissible notices, uninstall cleanup, ABSPATH guards, prefix checking, no CDN deps, trademark check, required files, SVN readiness.
Validate WordPress plugin or theme project. Checks headers, readme.txt, text domain, .pot file, stable tag match, GPL license, and uninstall cleanup. Auto-detects project type.
format parameter in wpcs_generate_report correctly uses enum (json|markdown|summary), but other tools lack similar constraints. Good pattern not consistently applied.
Tool annotations missing. Five tools have WRITE risk (wpcs_fix_file, wpcs_pre_commit, wpcs_generate_report), should declare destructiveHint:true. All READ tools should declare readOnlyHint:true for clarity.
No error handling guidance documented. Tools may fail (missing phpcs, invalid path, permission denied) but code provides no recovery hints to LLM. Pattern:recovery-guide not applied.
Destructive tool (wpcs_pre_commit with auto_stage=true) lacks confirmation pattern. Auto-staging modified files without user confirmation could inadvertently commit unreviewed changes. Missing pattern:confirmation-request.
Parameter descriptions lack validation rules. E.g., 'path' and 'target' accept any string, no constraint on length, characters, or traversal safety. LLMs may pass '../../../etc/passwd'. Missing sanitization guidance.
No composition guidance for chaining. Tools like wpcs_full_check aggregate many sub-checks, but their relationships and execution order unclear. No documentation of which tools to call first for fast feedback.