This MCP server lets LLMs manage RollDev/Magento 2 development environments and run common project commands.
List running RollDev environments with structured JSON details.
Start and stop RollDev project environments.
Start and stop RollDev system services.
Run SQL queries in a project database, defaulting to magento.
Execute PHP scripts inside the php-fpm container.
Run Magento CLI commands through roll magento.
Run Composer commands in project environments.
Initialize new Magento 2 projects with configurable version and target directory.
Save long Magento CLI or Composer output to log files for later investigation.
Per the README, also read Roll Inspector diagnostics such as service health, traces, hotspots, request timelines, and service info without changing the environment.
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 "Deploy 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)
These tools read from Roll Inspector (https://inspector.<TRAEFIK_DOMAIN>) and never change the environment. Each takes project_path, reads ROLL_ENV_NAME, TRAEFIK_DOMAIN and ROLL_INSPECTOR the way roll does (${ROLL_HOME_DIR:-~/.roll}/.env.roll, then .env there, then the nearest project .env.roll, each overriding the one before), and accepts save_output_to_file like the tools above. Output is compact text plus a JSON block. Anything over 60,000 characters is cut off with a hint to use save_output_to_file.
Tool | Returns |
| Service health, warnings and their copyable fixes |
| Trace list with cost split per category. Filters: |
| Analysis of one trace |
| Slowest routes, most expensive operations and repeated calls across all stored traces. |
| Timeline entry for a |
|
|
Connection details:
The tool connects with node:https and trusts roll's root CA from ${ROLL_SSL_DIR}/rootca/certs/ca.cert.pem. ROLL_SSL_DIR defaults to ${ROLL_HOME_DIR}/ssl and ROLL_HOME_DIR to ~/.roll, as in bin/roll. Set either variable in the MCP server's environment to override.
Requests time out after 10 seconds.
With ROLL_INSPECTOR unset or 0, the tool answers with the fix: set ROLL_INSPECTOR=1 in .env.roll and run roll env up.
It reports a stopped Inspector container (roll env up), certificate problems (roll sign-certificate <domain>), an unresolvable host and a 403 from the gate in plain words.
rolldev_inspector_trace and rolldev_inspector_hotspots need an Inspector image with the analysis and hotspots endpoints. Older images get a message to update.
Trace and hotspot answers need the project's .env.roll to have ROLL_INSPECTOR=1 and ROLL_INSPECTOR_TRACE=1. Varnish HITs have no trace, so rolldev_inspector_request finds nothing for them. User docs: roll-docker-stack/docs/inspector/api-and-extensions.md.
The logic lives in inspector.cjs, and test/inspector.test.js runs it against a fake transport.
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"
These prompts only read; no Inspector tool purges, flushes or switches anything. 16. "Why is /category-1.html slow? Check the Inspector trace" 17. "Show the Inspector hotspots for this project" 18. "Which routes in this project repeat the same SQL query (N+1)?" 19. "Is RabbitMQ healthy? Ask Inspector for the overview" 20. "Was the last request to /checkout/cart a Varnish MISS, and why?"
# 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 |
|---|---|---|---|
| command | Yes | Composer command to execute (e.g., 'install', 'update', 'require symfony/console', 'require-commerce') | |
| project_path | Yes | Path to the project directory | |
| 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 |
|---|---|---|---|
| query | Yes | SQL query to execute | |
| database | No | Database name (optional, defaults to magento) | magento |
| 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 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.
Hotspots across all stored traces: slowest routes, most expensive operations and repeated calls. Read-only: never changes the environment.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows per section (optional) | |
| project_path | Yes | Path to the project directory (holds .env.roll) | |
| save_output_to_file | No | Save the full output to a log file and return a preview (optional, default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description bears the full burden of behavioral disclosure. Stating 'Read-only: never changes the environment' is a crucial behavioral guarantee for a developer tool, preventing misuse.
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 definition is highly concise. It front-loads the core function and safety guarantee into two short, impactful sentences without any filler.
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 that there is no output schema, the description provides the necessary context regarding the tool's analytical focus and safety profile, making it complete enough for an agent to confidently select it for the correct problem type.
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%, meaning the structure is fully defined. The description reinforces the intent of the parameters (output format, read-only nature) but does not add substantial semantic meaning beyond what the schema provides for the inputs.
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 defines the scope of the tool, stating it finds 'Hotspots' specifically defined as 'slowest routes, most expensive operations and repeated calls.' This is highly specific and distinguishes it from a general trace view.
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?
It clearly defines the scenario where the tool should be used (identifying performance bottlenecks) but does not explicitly advise against using it for different, related tasks (e.g., detailed tracing vs. high-level summary).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Roll Inspector overview: service health, warnings and their copyable fixes. Read-only: never changes the environment.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to the project directory (holds .env.roll) | |
| save_output_to_file | No | Save the full output to a log file and return a preview (optional, default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden; it does disclose the critical behavioral fact that the tool is read-only and never mutates the environment, which is genuinely useful. However, it says nothing about whether a running environment is required, output volume, or performance cost.
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?
Two short sentences with zero filler; the purpose is front-loaded and the read-only guarantee follows immediately. Nothing could be removed without losing signal.
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 two-parameter, read-only diagnostic with no output schema, the description adequately conveys what is returned (health, warnings, fixes) and its safety profile. The main omission is any hint about preconditions such as an active environment.
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 project_path and save_output_to_file are already fully documented in the schema. The description adds no extra meaning about either parameter, so the 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?
The description names a specific resource (Roll Inspector overview) and enumerates what it surfaces: service health, warnings, and copyable fixes. The 'overview' framing distinguishes it from the trace/hotspot/request siblings, though no sibling is named explicitly.
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?
It implies usage as a first-stop diagnostic (health + warnings) and notes it is read-only, but never says when to prefer it over siblings like rolldev_inspector_service or rolldev_list_environments. Prerequisites (e.g., project must be started) are unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Timeline entry for a URL: Varnish result and why it missed, plus the lanes (PHP, cache, search, queue). Read-only: never changes the environment.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Full URL or a part of it, e.g. /category-1.html | |
| xid | No | Varnish transaction id (X-Varnish) for an exact match | |
| limit | No | Number of matching entries, newest first (default 1) | |
| project_path | Yes | Path to the project directory (holds .env.roll) | |
| save_output_to_file | No | Save the full output to a log file and return a preview (optional, default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavior, and it does disclose the key trait: 'Read-only: never changes the environment', which is genuinely useful safety context. It also hints at the payload (Varnish result, why it missed, lanes), but omits what happens when no entry matches, whether the project must be running, and any volume/pagination behavior beyond the limit parameter.
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?
Two short sentences, the payload summary front-loaded before the safety note, with no filler. The phrasings 'why it missed' and 'lanes' are slightly jargon-dependent but compact rather than redundant.
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 five parameters, no output schema and no annotations, the description should say more about return shape and preconditions. It covers the content categories returned and the read-only nature, but leaves the relationship to the other inspector tools and the environment prerequisites unstated.
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 every parameter (url, xid, limit, project_path, save_output_to_file) is already documented and the baseline is 3. The description adds only the framing that lookup is by URL or an exact Varnish XID match; it adds nothing on limit, project_path resolution or the file-saving preview behavior.
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?
States a concrete resource (a per-request timeline entry keyed on a URL) and enumerates what it contains: Varnish result plus the PHP, cache, search and queue lanes. That is more specific than a generic 'inspect' tool and differentiates it from rolldev_inspector_overview/traces by its single-request granularity, though it never names those siblings explicitly.
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?
Usage is only implied: the URL/xid framing suggests 'use when you have a specific request and want its timeline', but the description never says when to prefer this over rolldev_inspector_trace, rolldev_inspector_traces or rolldev_inspector_overview. No prerequisites (e.g. project must be started) or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health or info of one Inspector service adapter. Read-only: never changes the environment.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | varnish, redis, search or rabbitmq | |
| section | No | Default: health | |
| project_path | Yes | Path to the project directory (holds .env.roll) | |
| save_output_to_file | No | Save the full output to a log file and return a preview (optional, default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description still proactively declares 'Read-only: never changes the environment' — exactly the safety signal an agent needs before invoking. It does not cover output shape, log-file behavior, or failure modes, which keeps it out of 5 territory.
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?
Two compact sentences with zero waste; the action comes first and the read-only guarantee is front-loaded in a single clause. Nothing to trim.
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 four-parameter diagnostic tool with full schema coverage and no output schema, the description is minimally sufficient but leaves gaps: what 'health' vs 'info' actually return, that project_path must point at a directory containing .env.roll, and how it relates to rolldev_inspector_overview are all left to inference.
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 two enums fully enumerated, so the schema carries parameter meaning. The description only echoes the health/info split ('Health or info') and adds nothing about kind selection, project_path (.env.roll) resolution, or the save_output_to_file preview behavior.
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?
States a specific verb+resource: return health or info for one Inspector service adapter. The enum kinds (varnish/redis/search/rabbitmq) and the 'one ... adapter' scope let an agent tell it apart from the aggregate inspector_overview. It stops short of naming that sibling explicitly, so it isn't a 5.
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?
Usage is only implied: 'one Inspector service adapter' suggests per-service inspection versus the broader overview/traces/hotspots siblings, but the description never says when to choose this tool over those. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bottleneck analysis of one trace: cost per category, hot spans, repeated (N+1) calls and the slowest calls, as compact text plus JSON. Raw spans only with include_spans (top 200 by self time). Read-only: never changes the environment.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Trace id from rolldev_inspector_traces | |
| project_path | Yes | Path to the project directory (holds .env.roll) | |
| include_spans | No | Also return the raw spans, capped at 200 by self time (default: false) | |
| save_output_to_file | No | Save the full output to a log file and return a preview (optional, default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does much of it: it declares 'Read-only: never changes the environment', states the output shape ('compact text plus JSON'), and discloses the 200-span cap tied to include_spans. It omits error behavior, auth/env prerequisites, and whether the analysis is sampled or truncated beyond the span cap.
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?
Two sentences, both dense and front-loaded: the analytical output comes first, then the conditional span payload and the safety guarantee. No filler and no repetition of the tool name.
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?
There is no output schema, so the description must characterize the return value, and it does — cost per category, hot spans, N+1 calls, slowest calls, text plus JSON. Combined with 100% parameter coverage this is nearly complete; a short note on what 'cost' means (tokens/money/time) would close the gap.
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 schema already documents all four parameters including the 200-span cap on include_spans. The description only restates the include_spans behavior and adds nothing about save_output_to_file or about how project_path affects the analysis, so it stays at the baseline.
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 names a specific verb+resource ('Bottleneck analysis of one trace') and enumerates exactly what is produced: cost per category, hot spans, N+1 calls, slowest calls. It is clearly distinguishable from a sibling like rolldev_inspector_traces (listing traces) by the 'one trace' scope, but it never explicitly names the alternatives it contrasts with.
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?
Usage is implied rather than stated: you call this to diagnose a single trace whose id you already have. The schema field note ('Trace id from rolldev_inspector_traces') supplies the discovery path, but the description itself gives no when-to-use/when-not guidance versus rolldev_inspector_hotspots, rolldev_inspector_request or rolldev_inspector_service.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent PHP traces (one line each, with the cost split per category). Read-only: never changes the environment.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | slowest (default) or recent | |
| limit | No | Maximum number of traces (default 20) | |
| route | No | Only this route, e.g. catalog/category/view | |
| min_ms | No | Only traces slower than this many milliseconds | |
| project_path | Yes | Path to the project directory (holds .env.roll) | |
| save_output_to_file | No | Save the full output to a log file and return a preview (optional, default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description does carry the key safety signal itself: "Read-only: never changes the environment." It also discloses the output shape (one line per trace, cost split by category). It says nothing about ordering defaults, volume expectations, or whether traces are sampled, so it is adequate but not rich.
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?
Two short sentences with zero padding, leading with the action and the result format and closing with the safety constraint. Every clause earns its place.
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 filterable list tool with no output schema and no annotations, the description covers the read-only guarantee and the rough return shape, which is the minimum needed. It still leaves gaps on result ordering behavior beyond the sort parameter and what a truncated preview looks like when save_output_to_file is set.
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 every parameter including sort, min_ms, route, and save_output_to_file is already documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, so the 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?
States a specific verb and resource ("List recent PHP traces") plus the shape of each result (one line with per-category cost split). It does not explicitly distinguish itself from the sibling rolldev_inspector_trace (singular), so an agent must infer that this is the list view versus the detail view.
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?
"List recent PHP traces" implies a discovery/overview use case, and the sibling names hint at a trace-detail alternative. However, the description never says when to pick this over rolldev_inspector_trace, inspector_hotspots, or inspector_request, and offers no exclusions or prerequisites.
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 |
|---|---|---|---|
| args | No | Additional arguments for the command | |
| command | Yes | Magento CLI command (without 'bin/magento' prefix) | |
| project_path | Yes | Path to the project directory | |
| 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 |
|---|---|---|---|
| args | No | Additional arguments to pass to the script | |
| script_path | Yes | Path to the PHP script relative to project root | |
| project_path | Yes | Path to the project directory |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.0rolldev_inspector_hotspotsrolldev_inspector_overviewrolldev_inspector_requestrolldev_inspector_servicerolldev_inspector_tracerolldev_inspector_tracesv1.1.0rolldev_composerrolldev_db_queryrolldev_list_environmentsrolldev_magento_clirolldev_magento2_initrolldev_php_scriptrolldev_start_projectrolldev_start_svcrolldev_stop_projectrolldev_stop_svcScored across 16 tools
Most tools have clearly distinct targets: start/stop for projects vs services, and the Inspector tools form a readable granularity ladder (overview → traces → trace → hotspots → request → service). Mild overlap exists among the command-runner tools (magento_cli, composer, php_script, db_query) and between inspector_overview and inspector_service, but names and descriptions make selection reasonably clear.
All tools share a consistent rolldev_ prefix and snake_case formatting with predictable verb_noun or resource_noun patterns. Minor deviation: some entries are noun-only command runners (rolldev_composer, rolldev_magento_cli) while others use explicit verbs, and trace/traces differ only by plural, but nothing is confusing.
16 tools is slightly above the comfortable 3-15 range but each one covers a distinct operation (environment lifecycle, command execution, and Inspector diagnostics). The six Inspector tools are a justified, cohesive subsystem rather than filler.
Core lifecycle is covered: list/start/stop environments and services, project scaffolding via magento2_init, command/DB/PHP execution, plus a full read-only diagnostics suite. Gaps remain — no restart, no log streaming, no environment configuration or teardown/delete beyond stop — but these are workable around.
Hosted Magento MCP server for Claude, ChatGPT and Cursor, with each action switched per account.
MCP server that lets your AI assistant build and deploy apps, hosting each one at a live URL.
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.
