Loading ToolBench
MCP Server for Warden + Magento 2 development workflow with project initialization
The server defines 11 tools with explicit schemas and descriptions visible in server.js. Naming follows verb_noun convention (list_, start_, stop_, run_). However, critical gaps emerge: (1) Parameter descriptions are present but sparse and sometimes uninformative. For example, 'Path to the project directory' appears on every parameter without explaining what the tool does with that path or validating it exists. (2) No output schemas are documented, tools return raw command output without structured response definitions, making downstream chaining difficult. (3) Error handling is absent, no guidance on what happens when a command fails, whether to retry, or what error messages look like. (4) The tool descriptions are adequate (mostly 30-100 chars) but lack WHEN/WHY context and don't clarify distinctions between similar tools (e.g., warden_start_project vs warden_start_svc). (5) Dangerous tools like warden_init_project (DESTRUCTIVE) and warden_db_query (WRITE) lack confirmation/dry-run patterns, and parameter validation is not visible in the provided code. (6) No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. This is a functional baseline server with visible schemas but lacks production-grade polish.
Run Composer commands inside the php-fpm container
Run a SQL query in the Warden database
Initialize a new Warden project with Magento 2 environment
List all running Warden environments with their directories (returns structured JSON)
Run bin/magento command inside the php-fpm container
Run a PHP script inside the php-fpm container
Run unit tests using PHPUnit in the php-fpm container
No output schemas documented for any tool. Tools execute CLI commands and return raw output without structured response definitions. Downstream agents cannot reliably parse results or chain tools.
Destructive and write tools (warden_init_project, warden_db_query, warden_composer) lack confirmation/dry-run patterns. No way to preview changes or prevent accidental execution. Agents can irreversibly delete data without safeguards.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) defined despite clear risk stratification: READ_ONLY (list, test) vs WRITE (start, stop, cli) vs DESTRUCTIVE (init, db_query). Agents cannot distinguish safe tools from dangerous ones.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 19 | - | v1 |
Start a Warden project environment
Start Warden system services
Stop a Warden project environment
Stop Warden system services
Parameter descriptions are minimal and non-informative. 'Path to the project directory' appears on 11 tools without explaining what the tool does, validation rules (must exist? must be absolute?), or how the path is used. No format constraints, min/max lengths, or regex patterns.
No error handling guidance. Tools can fail (missing project, invalid SQL, PHP error) but provide no recovery instructions, error classification (retryable vs fatal), or actionable failure messages. LLMs cannot determine next steps on failure.
Tool descriptions lack WHEN/WHY context. For example, warden_start_svc and warden_start_project both 'start' but the distinction is unclear. No guidance on prerequisites, dependencies, or when to call each tool instead of the other.
warden_init_project has 11 optional parameters with default values (php_version, mysql_distribution, etc.) but no indication of which combinations are valid or recommended. LLMs may pass conflicting or unsupported configurations without validation.
warden_db_query accepts free-form SQL queries with no input validation visible. SQL injection prevention is not documented. Agents can pass malicious queries without safeguards.