Allows running Composer commands like install and update within RollDev project environments to manage PHP dependencies.
Enables interaction with project containers and Docker networks to manage and list project environments.
Provides tools to control OpenSearch system services within RollDev development environments.
Enables the execution of PHP scripts and command-line operations within containerized project environments.
Allows for the management and control of Redis system services used within RollDev projects.
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., "@RollDev MCP Server Flush the Magento cache for the project in ./my-magento-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 Model Context Protocol (MCP) server for RollDev + Magento 2 development environments. This server enables Claude and other LLMs to interact with RollDev projects, manage environments, execute commands, and initialize new Magento 2 projects seamlessly.
Environment Control: List, start, and stop RollDev project environments
Service Management: Control RollDev system services (database, Redis, OpenSearch, etc.)
Project Initialization: Create new Magento 2 projects with automatic configuration
Database Operations: Execute SQL queries directly in project databases
PHP Script Execution: Run PHP scripts within project containers
Magento CLI Access: Execute Magento commands through roll magento
Composer Integration: Run Composer commands in project environments
Command Timeouts: All commands have appropriate timeouts to prevent hanging (5-15 min depending on operation)
Output File Redirection: Option to save command output to log files for later investigation
Related MCP server: DAZ Command MCP Server
RollDev installed and configured
Node.js 18+
Active RollDev project environments (for some operations)
{
"mcpServers": {
"rolldev": {
"command": "npx",
"args": [
"-y",
"@disrex/rolldev-mcp-server"
]
}
}
}Add this configuration to your Claude for Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Clone this repository:
git clone https://github.com/dockergiant/rolldev-mcp-server.git
cd rolldev-mcp-serverInstall dependencies:
npm installAdd to Claude configuration:
{
"mcpServers": {
"rolldev": {
"command": "node",
"args": ["/path/to/rolldev-mcp-server/server.js"]
}
}
}Lists all running RollDev environments with structured information including project names, paths, URLs, Docker networks, and container counts.
Starts a RollDev project environment.
project_path: Path to the project directory
Stops a RollDev project environment.
project_path: Path to the project directory
Starts RollDev system services.
project_path: Path to the project directory
Stops RollDev system services.
project_path: Path to the project directory
Executes SQL queries in project databases.
project_path: Path to the project directory
query: SQL query to execute
database: Database name (optional, defaults to "magento")
Runs PHP scripts inside project containers.
project_path: Path to the project directory
script_path: Path to PHP script relative to project root
args: Additional arguments (optional)
Executes Magento CLI commands (5 minute timeout).
project_path: Path to the project directory
command: Magento command (without 'bin/magento' prefix)
args: Additional arguments (optional)
save_output_to_file: Save full output to a log file (optional, default: false)
Runs Composer commands in project environments (10 minute timeout).
project_path: Path to the project directory
command: Composer command (e.g., "install", "update", "require symfony/console")
save_output_to_file: Save full output to a log file (optional, default: false)
Initializes new Magento 2 projects with automatic configuration (15 minute timeout).
project_name: Project name (lowercase, letters, numbers, hyphens only)
magento_version: Magento version (optional, defaults to "2.4.x")
target_directory: Target directory (optional, defaults to current directory)
Here are some example interactions you can try with Claude after setting up the RollDev MCP server:
"Can you list all my RollDev environments?"
"Start the project at /path/to/my-magento-project"
"Stop the services for my current project"
"Run the query 'SELECT * FROM admin_user LIMIT 5' in my project"
"Show me all enabled modules in the database"
"Check the current configuration values for my store"
"Execute 'cache:flush' Magento command in my project"
"Run 'setup:upgrade' on my Magento installation"
"List all available Magento CLI commands"
"Initialize a new Magento 2.4.7 project called 'my-store'"
"Create a Magento project with the latest version in /Users/dev/projects"
"Install dependencies with Composer in my project"
"Require the symfony/console package in my project"
"Run setup:upgrade and save the output to a file for investigation"
"Execute composer install with output saved to a log file"
# Start in development mode with debugging
npm run dev
# Run tests
npm testYou can test the server using the MCP Inspector:
npx @modelcontextprotocol/inspector node server.jsFork the repository from dockergiant/rolldev-mcp-server
Create your feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
If you encounter any issues or have questions:
Check the GitHub Issues section
Consult the MCP documentation at modelcontextprotocol.io
Open a new issue with detailed reproduction steps
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') | |
| save_output_to_file | No | Save full output to a log file for later investigation (useful for long output) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It fails to disclose side effects, error handling, permissions, or dependencies (e.g., does the container have Composer installed?).
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 concise sentence, but it omits necessary details, so it earns a 4 for being efficient but not optimally informative.
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?
With no output schema and only one sentence, the description lacks context on return values, typical use cases, or how to handle long outputs (despite a parameter for saving output).
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 coverage is 100%, so the description adds no additional meaning. Baseline 3 applies, as the schema already documents parameters adequately.
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 specifies the tool's action ('Run') and resource ('Composer commands inside the php-fpm container'), which is distinct from sibling tools like rolldev_magento_cli or rolldev_php_script.
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, nor any exclusions or prerequisites. Sibling tools exist but are not referenced.
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 RollDev 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 the full burden of disclosing behavioral traits. It only states 'Run a SQL query' without addressing permissions, side effects (e.g., destructive writes), rate limits, or what happens on execution (e.g., returns result set or error). This is a critical gap for a database 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 sentence, front-loaded with the action. However, it is underspecified; while concise, it fails to earn its place by providing minimal useful context. A more informative sentence could maintain conciseness while adding value.
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 executes arbitrary SQL, it lacks essential context: expected output (e.g., result rows), execution behavior (e.g., read-only vs. write), and potential risks. No output schema exists, and the description does not compensate, leaving an LLM uncertain about what to expect.
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 coverage is 100% with parameter descriptions, so the baseline is 3. The description adds no extra meaning beyond the schema, merely saying 'Run a SQL query' without detailing parameter roles. It neither improves nor degrades the schema's clarity.
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 'Run' and resource 'a SQL query in the RollDev database', which distinguishes it from sibling tools like composer or CLI operations. However, 'RollDev database' is vague without specifying which database, though the schema later reveals a default database.
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. There is no mention of prerequisites, when not to use it, or comparison to sibling tools like rolldev_magento_cli which might also execute SQL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all running RollDev 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 must carry the behavioral disclosure burden. It indicates a read operation (list), which is non-destructive. However, it does not specify authentication needs, rate limits, or side effects, but the explicit mention of 'returns structured JSON' clarifies the safe read nature.
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, front-loaded sentence that efficiently states the purpose and output. No redundant or extra information is present.
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?
Though the tool is simple with no parameters, the description lacks details about the output structure (e.g., fields like environment name or status) that would be helpful since there is no output schema. However, the main action and return type are covered, so it is minimally adequate.
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 tool has zero parameters, and schema coverage is 100% by default. According to the rules, a baseline of 4 applies. The description adds value by stating that the output includes directories and is structured JSON, which goes beyond the empty 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 specifies the action ('list') and resource ('running RollDev environments'), and mentions the return format ('structured JSON') and fields ('directories'). This distinguishes it from sibling tools like rolldev_start_project or rolldev_db_query.
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: use when you need to list running environments. However, it does not explicitly state when not to use or mention alternatives among siblings, which is less critical for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize a new Magento 2 project using RollDev's magento2-init command with automatic version configuration
| Name | Required | Description | Default |
|---|---|---|---|
| project_name | Yes | Name of the Magento 2 project (lowercase letters, numbers, and hyphens only) | |
| magento_version | No | Magento version to install (default: 2.4.x). Examples: 2.4.x, 2.4.7, 2.4.7-p3, 2.4.8 | 2.4.x |
| target_directory | No | Directory to create project in (optional, defaults to current directory). Project will be created in a subdirectory named after the project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only mentions 'automatic version configuration' without elaborating on side effects, prerequisites, or potential destructive actions like overwriting files.
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 sentence that is succinct but lacks structure. It is not verbose but could be more informative without being lengthy.
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?
With no output schema and no annotations, the description should provide more context about the initialization process, but it only mentions version configuration. Missing details about project structure creation, network calls, or prerequisites.
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 coverage is 100%, so the description adds little beyond what the schema already provides. Baseline 3 is appropriate; no additional clarifications over schema descriptions.
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 it initializes a new Magento 2 project using a specific command with automatic version configuration, distinguishing it from sibling tools like rolldev_magento_cli and rolldev_composer.
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 on when to use this tool versus alternatives (e.g., rolldev_start_project) or when not to use it. The description lacks contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run roll 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 | |
| save_output_to_file | No | Save full output to a log file for later investigation (useful for long output) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states that the command is run inside a container, with no mention of return values, error handling, persistence, or side effects. This is insufficient for a tool that executes arbitrary commands.
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 short sentence, making it concise and front-loaded. However, the word 'roll' seems out of place (likely a typo), slightly detracting from 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?
The tool is relatively simple with 4 parameters and no output schema. The description does not explain return values or output behavior, but given the schema coverage and tool purpose, it is minimally adequate.
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, so the schema already documents all parameters. The description adds no additional meaning beyond what is in the schema, achieving the baseline of 3.
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?
Description clearly indicates the tool runs a Magento CLI command inside a php-fpm container. The verb 'run' and resource 'magento command' are specific, and it distinguishes from sibling tools like rolldev_composer or rolldev_db_query. However, the phrasing 'roll magento command' is slightly ambiguous (possibly a typo), preventing 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 implies usage for running Magento CLI commands in a container, but provides no explicit guidance on when to use this tool versus alternatives like rolldev_magento2_init or rolldev_php_script. No when-not or alternative suggestions are given.
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 provided, and the description only states the action without disclosing any behavioral traits such as permissions, side effects, error handling, or output 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?
Single sentence, no wasted words, front-loaded. Could be slightly more descriptive but remains efficient.
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?
No output schema and description does not hint at return values, errors, or execution context. Incomplete for a tool that runs arbitrary scripts.
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 coverage is 100% and descriptions in the schema are clear. The tool description adds no extra meaning beyond what the schema already provides.
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?
Description clearly states the tool runs a PHP script inside the php-fpm container, using a specific verb and resource, and distinguishes it from sibling tools like rolldev_magento_cli or rolldev_composer.
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 on when to use this tool versus alternatives. Agent is not told when to prefer this over other script-running tools or context requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a RollDev 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 full burden for behavioral disclosure. It fails to mention side effects (e.g., what gets created or changed), required permissions, or whether the operation is synchronous. The single verb 'start' is insufficient.
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 very short (one sentence) with no wasted words. However, it lacks any structure (e.g., bullet points) and does not front-load critical information. It is concise but could be improved without adding length.
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 low complexity (1 param, no output schema), the description is too minimal. It does not explain what 'starting' a project environment entails, such as whether it returns environment details or requires prior setup. This leaves the agent underinformed.
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% coverage for the only parameter 'project_path', and its description is already adequate. The tool description adds no extra semantic context beyond what is in the schema, so baseline 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 'Start' and the resource 'RollDev project environment'. However, it does not differentiate from sibling tools like 'rolldev_start_svc' or 'rolldev_stop_project', which could cause ambiguity.
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 such as 'rolldev_list_environments' or 'rolldev_start_svc'. There are no prerequisites or explicit when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start RollDev 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?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic action. For a mutation tool, information about side effects, permissions, or reversibility is missing.
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 very short (3 words) and front-loaded, but it is so minimal that it provides little beyond the tool name. It is not verbose, but it sacrifices informativeness for brevity.
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 simplicity of the tool (1 parameter, no output schema, no annotations), the description is minimally adequate. However, it does not explain how this tool fits into the broader system of RollDev tools, such as its relationship to start_project or stop_svc.
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% coverage for the single parameter (project_path), so the description does not need to add further meaning. The baseline 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 (start) and the resource (RollDev system services). It distinguishes from siblings like rolldev_start_project by name, but does not explicitly explain the difference.
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 on when to use this tool versus alternatives such as rolldev_start_project or rolldev_stop_svc. The description lacks any context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a RollDev 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?
No annotations are provided, so the description must cover behavioral traits. It merely says 'stop' without explaining what stopping entails (e.g., kills processes, preserves state, is reversible). This leaves ambiguity for the agent.
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, concise sentence with no extraneous words. However, it is so minimal that it may not fully serve its purpose; conciseness should not sacrifice essential information.
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 has only one parameter and no output schema, the description could still provide more context about the stopping process or effects. It lacks completeness for an agent to understand the full impact.
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 (project_path described as 'Path to the project directory'). The description adds no further semantics beyond what the schema already provides, so baseline applies.
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 ('a RollDev project environment'). It distinguishes from sibling tools like rolldev_start_project and rolldev_stop_svc by specifying 'project environment' rather than service or other component.
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 on when to use this tool versus alternatives (e.g., stop_svc). It does not specify prerequisites, such as the project being running, or when not to use (e.g., if the project is already stopped).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop RollDev 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?
No annotations provided; description only says 'stop' without detailing side effects, what services are affected, or whether it's destructive. Lacks clarity on behavior beyond the obvious.
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?
Extremely brief (one phrase), but concise. No wasted words, yet lacks detail that could improve usability without making it longer.
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 simple tool, description is minimal; missing usage context and behavioral details. Agent may not know when to invoke or what consequences to expect.
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 coverage is 100% (one parameter described). Description does not add extra meaning beyond the schema field 'Path to the project directory', so baseline 3 applies.
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?
Description clearly states it stops RollDev system services, differentiating from siblings like rolldev_stop_project. Verb 'stop' and resource 'RollDev system services' are specific.
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 on when to use this tool vs alternatives. Does not mention prerequisites or typical usage sequence with other tools like rolldev_start_svc.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no ambiguity. For example, rolldev_start_project and rolldev_stop_project handle project lifecycle, while rolldev_db_query and rolldev_php_script target specific execution contexts. The descriptions clearly differentiate between environment management, service control, and command execution.
All tools follow a perfect 'rolldev_verb_noun' pattern with consistent snake_case throughout. The naming is highly predictable, making it easy to understand each tool's function at a glance, such as rolldev_list_environments for listing and rolldev_magento2_init for initialization.
With 10 tools, the count is well-scoped for a development environment management server. Each tool earns its place by covering distinct aspects like project control, service management, and command execution, without being overwhelming or insufficient for the domain.
The tool set provides strong coverage for RollDev's domain, including environment lifecycle (start/stop), service management, database queries, and Magento/PHP operations. A minor gap exists in monitoring or status-checking tools beyond listing environments, but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Build, deploy and manage MaShop e-commerce projects from Claude, Cursor or any MCP client.
Devopness MCP server for DevOps happiness! Empower AI Agents to deploy apps and infra, to any cloud.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dockergiant/rolldev-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
