MCP server for WordPress database access via Local by Flywheel
Server provides 5 tools with proper schema definitions and non-empty descriptions, but exhibits significant quality gaps. All tools start with 'mysql_' prefix rather than action verbs (get_, list_, execute_), which violates naming patterns and reduces semantic clarity. Descriptions range from 84-168 characters (adequate length), but lack specifics about when to use each tool and dependencies between them. Input schemas are present for all tools with proper JSON Schema structure, but parameter descriptions are minimal or absent. The mysql_query and mysql_write tools accept free-form SQL strings with optional parameterized arrays, no enum constraints or validation hints to guide LLM input. Error handling is absent from tool definitions; no guidance on recovery paths or categorization of failure modes. Overall: serviceable for database access but suboptimal for LLM consumption.
Get information about the currently connected Local WordPress site, including how it was selected
List all available Local WordPress sites and their running status
Execute a read-only SQL query against the Local WordPress database
Inspect database schema. Without args: lists tables. With table: shows columns and indexes.
Execute write operations (INSERT/UPDATE/DELETE) against the Local WordPress database. UPDATE and DELETE require parameterized WHERE clauses for safety.
Tool names do not start with action verbs. All tools use 'mysql_' prefix (mysql_query, mysql_schema, mysql_write) instead of semantic verb-noun patterns (execute_query, inspect_schema, execute_write). LLMs infer intent from name first, opaque prefixes force reliance on descriptions and reduce discoverability.
Parameter descriptions are missing or trivial. 'sql' parameter in mysql_query and mysql_write lacks format guidance (e.g. 'SELECT statements only, no DDL', 'parameterized WHERE required for safety'). 'params' description is generic ('Optional parameter values for placeholders'). LLMs cannot infer valid SQL dialects or syntax constraints from these descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
No input validation hints or constraints in descriptions. mysql_query accepts SELECT/SHOW/DESCRIBE/EXPLAIN (read-only intent stated in tool description, not param description), but LLM has no machine-readable constraint preventing INSERT or UPDATE attempts. mysql_write accepts INSERT/UPDATE/DELETE but no enum or pattern constraint prevents schema DDL (CREATE/ALTER/DROP). Free-form SQL strings invite injection risks and misuse.
No documented output schemas. Tool descriptions do not specify what fields are returned (e.g. mysql_list_sites returns list of site objects, what are the fields? site_name, site_path, domain, running_status?). Without output documentation, LLMs cannot plan downstream chains or extract required fields reliably.
No error handling guidance in definitions. Tool descriptions do not specify what errors are possible, when they are retryable, or what the LLM should do next (e.g. 'If connection fails, retry with exponential backoff.' or 'If syntax error occurs, review SQL and try again.'). Agents calling these tools without error recovery context will stall on failures.
No dependency or composition guidance. Tool descriptions do not indicate relationships (e.g. 'Call mysql_list_sites first to find the site name, then use mysql_current_site to confirm connection.' or 'mysql_query is read-only; use mysql_write for modifications'). LLMs must infer composition from names alone, risking unnecessary discovery calls.
mysql_write tool is conditionally registered based on MYSQL_ALLOW_WRITES environment variable. If writes are disabled, the tool is omitted entirely. This is a viable gating mechanism, but the tool description should state the permission requirement explicitly ('This tool is only available if MYSQL_ALLOW_WRITES is set to true') so clients understand why it may or may not be available.