The Magento 2 Development MCP Server provides comprehensive Magento 2 development and administration tools through AI agents (Claude, Cursor, etc.), covering the following areas:
DI & Module Management
Retrieve DI preferences across scopes (global, adminhtml, frontend, etc.)
List modules (with enabled/disabled filtering), observers (filterable by event), and themes
Create new modules with optional components (blocks, helpers, models, composer.json, readme, strict types)
Inspect plugin/interceptor chains for any class or method across all DI scopes
Cache Management
Clean, flush, enable, disable, and check status of specific or all cache types
Inspect individual cache entries by key
System Diagnostics
Retrieve system information and verify system requirements/configuration health
Configuration Management
View and set system configuration values by path, scope, and scope ID (with optional encryption)
Get and set store-level configuration values
Database Tools
Execute raw SQL queries against the Magento 2 database
Check database status to determine if setup:upgrade is needed
Setup & Deployment
Run setup upgrades (with option to keep generated files)
Compile DI configuration
Deploy static content with options for languages, themes, parallel jobs, and force deployment
Store & Website Management
List stores, websites, store views, base URLs, and all URLs (filterable by store ID)
Cron Management
List all cron jobs and their configuration
Run specific cron jobs or entire cron groups
Additional Features
Automatic detection of Docker environments (Warden, DDEV, docker-magento, docker-compose)
Flexible output formats: table, JSON, and CSV
Support for custom magerun2 binary paths via environment variables, with automatic fallback to local execution
Enables creation of Magento 2 modules with composer.json files for dependency management and package distribution
Provides access to Magento 2's GraphQL API context through dependency injection preference management
Generates PHP code for Magento 2 modules including blocks, helpers, models, and setup scripts with strict type declarations
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., "@Magento 2 Development MCP Server list all modules and show which ones are enabled"
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.
This project is abandoned since it mainly exposed magerun commands through an MCP. Magerun now offers an internal MCP server; just run magerun2 mcp:server:start - see magerun2 9.3.0 release notes.
A Model Context Protocol (MCP) server for Magento 2 development, designed to integrate with AI agents like Claude, Cursor, Continue.dev, and Augment Code.
npx -y @elgentos/magento2-dev-mcpRelated MCP server: RollDev MCP Server
Add to your AI agent's MCP configuration:
{
"mcpServers": {
"magento2-dev": {
"command": "npx",
"args": ["-y", "@elgentos/magento2-dev-mcp"]
}
}
}Restart your AI agent to load the MCP server
Start using Magento 2 development tools through your AI agent!
See AI Platform Configuration Examples for platform-specific setup instructions.
The server automatically detects Docker-based Magento environments and routes magerun2 commands through the container:
Environment | Detection | Command prefix |
Warden |
|
|
DDEV |
|
|
docker-magento |
|
|
docker-compose |
|
|
For docker-compose the server tries the service names phpfpm, php-fpm, and php in order.
If Docker execution fails, the server falls back to running magerun2 locally.
Variable | Description | Default |
| Override the magerun2 binary name or path |
|
Use MAGERUN2_COMMAND when your system installs the binary under a different name (e.g. n98-magerun2) or when you need to specify an absolute path:
{
"mcpServers": {
"magento2-dev": {
"command": "npx",
"args": ["-y", "@elgentos/magento2-dev-mcp"],
"env": {
"MAGERUN2_COMMAND": "n98-magerun2"
}
}
}
}Parameters:
scope (optional): The scope to get DI preferences for
Options: global, adminhtml, frontend, crontab, webapi_rest, webapi_soap, graphql, doc, admin
Default: global
Available Scopes:
global - Global scope (default)
adminhtml - Admin area
frontend - Frontend/storefront area
crontab - Cron job execution context
webapi_rest - REST API context
webapi_soap - SOAP API context
graphql - GraphQL API context
doc - Documentation context
admin - Admin context (alternative to adminhtml)
Parameters:
format (optional): Output format (table, json, csv) - Default: table
enabled (optional): Show only enabled modules
disabled (optional): Show only disabled modules
Parameters:
format (optional): Output format (table, json, csv) - Default: table
event (optional): Filter by specific event name
Parameters:
format (optional): Output format (table, json, csv) - Default: table
Parameters:
vendorNamespace (required): Namespace (your company prefix)
moduleName (required): Name of your module
minimal (optional): Create only module file
addBlocks (optional): Add blocks
addHelpers (optional): Add helpers
addModels (optional): Add models
addSetup (optional): Add SQL setup
addAll (optional): Add blocks, helpers and models
enable (optional): Enable module after creation
modman (optional): Create all files in folder with a modman file
addReadme (optional): Add a readme.md file to generated module
addComposer (optional): Add a composer.json file to generated module
addStrictTypes (optional): Add strict_types declaration to generated PHP files
authorName (optional): Author for readme.md or composer.json
authorEmail (optional): Author email for readme.md or composer.json
description (optional): Description for readme.md or composer.json
Example Usage:
{
"name": "dev-module-create",
"arguments": {
"vendorNamespace": "MyCompany",
"moduleName": "CustomModule",
"addAll": true,
"enable": true,
"addReadme": true,
"addComposer": true,
"authorName": "John Doe",
"authorEmail": "john@example.com",
"description": "A custom Magento 2 module"
}
}Analyzes di.xml files across all DI scopes to find plugins for a given class. Resolves the full class hierarchy (parent classes and interfaces) so inherited plugins are included. Returns the plugin list, sort order, and full execution order chain per scope.
Parameters:
className (required): Fully qualified PHP class or interface name
methodName (optional): Method name to inspect. Omit to scan all public methods.
Example — single method:
{
"name": "dev-plugin-list",
"arguments": {
"className": "Magento\\Catalog\\Api\\ProductRepositoryInterface",
"methodName": "save"
}
}Example — scan all methods of a class:
{
"name": "dev-plugin-list",
"arguments": {
"className": "Magento\\Framework\\View\\LayoutInterface"
}
}Scopes checked: global, adminhtml, frontend, crontab, webapi_rest, webapi_soap, graphql
Docker support: Automatically detects Warden, DDEV, docker-magento, and docker-compose environments. Falls back to local PHP.
Parameters:
format (optional): Output format (table, json, csv) - Default: table
Parameters: None
Available Tools:
cache-clean - Clear specific or all caches
cache-flush - Flush specific or all caches
cache-enable - Enable specific cache types
cache-disable - Disable specific cache types
cache-status - Check cache status
cache-view - Inspect cache entries
See Cache Types Reference for details.
Parameters:
path (optional): Configuration path to show
scope (optional): Configuration scope (default, website, store)
scopeId (optional): Scope ID (website ID or store ID)
Parameters:
path (required): Configuration path to set
value (required): Value to set
scope (optional): Configuration scope
scopeId (optional): Scope ID
encrypt (optional): Encrypt the value
Store-specific configuration management for getting and setting configuration values at the store level.
Parameters:
query (required): SQL query to execute
format (optional): Output format (table, json, csv) - Default: table
Parameters:
keepGenerated (optional): Keep generated files during upgrade
Parameters: None
Parameters: None
Parameters:
languages (optional): Languages to deploy
themes (optional): Themes to deploy
jobs (optional): Number of parallel jobs
force (optional): Force deployment
Parameters:
format (optional): Output format (table, json, csv) - Default: table
Parameters:
format (optional): Output format (table, json, csv) - Default: table
Parameters:
format (optional): Output format (table, json, csv) - Default: table
storeId (optional): Store ID to filter URLs
Parameters:
format (optional): Output format (table, json, csv) - Default: table
Parameters:
format (optional): Output format (table, json, csv) - Default: table
Parameters:
job (optional): Specific cron job to run
group (optional): Cron group to run
MIT License - see LICENSE file for details.
Clear specific Magento 2 cache types or all caches
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Specific cache types to clean (leave empty for all caches) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action ('Clear') but does not specify whether this requires admin permissions, if it's destructive to system performance, what the typical response or errors might be, or any rate limits. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and appropriately sized for its purpose, with no wasted 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 complexity of a cache-clearing operation in a system like Magento 2, with no annotations and no output schema, the description is insufficient. It lacks details on permissions, side effects, error handling, or what happens after execution, making it incomplete for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'types' parameter well-documented. The description adds minimal value by implying the parameter's purpose ('specific cache types' vs 'all caches'), but does not provide additional semantics beyond what the schema already states, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear') and target ('Magento 2 cache types or all caches'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like cache-flush or cache-disable, which might have overlapping or distinct functionality, leaving some 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 cache-flush or cache-disable, nor are any prerequisites or exclusions mentioned. The description only states what the tool does, not when it should be selected over other cache-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disable specific Magento 2 cache types
| Name | Required | Description | Default |
|---|---|---|---|
| types | Yes | Cache types to disable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Disable') but doesn't mention potential side effects (e.g., performance impact, reversibility), permissions required, or error conditions. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a cache disable operation (a mutation with potential system impact), no annotations, and no output schema, the description is insufficient. It lacks details on behavior, outcomes, or error handling, leaving critical gaps for safe and effective tool invocation.
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 the parameter 'types' fully documented in the schema as 'Cache types to disable'. The description adds no additional semantic context beyond what the schema provides, such as examples of cache types or formatting details, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Disable') and target resource ('specific Magento 2 cache types'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'cache-enable' or 'cache-clean' beyond the verb choice, which is why it doesn't reach 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?
The description provides no guidance on when to use this tool versus alternatives like 'cache-enable' (for enabling) or 'cache-clean' (for cleaning). It lacks context about prerequisites, such as when disabling is appropriate compared to other cache operations, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable specific Magento 2 cache types
| Name | Required | Description | Default |
|---|---|---|---|
| types | Yes | Cache types to enable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects: whether this requires admin permissions, if it's reversible, what happens when enabling already-enabled caches, or potential performance impacts. The description is minimal and lacks operational context.
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 extremely concise at just 5 words, front-loading the essential information with zero wasted words. It efficiently communicates the core functionality without unnecessary elaboration or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'enabling' entails operationally, what the expected outcome is, or provide any context about Magento 2 cache types. Users must infer these details from the tool name and minimal description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'types' clearly documented as 'Cache types to enable'. The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline for adequate but not exceptional parameter documentation.
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 ('Enable') and target resource ('specific Magento 2 cache types'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from its sibling 'cache-disable', which performs the opposite operation, missing an opportunity for clearer differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'cache-disable' or 'cache-clean'. It doesn't mention prerequisites, typical use cases, or scenarios where enabling cache types is appropriate versus other cache management operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flush specific Magento 2 cache types or all caches
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Specific cache types to flush (leave empty for all caches) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('Flush') but does not disclose behavioral traits like whether this requires admin permissions, if it's destructive to system performance, potential side effects, or error handling. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a cache management tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects, usage context, and potential impacts, making it inadequate for safe and effective agent invocation.
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, clearly explaining the 'types' parameter. The description adds no additional meaning beyond what the schema provides, such as examples of cache types or usage nuances. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Flush') and resource ('Magento 2 cache types or all caches'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'cache-clean' or 'cache-disable', which might have overlapping or related functionality, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'cache-clean' or 'cache-disable'. It lacks context on prerequisites, exclusions, or specific scenarios, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of Magento 2 cache types
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. While 'Check' suggests a read-only operation, it doesn't explicitly state whether this requires specific permissions, what format the status information returns, whether it's real-time or cached data, or any rate limits. For a diagnostic tool with zero annotation coverage, this represents significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the essential purpose without any wasted words. It's appropriately sized for a simple diagnostic tool and front-loads the core functionality. Every word earns its place in this minimal but complete statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no annotations, no output schema), the description provides adequate coverage of what the tool does. However, as a diagnostic tool with potential complexity in what 'status' means and how it's presented, the description could benefit from clarifying the return format or what specific status information is provided. It meets minimum viability but leaves questions about output format.
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 description coverage is 100% (though trivial since there are no parameters). The description appropriately doesn't discuss parameters since none exist. A baseline of 4 is appropriate for parameterless tools where the schema fully documents the empty parameter set.
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 ('Check') and resource ('status of Magento 2 cache types'), making the purpose immediately understandable. It distinguishes itself from siblings like cache-clean, cache-disable, cache-enable, cache-flush, and cache-view by focusing on status checking rather than modification operations. However, it doesn't explicitly contrast with cache-view which might also provide status information, 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 context through the verb 'Check' - suggesting this is for diagnostic or monitoring purposes rather than modification. However, it provides no explicit guidance on when to use this tool versus alternatives like cache-view or sys-info, nor does it mention prerequisites or exclusions. The context is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect specific cache entries in Magento 2
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Cache key to inspect | |
| type | No | Cache type (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'inspect' which implies a read-only operation, but does not disclose behavioral traits such as whether it requires specific permissions, what format the inspection output is in, if it handles missing keys gracefully, or any rate limits. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of cache operations in Magento 2, no annotations, and no output schema, the description is incomplete. It lacks details on what 'inspect' entails (e.g., returns entry details, metadata, or just existence), how it interacts with sibling tools, or any error handling, making it inadequate for informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (key and type). The description adds no additional meaning beyond what the schema provides, such as examples of cache keys or cache types, but since the schema is comprehensive, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'inspect' and the resource 'specific cache entries in Magento 2', making the purpose understandable. However, it does not explicitly differentiate from sibling tools like cache-status (which might show overall cache status) or cache-flush (which modifies cache), leaving room for ambiguity in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like cache-status (which might list cache entries) and cache-clean (which might remove entries), there is no indication of context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set Magento 2 system configuration values
| Name | Required | Description | Default |
|---|---|---|---|
| encrypt | No | Encrypt the value | |
| path | Yes | Configuration path to set | |
| scope | No | Configuration scope (default, website, store) | |
| scopeId | No | Scope ID (website ID or store ID) | |
| value | Yes | Value to set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Set' implies a write/mutation operation, it doesn't specify whether this requires admin permissions, if changes are reversible, potential side effects (e.g., cache invalidation), or error handling. For a configuration mutation tool, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a straightforward configuration-setting tool and is perfectly front-loaded with the 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?
For a configuration mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address what happens after setting values (e.g., cache implications, need for reindexing), doesn't explain the relationship with sibling tools, and provides no information about return values or error conditions.
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, clearly documenting all 5 parameters. The description adds no additional parameter semantics beyond what's already in the schema (e.g., it doesn't explain path format conventions, scope hierarchy, or value encoding). This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set') and resource ('Magento 2 system configuration values'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from its sibling 'config-store-set', which appears to serve a similar configuration-setting function, leaving some ambiguity about when to use one versus the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'config-store-set' or other configuration-related tools in the sibling list. It lacks context about prerequisites, typical use cases, or any 'when-not-to-use' scenarios, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View Magento 2 system configuration values
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Configuration path to show (optional, shows all if not specified) | |
| scope | No | Configuration scope (default, website, store) | |
| scopeId | No | Scope ID (website ID or store ID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'view' implies a read-only operation, but does not cover aspects like permissions required, rate limits, error handling, or what happens if parameters are omitted (e.g., showing all values). This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a configuration tool with 3 parameters and no annotations or output schema, the description is insufficient. It does not explain return values, error cases, or behavioral nuances like how 'scope' and 'scopeId' interact, leaving the agent with incomplete context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all parameters (e.g., 'path' as optional configuration path, 'scope' as configuration scope). The description adds no additional parameter semantics beyond the schema, so it meets the baseline for adequate but not enhanced coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('view') and resource ('Magento 2 system configuration values'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'config-set' or 'config-store-get', which would require a more specific scope or comparison.
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 such as 'config-set' for setting values or 'config-store-get' for store-specific configurations. It lacks context on prerequisites or scenarios where this tool is preferred, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get store-specific Magento 2 configuration values
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Configuration path to get | |
| storeId | No | Store ID (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), but doesn't mention potential side effects, error conditions, authentication needs, rate limits, or what the return format looks like. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and earns its place by clearly stating the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving configuration values), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the return values look like, error handling, or how it differs from similar tools, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('path' and 'storeId') adequately. The description adds no additional meaning beyond implying store-specific configuration retrieval, which aligns with the schema but doesn't provide extra context like format examples or edge cases.
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 'Get' and the resource 'store-specific Magento 2 configuration values', making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'config-show' or 'config-store-set', which would require 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?
The description provides no guidance on when to use this tool versus alternatives like 'config-show' or 'config-store-set'. It lacks any context about prerequisites, typical use cases, or exclusions, leaving the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set store-specific Magento 2 configuration values
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Configuration path to set | |
| storeId | No | Store ID (optional) | |
| value | Yes | Value to set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Set' which implies a write/mutation operation, but doesn't cover critical aspects like required permissions, whether changes are reversible, potential side effects, or error handling. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., permissions, side effects), output format, and differentiation from siblings, leaving significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (path, storeId, value) with clear descriptions. The description adds no additional meaning beyond what's in the schema, such as examples or format details, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('store-specific Magento 2 configuration values'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'config-set' (which likely sets global config) or 'config-store-get' (which retrieves store config), missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'config-set' (presumably for global config) and 'config-store-get' (for retrieval), there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute SQL queries directly on Magento 2 database
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format | table |
| query | Yes | SQL query to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool executes SQL queries but doesn't mention critical aspects like required permissions, whether it's read-only or can modify data, potential risks of direct database access, or any rate limits. This leaves significant gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing SQL queries on a production database, the description is insufficient. With no annotations, no output schema, and no guidance on usage or behavior, it fails to provide the completeness needed for safe operation. The agent lacks information about return values, error handling, and operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents both parameters (query and format). The description doesn't add any meaningful parameter semantics beyond what's already in the schema, such as SQL dialect specifics or format implications. The baseline score of 3 reflects adequate but not enhanced parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute SQL queries') and target resource ('Magento 2 database'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'setup-db-status' or other database-related operations, which would require explicit comparison to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'setup-db-status', 'config-store-get'), there's no indication of appropriate contexts, prerequisites, or exclusions for this direct SQL execution tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create and register a new Magento 2 module
| Name | Required | Description | Default |
|---|---|---|---|
| addAll | No | Add blocks, helpers and models | |
| addBlocks | No | Add blocks | |
| addComposer | No | Add a composer.json file to generated module | |
| addHelpers | No | Add helpers | |
| addModels | No | Add models | |
| addReadme | No | Add a readme.md file to generated module | |
| addSetup | No | Add SQL setup | |
| addStrictTypes | No | Add strict_types declaration to generated PHP files | |
| authorEmail | No | Author email for readme.md or composer.json | |
| authorName | No | Author for readme.md or composer.json | |
| description | No | Description for readme.md or composer.json | |
| enable | No | Enable module after creation | |
| minimal | No | Create only module file | |
| modman | No | Create all files in folder with a modman file | |
| moduleName | Yes | Name of your module | |
| vendorNamespace | Yes | Namespace (your company prefix) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates and registers a module, implying a write operation, but lacks details on permissions, side effects, error handling, or what 'register' entails. This is inadequate for a mutation tool with complex parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (16 parameters, mutation tool) and lack of annotations or output schema, the description is insufficient. It doesn't explain behavioral aspects, return values, or usage context, leaving significant gaps for the agent to understand how to invoke it correctly.
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 fully documents all 16 parameters. The description adds no additional parameter semantics beyond what's in the schema, resulting in a baseline score of 3 as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create and register') and the resource ('new Magento 2 module'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'dev-module-list' or other development tools, which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when it's appropriate compared to other module-related tools, or any exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Magento 2 modules and their status
| Name | Required | Description | Default |
|---|---|---|---|
| disabled | No | Show only disabled modules | |
| enabled | No | Show only enabled modules | |
| format | No | Output format | table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't mention permissions, rate limits, pagination, or output structure. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence earns its place by specifying the action, resource, and scope.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what the output includes (e.g., module names, versions, paths) or behavioral aspects like permissions or errors. For a list tool with rich sibling context, it should provide more guidance on usage and results.
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 description adds no parameter-specific information beyond what's in the schema, which has 100% coverage. It implies filtering by status but doesn't detail how parameters interact (e.g., 'disabled' and 'enabled' as mutual exclusives). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all Magento 2 modules and their status'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'dev-module-observer-list' or 'dev-module-create', which would require 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?
The description provides no guidance on when to use this tool versus alternatives. There are no mentions of prerequisites, exclusions, or comparisons to sibling tools like 'dev-module-observer-list' or 'sys-info', leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Magento 2 module observers
| Name | Required | Description | Default |
|---|---|---|---|
| event | No | Filter by specific event name | |
| format | No | Output format | table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the action without details on permissions, rate limits, output behavior, or side effects. It lacks information on what 'list' entails (e.g., pagination, default sorting), making it insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's listing function, no output schema, and lack of annotations, the description is incomplete. It does not address return values, error handling, or behavioral traits, leaving gaps that could hinder an AI agent's ability to use it effectively in context with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters ('event' and 'format'). The description adds no additional parameter semantics beyond what the schema provides, such as examples or usage context, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all Magento 2 module observers'), making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like 'dev-module-list' or 'sys-cron-list', which also list resources but different types, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as how it differs from 'dev-module-list' or other listing tools in the sibling set. There is no mention of context, prerequisites, or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Magento 2 themes
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format | table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a list operation, implying it's read-only, but doesn't cover other aspects like permissions needed, rate limits, pagination, or what the output looks like (beyond the format parameter). For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single optional parameter) and high schema coverage, the description is minimally adequate. However, with no output schema and no annotations, it lacks details on return values (e.g., structure of theme data) and behavioral context, which could be important for a listing tool in a development 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?
The input schema has 100% description coverage, with the single parameter 'format' fully documented (including default, enum values, and description). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all available Magento 2 themes'), making the purpose unambiguous. However, it doesn't distinguish this tool from other listing tools like 'dev-module-list' or 'sys-store-list' in the sibling list, which would require explicit differentiation for a score of 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., development vs. production), or compare it to similar tools like 'dev-module-list', leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Magento 2 dependency injection preferences list using magerun2
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | The scope to get DI preferences for | global |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't clarify if it requires specific permissions, has side effects (e.g., caching), rate limits, or what the output format looks like (list structure, pagination). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('Get', 'Magento 2 dependency injection preferences list', 'using magerun2') earns its place by specifying the action, resource, and method concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving DI preferences with scope filtering), no annotations, and no output schema, the description is minimally adequate. It identifies the tool's purpose and method but lacks details on behavior, output format, and usage context. The high schema coverage for the single parameter helps, but overall completeness is limited for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'scope' fully documented including enum values and default. The description adds no additional parameter semantics beyond what the schema provides, such as explaining what 'scope' means in the context of DI preferences or how different scopes affect results. This meets the baseline of 3 given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('Magento 2 dependency injection preferences list') with the specific method ('using magerun2'). It distinguishes from siblings by focusing on DI preferences rather than cache, config, or system operations. However, it doesn't explicitly differentiate from potential similar tools like 'config-show' or 'dev-module-list' that might also retrieve configuration data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requiring magerun2 installation), typical use cases (e.g., debugging DI issues), or when other tools like 'config-show' might be more appropriate for related configuration queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Magento 2 database status to see if setup:upgrade is needed
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's purpose as a status check, implying it's a read-only operation, but doesn't disclose details like output format, error conditions, or any side effects. This is adequate but lacks rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('Check Magento 2 database status') and avoids any wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema), the description is complete enough for its purpose. It clearly states what the tool does and when to use it, though it could benefit from more behavioral details like output expectations, but this is minor for a simple status check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the baseline is 4. The description adds no parameter details, which is appropriate since there are none, and it doesn't need to compensate for any gaps.
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 specific action ('Check Magento 2 database status') and the purpose ('to see if setup:upgrade is needed'), using precise verbs and distinguishing it from sibling tools like 'setup-upgrade' (which performs the upgrade) and 'db-query' (which runs queries).
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 explicitly states when to use this tool ('to see if setup:upgrade is needed'), providing clear context for its application in checking database status before potentially running the upgrade, and distinguishes it from alternatives like 'setup-upgrade' itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compile Magento 2 dependency injection configuration
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('compile') but doesn't explain what this entails—whether it's a read-only operation, modifies files, requires specific permissions, or has side effects like caching changes. This lack of detail is a significant gap for a tool with potential system impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundant information. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides a basic purpose but lacks completeness. It doesn't cover behavioral aspects like what 'compile' does operationally, potential outputs, or integration with sibling tools, which is important for a setup-related command in a development 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?
The tool has zero parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description correctly omits parameter information, earning a high score for not adding unnecessary content, though it doesn't explicitly state 'no parameters required' which could slightly improve 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 ('compile') and resource ('Magento 2 dependency injection configuration'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-di-preferences' or 'setup-upgrade', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as during development, deployment, or troubleshooting scenarios. There's no mention of prerequisites, related tools, or typical use cases, leaving the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy Magento 2 static content and assets
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Force deployment even if files exist | |
| jobs | No | Number of parallel jobs | |
| languages | No | Languages to deploy (e.g., ['en_US', 'de_DE']) | |
| themes | No | Themes to deploy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deploys content and assets, implying a write operation, but fails to detail critical aspects like required permissions, whether it's idempotent, potential side effects (e.g., downtime), or error handling. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core action without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a deployment tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, error conditions, or what constitutes successful deployment, leaving the agent with incomplete context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all four parameters (force, jobs, languages, themes). The description adds no additional meaning beyond the schema, such as default values or usage examples, so it meets the baseline of 3 for adequate but not enhanced parameter semantics.
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 ('deploy') and target ('Magento 2 static content and assets'), making the purpose understandable. However, it does not distinguish this tool from potential siblings like 'setup-di-compile' or 'setup-upgrade', which are also setup-related operations, leaving some ambiguity about its specific role within the sibling set.
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, such as other setup tools like 'setup-di-compile' or 'setup-upgrade', nor does it mention prerequisites or exclusions. This lack of context makes it unclear in what scenarios this deployment is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Magento 2 setup upgrade to update database schema and data
| Name | Required | Description | Default |
|---|---|---|---|
| keepGenerated | No | Keep generated files during upgrade |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the action ('run') and outcome ('update database schema and data'), but lacks critical behavioral details: it doesn't specify if this is a destructive operation (likely yes for schema changes), permission requirements, execution time, error handling, or impact on site availability. For a database upgrade tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and purpose without unnecessary words. Every part ('Run Magento 2 setup upgrade to update database schema and data') directly contributes to understanding the tool's function, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a database upgrade tool (potentially high-risk), no annotations, no output schema, and minimal behavioral disclosure, the description is incomplete. It should cover more about execution context, safety, and outcomes to compensate for the lack of structured data. The current description is adequate only for basic purpose understanding but insufficient for safe or informed usage.
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 one parameter ('keepGenerated') fully documented in the schema. The description adds no parameter-specific information beyond what the schema provides. According to rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 ('Magento 2 setup upgrade') with specific purpose ('to update database schema and data'). It distinguishes from siblings like 'setup-db-status' or 'db-query' by focusing on upgrade execution rather than status checks or queries. However, it doesn't explicitly differentiate from all setup-related tools like 'setup-di-compile' or 'setup-static-content-deploy' beyond the database focus.
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. It doesn't mention prerequisites (e.g., after code changes), timing considerations (e.g., during deployments), or exclusions (e.g., not for minor config updates). The description implies usage for database updates but lacks explicit context for selection among siblings like 'setup-db-status' for checking status first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Magento 2 system requirements and configuration
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool performs a 'check' (implying read-only, non-destructive behavior) but doesn't specify what the check entails (e.g., returns a report, validates against benchmarks, requires admin permissions) or any side effects. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Check Magento 2 system requirements and configuration.' It is front-loaded with the core action and resource, with zero wasted words. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple check with no parameters) and lack of annotations/output schema, the description is minimally complete. It states what the tool does but lacks details on behavior, output format, or integration context. It's adequate for a basic tool but would benefit from more context about what the check returns or when to use it.
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 0 parameters, and schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to add parameter details, so it meets the baseline of 4 for zero-parameter tools. It appropriately focuses on the tool's purpose without unnecessary parameter explanations.
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 tool's purpose: 'Check Magento 2 system requirements and configuration' with a specific verb ('Check') and resource ('Magento 2 system requirements and configuration'). It distinguishes from most siblings (e.g., cache-*, config-*, dev-* tools) but doesn't explicitly differentiate from 'sys-info' or 'setup-db-status' which might overlap in system assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing (e.g., after installation or before upgrades), or compare to siblings like 'sys-info' (which might provide general system info) or 'setup-db-status' (which checks database status). Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Magento 2 cron jobs and their configuration
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format | table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it implies a read-only operation ('List'), it doesn't specify whether this requires specific permissions, how data is retrieved (e.g., from database or configuration files), potential performance impacts, or error handling. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. Every word earns its place, making it easy to parse quickly. No redundancy or verbose explanations detract 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?
Given the tool's low complexity (one optional parameter, no output schema), the description is minimally adequate but lacks depth. It doesn't explain what 'configuration' includes (e.g., schedule, status, last run), how results are structured, or potential limitations (e.g., pagination). With no annotations and simple schema, more context would improve completeness for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'format' well-documented (including enum values and default). The description adds no additional parameter semantics beyond what the schema provides, such as explaining the implications of each format choice (e.g., 'table' for human-readable output vs. 'json' for programmatic use). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all Magento 2 cron jobs and their configuration'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'sys-cron-run' (which executes cron jobs) or 'sys-check' (which might check cron status), leaving some ambiguity about when to choose this specific list tool over alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'sys-cron-run' (for executing cron jobs) and 'sys-check' (potentially for cron-related diagnostics), there's no indication of context, prerequisites, or exclusions. This lack of comparative guidance could lead to misuse or confusion in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Magento 2 cron jobs
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Cron group to run | |
| job | No | Specific cron job to run (optional, runs all if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Run') but lacks critical details such as whether this requires admin permissions, if it's safe for production environments, potential performance impacts, or what happens upon execution (e.g., output format, errors). This is inadequate for a tool that performs system operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, direct sentence that front-loads the core purpose without any fluff or redundancy. Every word earns its place, making it efficient for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of running system cron jobs (a potentially impactful operation), the description is insufficient. With no annotations, no output schema, and minimal behavioral details, it fails to provide enough context for safe and effective use. The agent lacks information on prerequisites, outcomes, or error handling.
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, clearly documenting both parameters ('group' and 'job') with their types and optionality. The description adds no additional semantic context beyond implying cron job execution, so it meets the baseline for adequate but not enhanced parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run') and resource ('Magento 2 cron jobs'), making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like 'sys-cron-list' (which likely lists cron jobs) or other execution tools, missing an opportunity for precise distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not mention when to run cron jobs manually versus relying on automated scheduling, or how it relates to siblings like 'sys-cron-list' or other system tools. This leaves the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Magento 2 system information
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format | table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a read operation ('Get'), but doesn't disclose behavioral traits like permissions needed, rate limits, or what 'system information' entails (e.g., performance metrics, configuration). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it appropriately sized and structured for its simplicity.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'system information' includes or the return format, leaving gaps for an agent to understand the tool's behavior and output fully.
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 the single parameter 'format' fully documented in the schema (including enum values and default). The description doesn't add any parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('Magento 2 system information'), making the purpose understandable. However, it doesn't differentiate from siblings like 'sys-check' or 'sys-cron-list', which might also retrieve system-related data, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'sys-check' and 'sys-cron-list', the description doesn't specify if this is for general system info or something more specific, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all base URLs for Magento 2 stores
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format | table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it lists base URLs but does not cover aspects like read-only vs. destructive behavior, authentication needs, rate limits, or output format details beyond the schema. This leaves significant gaps for a tool with potential system interactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain behavioral traits, return values, or how it differs from siblings, which is insufficient for a tool that might involve system configuration or data retrieval in a complex environment like Magento 2.
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, documenting the 'format' parameter with its enum values and default. The description does not add any parameter semantics beyond this, so it meets the baseline for high schema coverage without compensating or enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all base URLs for Magento 2 stores'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'sys-store-list' or 'sys-url-list', which might have overlapping functionality, 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?
No guidance is provided on when to use this tool versus alternatives such as 'sys-store-list' or 'sys-url-list' from the sibling list. The description lacks context on prerequisites, exclusions, or specific scenarios, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Magento 2 stores, websites, and store views
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format | table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't mention any constraints like permissions, rate limits, or what the output includes beyond the resource types. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on output format or behavioral traits, which would be helpful for an agent to use it effectively in context with siblings.
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, documenting the 'format' parameter with its enum values and default. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('Magento 2 stores, websites, and store views'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'sys-website-list' or 'sys-store-config-base-url-list', which appear to list similar resources, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given sibling tools like 'sys-website-list' and 'sys-store-config-base-url-list' that might overlap in functionality, the lack of explicit usage context or exclusions leaves the agent without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all Magento 2 URLs
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format | table |
| storeId | No | Store ID to filter URLs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get all Magento 2 URLs' but does not explain what 'all' entails (e.g., pagination, rate limits, permissions required, or whether it's a read-only operation). This leaves significant gaps in understanding the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the core action. It is appropriately sized for the tool's complexity, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimal but adequate for the basic purpose. It lacks details on behavioral traits and usage context, which would be needed for full completeness, but it suffices as a starting point without being misleading.
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, documenting both parameters ('format' and 'storeId') with details like default values and enums. The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline of 3 without compensating for any gaps.
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 'Get' and the resource 'all Magento 2 URLs', making the purpose specific and understandable. However, it does not differentiate from sibling tools like 'sys-store-config-base-url-list' or 'sys-store-list', which might also retrieve URL-related information, leaving some ambiguity about uniqueness.
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, such as 'sys-store-config-base-url-list' for base URLs or 'sys-store-list' for store details. It lacks explicit when/when-not instructions or prerequisites, offering only a basic action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Magento 2 websites
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format | table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('List') but doesn't mention whether this is a read-only operation, if it requires specific permissions, potential rate limits, or what the output looks like (e.g., structure, pagination). This leaves significant gaps for a tool that interacts with a system like Magento 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for a simple listing tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of Magento 2 systems and the lack of annotations and output schema, the description is insufficient. It doesn't explain what 'websites' entail in this context, the return format, or any behavioral traits, leaving the agent with incomplete information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting the 'format' parameter with its enum values and default. The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline for high schema coverage without compensating with extra details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all Magento 2 websites'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential siblings like 'sys-store-list' or 'sys-url-list', which might also list related entities, so it misses full differentiation.
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, such as 'sys-store-list' or 'sys-url-list' from the sibling list. It lacks context about prerequisites, exclusions, or specific use cases, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes with clear boundaries, such as cache-clean vs. cache-flush or config-set vs. config-show. However, some tools like sys-store-list and sys-website-list could potentially overlap in listing store-related information, though their descriptions specify different scopes (stores/websites vs. websites only). Overall, the naming and descriptions help minimize confusion.
Tool names follow a highly consistent verb-noun pattern with hyphens, such as cache-clean, config-set, and sys-info. All tools adhere to this convention, making them predictable and easy to parse. There are no deviations in style or mixed conventions.
With 28 tools, the count is on the higher side for a development server, bordering on heavy. While it covers many aspects of Magento 2 development, it may feel overwhelming or redundant in some areas, such as multiple cache-related tools. A more streamlined set could improve usability without losing functionality.
The tool set provides comprehensive coverage for Magento 2 development, including cache management, configuration, database operations, module and theme development, system setup, and system information. It supports full lifecycle operations like creating modules, deploying content, and running upgrades, with no obvious gaps that would hinder agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Develop, manage, and debug Railway projects, services, and deployments from within agents.
A registry of AI agent tools — MCP servers, APIs, CLIs, SDKs — kept current by automated ingestion.
Shared control plane for AI coding agents — tasks, memory, decisions, file locks. 12 tools.
Package intelligence MCP for AI agents — 22 tools, 19 ecosystems, AGPL SDK, free.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/elgentos/magento2-dev-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
