Executes Composer commands inside PHP containers for dependency management including installing, updating, adding or removing packages, and managing autoloading
Manages Docker-based Warden environments for Magento development, including starting and stopping containers and services
Provides integration with MariaDB database containers, allowing execution of SQL queries for database operations in Magento environments
Enables interaction with MySQL database containers for executing queries and managing databases in Magento projects
Supports configuring Node.js version in Warden environments for Magento development projects
Provides integration with OpenSearch services for Magento environments with customizable version configuration
Executes PHP scripts in containerized environments with proper Magento context, supports PHPUnit testing, and allows Magento CLI command execution
Enables optional RabbitMQ messaging service integration for Magento environments
Provides Redis caching service integration for Magento environments with customizable version configuration
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Warden Magento MCP Server start my Magento project at /Users/dev/projects/store"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A comprehensive Model Context Protocol (MCP) server that provides seamless integration between AI assistants and Warden + Magento 2 development environments. This server enables AI assistants to interact directly with your Warden-managed Magento projects, automating common development tasks and providing intelligent assistance for complex workflows.
This MCP server transforms your AI assistant into a powerful development companion for Warden + Magento 2 projects by providing:
🚀 Project Initialization: Create new Warden projects with customizable Magento 2 environments
🔧 Environment Management: Start/stop projects and services with intelligent state management
🗄️ Database Operations: Execute SQL queries directly in containerized databases
🐘 PHP Development Tools: Run PHP scripts in properly configured containerized environments
🛠️ Magento CLI Integration: Execute Magento commands seamlessly within containers
🧪 Unit Testing Support: Run PHPUnit tests with automatic configuration detection
📦 Composer Integration: Manage dependencies within containers with full command support
📊 Environment Monitoring: List and monitor running Warden environments
Related MCP server: wp-mcp
Clone or download this repository
Install dependencies:
npm installConfigure your MCP client (see Configuration section below)
Add the following configuration to your MCP client settings:
{
"mcpServers": {
"warden-magento": {
"command": "node",
"args": ["/absolute/path/to/warden-mcp-server/server.js"],
"env": {}
}
}
}Important: Replace /absolute/path/to/warden-mcp-server/server.js with the actual absolute path to the server.js file on your system.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"warden-magento": {
"command": "node",
"args": ["/Users/your-username/path/to/warden-mcp-server/server.js"]
}
}
}Add to your Zed settings:
{
"assistant": {
"version": "2",
"provider": {
"name": "anthropic",
"model": "claude-3-5-sonnet-20241022"
}
},
"context_servers": {
"warden-magento": {
"command": "node",
"args": ["/Users/your-username/path/to/warden-mcp-server/server.js"]
}
}
}Once configured, your AI assistant can automatically use these tools to help with Warden + Magento development tasks. Simply describe what you want to accomplish, and the AI will use the appropriate tools.
warden_list_environmentsLists all running Warden environments with their directories and status information.
Parameters: None
Use Cases:
Check which environments are currently running
Get project paths for other operations
Monitor environment status
warden_start_projectStarts a Warden project environment, bringing up all configured containers.
Parameters:
project_path (required): Path to the project directory
Use Cases:
Start development environment
Resume work on a project
Bring up services after system restart
warden_stop_projectStops a Warden project environment, shutting down all project containers.
Parameters:
project_path (required): Path to the project directory
Use Cases:
Clean shutdown of development environment
Free up system resources
Prepare for system maintenance
warden_start_svcStarts Warden system services (shared infrastructure like DNS, proxy, etc.).
Parameters:
project_path (required): Path to the project directory
Use Cases:
Initialize Warden infrastructure
Start shared services after system reboot
Prepare environment for project startup
warden_stop_svcStops Warden system services.
Parameters:
project_path (required): Path to the project directory
Use Cases:
Clean shutdown of Warden infrastructure
Troubleshoot service conflicts
System maintenance
warden_init_projectInitializes a new Warden project with a fully configured Magento 2 environment.
Parameters:
project_path (required): Path where the project should be initialized
project_name (required): Name for the Warden environment
environment_type (optional): Environment type (default: "magento2")
php_version (optional): PHP version (default: "8.3")
mysql_distribution (optional): MySQL distribution (default: "mariadb")
mysql_version (optional): MySQL version (default: "10.6")
node_version (optional): Node.js version (default: "20")
composer_version (optional): Composer version (default: "2")
opensearch_version (optional): OpenSearch version (default: "2.12")
redis_version (optional): Redis version (default: "7.2")
enable_redis (optional): Enable Redis (default: true)
enable_opensearch (optional): Enable OpenSearch (default: true)
enable_varnish (optional): Enable Varnish (default: true)
enable_rabbitmq (optional): Enable RabbitMQ (default: true)
enable_xdebug (optional): Enable Xdebug (default: true)
Use Cases:
Set up new Magento 2 development environment
Create project with specific PHP/MySQL versions
Configure environment for specific requirements
Initialize project with custom service stack
warden_db_queryExecutes SQL queries directly in the Warden database container.
Parameters:
project_path (required): Path to the project directory
query (required): SQL query to execute
database (optional): Database name (default: "magento")
Use Cases:
Execute database queries for debugging
Retrieve data for analysis
Perform database maintenance tasks
Check database schema or data
warden_php_scriptRuns PHP scripts inside the php-fpm container with proper environment setup.
Parameters:
project_path (required): Path to the project directory
script_path (required): Path to the PHP script relative to project root
args (optional): Additional arguments to pass to the script
Use Cases:
Execute custom PHP scripts
Run data migration scripts
Test PHP functionality
Execute maintenance scripts
warden_magento_cliExecutes Magento CLI commands inside the php-fpm container.
Parameters:
project_path (required): Path to the project directory
command (required): Magento CLI command (without 'bin/magento' prefix)
args (optional): Additional arguments for the command
Use Cases:
Run cache operations (cache:clean, cache:flush)
Execute setup commands (setup:upgrade, setup:di:compile)
Manage configuration (config:set, config:show)
Run indexing operations (indexer:reindex)
Module management (module:enable, module:disable)
warden_run_unit_testsRuns PHPUnit tests inside the php-fpm container with automatic configuration detection.
Parameters:
project_path (required): Path to the project directory
config_file (optional): PHPUnit configuration file (auto-detects phpunit.xml.dist or phpunit.xml)
test_path (optional): Path to specific test file or directory
extra_args (optional): Additional PHPUnit arguments
Use Cases:
Run unit tests for modules
Execute specific test suites
Run tests with custom configuration
Validate code changes with automated testing
warden_composerExecutes Composer commands inside the php-fpm container.
Parameters:
project_path (required): Path to the project directory
command (required): Composer command to execute
Common Commands:
install - Install dependencies
update - Update dependencies
require package/name - Add new dependency
remove package/name - Remove dependency
require-commerce - Install Adobe Commerce (if applicable)
dump-autoload - Regenerate autoloader
Use Cases:
Install project dependencies
Add new packages to project
Update existing dependencies
Manage autoloading
Install Adobe Commerce components
Warden: Must be installed and configured on your system
Docker: Required for Warden to function
Node.js: Version 18.0.0 or higher
MCP Client: Compatible MCP client (Claude Desktop, Zed, etc.)
For issues specific to this MCP server, check:
Server logs when running npm start
MCP client logs for connection issues
Docker container logs: warden env logs
MCP Server inspector: https://github.com/modelcontextprotocol/inspector
MIT License - see LICENSE file for details
Contributions are welcome! Please feel free to submit issues and pull requests.
Warden - The Docker-based development environment
Model Context Protocol - The protocol specification
Magento 2 - The e-commerce platform
Run Composer commands inside the php-fpm container
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to the project directory | |
| command | Yes | Composer command to execute (e.g., 'install', 'update', 'require symfony/console', 'require-commerce') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool runs commands in a container but lacks critical details: whether it requires the container to be active, if it's read-only or mutative (e.g., 'composer install' vs. 'composer update'), potential side effects, error handling, or output format. This leaves significant gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It front-loads the core action ('Run Composer commands') and context ('inside the php-fpm container'), making it immediately understandable. Every word earns its place, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing commands in a container with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like mutability, prerequisites, or error handling, which are crucial for a tool that could modify project dependencies or fail due to container state. More context is needed for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('project_path' and 'command'), including examples for the command. The description adds no additional parameter semantics beyond what the schema provides, such as path format constraints or command limitations. Given the high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run Composer commands') and the context ('inside the php-fpm container'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'warden_magento_cli' or 'warden_php_script', which might also involve container execution, leaving some ambiguity about when to choose this tool over those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the project must be running or initialized), exclusions (e.g., commands that shouldn't be run), or comparisons to siblings like 'warden_magento_cli' for Magento-specific tasks. Usage is implied but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a SQL query in the Warden database
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to the project directory | |
| query | Yes | SQL query to execute | |
| database | No | Database name (optional, defaults to magento) | magento |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Run a SQL query' implies execution but reveals nothing about permissions needed, whether queries are read-only or can modify data, transaction handling, error behavior, or result formatting. This leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's perfectly front-loaded and appropriately sized for what it does convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a database query tool with no annotations and no output schema, the description is incomplete. It doesn't address critical aspects like query types supported, result format, error handling, or security considerations, leaving significant gaps for an agent to understand how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter context beyond what's already in the structured fields, which meets the baseline expectation but doesn't provide extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run a SQL query') and target resource ('in the Warden database'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling database tools (though none are listed among siblings), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or any contextual constraints. It's a bare statement of functionality with zero usage context, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize a new Warden project with Magento 2 environment
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path where the project should be initialized | |
| project_name | Yes | Name for the Warden environment | |
| environment_type | No | Environment type (default: magento2) | magento2 |
| php_version | No | PHP version (default: 8.3) | 8.3 |
| mysql_distribution | No | MySQL distribution (default: mariadb) | mariadb |
| mysql_version | No | MySQL version (default: 10.6) | 10.6 |
| node_version | No | Node.js version (default: 20) | 20 |
| composer_version | No | Composer version (default: 2) | 2 |
| opensearch_version | No | OpenSearch version (default: 2.12) | 2.12 |
| redis_version | No | Redis version (default: 7.2) | 7.2 |
| enable_redis | No | Enable Redis (default: true) | |
| enable_opensearch | No | Enable OpenSearch (default: true) | |
| enable_varnish | No | Enable Varnish (default: true) | |
| enable_rabbitmq | No | Enable RabbitMQ (default: true) | |
| enable_xdebug | No | Enable Xdebug (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool initializes a project but doesn't describe what that entails: whether it creates files/directories, modifies system configurations, requires specific permissions, has side effects, or what happens on success/failure. For a tool with 15 parameters that likely creates infrastructure, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word contributing to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what 'initializing' entails operationally, what gets created or modified, potential side effects, or expected outcomes. For a tool that likely sets up development environments with multiple services, more context about the behavioral impact is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 15 parameters thoroughly with descriptions and defaults. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for adequate coverage through structured data alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Initialize') and resource ('new Warden project with Magento 2 environment'), providing a specific purpose. However, it doesn't explicitly differentiate from sibling tools like 'warden_start_project' or 'warden_list_environments', which might cause confusion about when to use this initialization tool versus starting an existing project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether Warden must be installed), when-not-to-use scenarios (e.g., for existing projects), or how it relates to sibling tools like 'warden_start_project' for starting initialized projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all running Warden environments with their directories (returns structured JSON)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns structured JSON, which is useful behavioral context, but does not cover other aspects like performance, error handling, or authentication needs, leaving gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes essential details about the output format, with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is fairly complete for a list operation, covering what it does and the return format. However, it could be more robust by addressing potential limitations or dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is high. The description adds value by clarifying the output format ('structured JSON'), which is not covered by the schema, compensating for the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all running Warden environments') with specific scope ('with their directories'), and distinguishes from siblings like warden_start_project or warden_stop_svc by focusing on listing rather than controlling environments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to view running environments, but lacks explicit guidance on when to use this versus alternatives like warden_start_project or warden_stop_svc, and does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run bin/magento command inside the php-fpm container
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to the project directory | |
| command | Yes | Magento CLI command (without 'bin/magento' prefix) | |
| args | No | Additional arguments for the command |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions running commands inside a container but lacks details on permissions, side effects (e.g., whether it modifies files or databases), error handling, or output format. This is inadequate for a tool that likely executes commands with potential system impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and easy to parse, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing CLI commands in a container, no annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects like safety, permissions, or what to expect in terms of results or errors, leaving significant gaps for an agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters well. The description adds minimal value beyond implying the command is run in a specific context (php-fpm container), but it doesn't provide additional syntax, examples, or constraints beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run') and target ('bin/magento command inside the php-fpm container'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like warden_php_script or warden_composer, which might also execute commands in containers, leaving some ambiguity about when this specific tool is preferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like warden_php_script or warden_composer. The description implies it's for Magento CLI commands, but it doesn't specify prerequisites, such as needing a running project or container, or exclusions for other types of commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a PHP script inside the php-fpm container
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to the project directory | |
| script_path | Yes | Path to the PHP script relative to project root | |
| args | No | Additional arguments to pass to the script |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions execution inside a container but doesn't cover critical aspects like permissions required, whether it's read-only or destructive, error handling, output format, or execution limits. For a tool that runs arbitrary code, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of running arbitrary PHP scripts in a containerized environment, the description is incomplete. With no annotations, no output schema, and minimal behavioral context, it lacks details on safety, output, errors, and integration with sibling tools, making it inadequate for informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (project_path, script_path, args) with clear descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as path format examples or script behavior details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run a PHP script') and the context ('inside the php-fpm container'), which distinguishes it from general PHP execution tools. However, it doesn't explicitly differentiate from siblings like warden_magento_cli or warden_run_unit_tests, which might also involve PHP execution in similar environments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like warden_magento_cli (for Magento-specific commands) or warden_run_unit_tests (for testing). The description implies usage for arbitrary PHP scripts but doesn't specify prerequisites, constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run unit tests using PHPUnit in the php-fpm container
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to the project directory | |
| config_file | No | PHPUnit configuration file (auto-detects phpunit.xml.dist or phpunit.xml) | |
| test_path | No | Optional path to specific test file or directory | |
| extra_args | No | Additional PHPUnit arguments |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the execution environment ('php-fpm container') but omits critical details such as whether this requires a running project, potential side effects (e.g., test output or database interactions), error handling, or runtime constraints. This is inadequate for a tool that likely involves system-level operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It front-loads the core action and specifies the technology and environment efficiently, making it easy to parse and understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of running unit tests in a containerized environment, no annotations, and no output schema, the description is insufficient. It fails to address behavioral aspects like execution context, output format, error conditions, or dependencies on other tools (e.g., warden_start_project), leaving significant gaps for an AI agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all parameters. The description adds no additional semantic context beyond implying PHPUnit usage, which is already covered by the tool's purpose. This meets the baseline for high schema coverage but doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run unit tests') and the technology used ('using PHPUnit in the php-fpm container'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like warden_php_script or warden_magento_cli, which could also involve PHP execution in similar contexts, leaving some ambiguity about when this tool is uniquely appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., needing a running project or specific setup), exclusions (e.g., not for integration tests), or comparisons to siblings like warden_php_script for general PHP execution. This leaves the agent without clear direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a Warden project environment
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to the project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Start') but lacks details on what 'starting' entails (e.g., does it launch services, set up configurations, require specific permissions?), potential side effects, or error conditions. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, earning a top score for brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'starting a project environment' (likely involving multiple steps or services), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, what happens during execution, or how it interacts with siblings, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'project_path' clearly documented in the schema. The description adds no additional semantic context about the parameter (e.g., format examples, what constitutes a valid path), so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start') and resource ('a Warden project environment'), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'warden_start_svc' or 'warden_stop_project', which would require more specific context about what distinguishes starting a project environment from other start/stop operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an initialized project), exclusions, or comparisons to siblings like 'warden_init_project' or 'warden_stop_project', leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start Warden system services
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to the project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Start' implies a state-changing operation, but the description doesn't reveal what permissions are needed, whether the operation is reversible, what happens if services are already running, or what side effects might occur. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'starting services' entails, what happens on success/failure, or how this differs from related tools. The context signals show this is a single-parameter tool, but the description doesn't provide enough operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so the parameter 'project_path' is documented in the schema. The description adds no additional parameter semantics beyond what's already in the structured data, which meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start') and target resource ('Warden system services'), which provides a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'warden_start_project', leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'warden_start_project' or 'warden_stop_svc'. There's no mention of prerequisites, dependencies, or appropriate contexts for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a Warden project environment
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to the project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Stop') but doesn't explain what 'stop' entails (e.g., whether it halts containers, shuts down services, or destroys data), potential side effects, permissions required, or error conditions. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action and target, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavior, side effects, success/failure indicators, and how it relates to sibling tools. The agent would need to guess about the tool's impact and proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'project_path' well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and target ('a Warden project environment'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'warden_stop_svc' (which stops services rather than projects), but the specificity of 'project environment' provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the project must be running), contrast with 'warden_stop_svc', or indicate when not to use it. The agent must infer usage from the tool name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop Warden system services
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to the project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool stops services but doesn't mention whether this requires specific permissions, if the action is reversible, what happens to dependent processes, or any rate limits. For a potentially destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a potentially destructive operation with no annotations and no output schema), the description is incomplete. It doesn't explain what 'stopping' entails, what services are affected, or what the expected outcome is. For a tool that might impact system state, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'project_path'. The description adds no additional meaning about this parameter beyond what the schema provides, such as why the project path is needed or how it relates to stopping services. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and the resource ('Warden system services'), providing a specific verb+resource combination. However, it doesn't differentiate from its sibling 'warden_stop_project', which might handle broader project-level stopping versus service-specific stopping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'warden_stop_project' or 'warden_start_svc'. It lacks context about prerequisites, exclusions, or typical scenarios for stopping services versus stopping the entire project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose with no ambiguity. Each tool targets a specific action within the Warden Magento environment, such as running commands, managing projects, or controlling services. The descriptions clearly differentiate between database queries, Composer commands, Magento CLI operations, and environment management tasks.
All tools follow a perfect 'warden_verb_noun' pattern throughout. The naming is completely consistent with snake_case used uniformly across all 11 tools. This predictable pattern makes it easy for agents to understand and select the right tool for each operation.
The 11 tools are well-scoped and appropriate for a Magento development environment server. Each tool earns its place by covering essential operations like project initialization, environment management, command execution, and testing. The count is neither too sparse nor overwhelming for the domain.
The tool surface provides complete coverage for Magento development workflows in Warden environments. It includes project lifecycle management (init, start, stop), command execution (Composer, Magento CLI, PHP scripts), database operations, testing capabilities, and service management. No obvious gaps exist for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/run-as-root/warden-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
