Fetches release notes for magento/magento2 from GitHub Releases to support upgrade planning without relying on model memory.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-magento-audit assess this Magento project for PHP 8.3 / Magento 2.4.8 upgrade blockers"
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.
An MCP server giving an AI agent tools to assess a Magento 2 / Adobe Commerce project along three axes: compatibility with a target PHP and Magento version, quality of custom modules, and dependency security.
It answers the question that never stops coming up in Magento agencies: "can we bump this client to a newer version, what's blocking it, and where do we start?"
Status: early stage. Built on evenings/weekends. All five planned tools (
project_status,check_updates,module_risk,fetch_release_notes,upgrade_plan) are working. SeeROADMAP.mdfor what's next.
composer auditcomposer audit and composer outdated are built into Composer and do their job well.
This server targets three things they don't give you:
They don't see app/code. Custom modules don't exist on Packagist, so they get
zero coverage from vulnerability databases — and that's exactly the code agencies write.
They don't combine axes. Nobody gets one answer: this module blocks the upgrade, has an open CVE, is abandoned by its author, and has the worst complexity in the project — fix this one first.
They don't aggregate across projects. "Which of our twenty stores can be upgraded today" requires stitching results together from many directories by hand.
What this server doesn't pretend to be: there's no clean dataset of "module X works
with Magento 2.4.8". Results are derived from declarations in composer.json, a code
scan, and the vendor's own release notes — this is a decision-support tool, not an
oracle. Upgrading a production store still requires testing, not just a report.
Related MCP server: Magento MCP Server
git clone https://github.com/michalper/mcp-magento-audit.git
cd mcp-magento-audit
python3.12 -m venv .venv
.venv/bin/pip install -e ".[dev]"{
"mcpServers": {
"magento-audit": {
"command": "/path/to/mcp-magento-audit/.venv/bin/mcp-magento-audit"
}
}
}Tool | Status | Description |
| working | Magento version, PHP requirement, package count, abandoned packages |
| working | per-package verdict against a target PHP/Magento version, plus a Rector-based check of whether the code itself would need changes |
| working | scans code via |
| working | release notes from |
| working | combines the other tools into a list of concrete blockers, with |
.venv/bin/python -m pytest # tests
.venv/bin/ruff check . # lint
.venv/bin/mypy src # typesArchitectural decisions are recorded in docs/adr/.
MIT
Checks the given Magento project against a target PHP and Magento version, with two independent signals: a per-package verdict ('ok', 'blocks' or 'unknown') from declared composer.lock PHP requirements, and code_compatibility — whether the project's own code would actually need changes under the target PHP, via a Rector dry-run (declared requirements are often just '*', which alone gives a false sense of readiness). The PHP requirement for the target Magento version comes from a local cache, a live fetch, or an offline fallback table, in that order — the result says which one was used.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| target_php | Yes | ||
| target_magento | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden and largely meets it: it discloses the two independent signals, the per-package verdict vocabulary ('ok', 'blocks', 'unknown'), a Rector dry-run, and the three-tier requirement resolution order (cache, live fetch, offline fallback) with the result reporting which was used. What it omits is the safety/cost profile — a Rector dry-run can be slow, and it never states the tool is a read-only analysis.
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?
Purpose is front-loaded in the first clause, and both sentences carry real information rather than padding. The first sentence is long and dash-heavy, but it is dense with substance rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return formatting is not the description's job, and the description nonetheless explains the semantic meaning of the key fields. For a 3-required-param tool with zero annotation and zero schema-description coverage, the remaining gap is parameter formats and runtime cost, which keeps it short of full marks.
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 0%, so the description must compensate and it largely does not: path, target_php, and target_magento are never given formats, examples ('8.2', '2.4.7'), or path requirements. The narrative implies target_php/target_magento are versions, but that is inference, not 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?
It states a specific verb and resource ('Checks the given Magento project against a target PHP and Magento version') and even enumerates the two computed signals. The scope is unmistakable, but it never names or differentiates itself from siblings such as upgrade_plan or module_risk, which an agent choosing between five upgrade-related tools would want.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: a compatibility pre-check is plausibly what you run before upgrade_plan, but the description never says 'use this when...' or excludes an alternative. It spends its words explaining what the result contains rather than when to reach for the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches Magento's own release notes for a given version from the magento/magento2 GitHub repo's Releases API — never reconstructs them from training data. Returns found=false with a reason when nothing could be fetched, rather than guessing what a release might have contained.
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does meaningfully disclose behavior: the upstream dependency (GitHub Releases API), the deliberate avoidance of training-data reconstruction, and the failure contract (returns found=false with a reason rather than guessing). It stops short of covering auth requirements, rate limits, or caching, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no filler. The core action and source are front-loaded, and the failure-mode clause earns its place by setting expectations.
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?
An output schema exists, so return values needn't be enumerated, and the description still adds the found=false signal for the empty case. For a one-parameter read tool with no annotations, the remaining gap is the version-format contract, which is minor but real.
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 0%, so the description must compensate for the single 'version' parameter and it largely does not. Saying 'for a given version' adds nothing beyond the parameter name; the expected format (e.g. '2.4.6', '2.4.6-p1', composer-style constraint) and behavior for unknown versions are never specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (fetches), a specific resource (Magento's own release notes), and the exact source of truth (magento/magento2 GitHub Releases API). The scope is narrow and unambiguous, so an agent can tell it apart from siblings like check_updates or project_status without opening the schema.
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 the correct usage context by insisting it fetches real release notes and 'never reconstructs them from training data', which hints the agent should prefer this over answering from memory. However, it names no alternative sibling tool and gives no explicit when-to-use/when-not-to-use conditions (e.g. offline, cached, or unavailable-version cases).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scans the given Magento project's custom code for coding-standard violations and static-analysis issues by shelling out to the project's own vendor/bin/phpcs and vendor/bin/phpstan. phpcs: if the project has its own phpcs.xml(.dist), that configuration is used as-is; otherwise falls back to the Magento2 standard on app/code. phpstan: only run if the project has its own phpstan.neon(.dist) — unlike phpcs there is no safe generic fallback (no paths/level/extensions to guess), so it is skipped rather than guessing. Each tool reports scanned=false with a reason when it can't run, instead of staying silent.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: it shells out to the project's own vendor/bin tools, phpcs uses phpcs.xml(.dist) as-is or falls back to the Magento2 standard on app/code, phpstan runs only with a project phpstan.neon(.dist) and is skipped rather than guessed, and failures surface as scanned=false with a reason instead of silence. This is exactly the behavioral disclosure an agent needs.
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 purpose is front-loaded in the first clause, and the subsequent sentences each add distinct behavioral detail (phpcs config, phpstan skip logic, scanned=false reporting). It is on the long side, but nearly every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required, and the description still notes the scanned=false signaling. For a single-parameter tool with rich behavioral disclosure, coverage is strong; the only real gap is guidance on when to prefer it over 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 coverage is 0% and the single 'path' parameter has no description in the schema. The phrase 'the given Magento project's custom code' implies path points at a project root, giving partial meaning, but it never states the expected format (absolute vs relative, project root vs module dir). Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Scans the given Magento project's custom code for coding-standard violations and static-analysis issues.' This is clearly distinguishable from the update/status/notes-oriented siblings, and it names the underlying engines (phpcs/phpstan) so the agent knows the kind of output to expect.
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 is entirely about internal mechanics (config resolution, fallbacks, skip behavior) and never says when to reach for this tool versus project_status, check_updates, or upgrade_plan. Usage is only implicit from the tool's subject matter, with no conditions or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads composer.json and composer.lock of the given Magento project and returns its state: Magento version, PHP requirement, package count and the list of packages abandoned by their authors.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Reads' correctly signals a non-mutating inspection of local manifest files, and the enumerated outputs tell the agent what it gets back, but there is no disclosure of failure modes (missing/invalid composer.json, unreadable lock file) or environment requirements.
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?
One tightly constructed sentence, front-loaded with the action and inputs, then the outputs as a list. No filler 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 one-parameter read-only tool with an output schema, the definition is sufficient: the inputs and result shape are stated. The remaining gap is edge-case behavior on unreadable or missing files, which the output schema does not cover.
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 single 'path' parameter has 0% schema description coverage, so the description must compensate. It adds meaningful context by saying the path refers to 'the given Magento project', implying a project root directory rather than an arbitrary file, but it stops short of clarifying whether it is a directory, a composer.json path, or absolute vs relative.
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 gives a specific verb ('Reads') and names both the resources (composer.json, composer.lock) and the exact outputs (Magento version, PHP requirement, package count, abandoned packages). An agent immediately knows this is a project-state inspection tool, which implicitly separates it from fetch_release_notes or upgrade_plan, but it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of the alternatives (check_updates, module_risk, upgrade_plan) or when one should be preferred over this one. The only hint is the implied use of reading project state, which the agent must infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Builds an upgrade plan for the given Magento project against a target PHP and Magento version by combining check_updates, module_risk and fetch_release_notes. The verdict is a list of concrete blockers (composer constraints, code that Rector flags as needing changes, phpcs/phpstan errors), each with its own reason — not a single abstract score. ready=true only when that list is empty.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| target_php | Yes | ||
| target_magento | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose result semantics (a concrete blocker list rather than a score, ready=true only when empty) and reveals that it orchestrates three other tools, but it never states that the operation is read-only/non-mutating, nor that it may be slow or expensive because it fans out to three sub-checks.
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?
Three tightly packed sentences: purpose and composition first, then the shape and success condition of the result. No filler, and the most decision-relevant information is front-loaded.
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?
Output schema exists, so return values need no narrative, and the safety profile is low-risk. The remaining gaps are the undocumented parameter formats and the absence of any statement about cost/latency or preconditions (e.g. a valid Magento project at path), which matter for a tool that fans out to three sub-checks.
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 0%, so the description must document the three parameters. It gives rough meaning for two of them ('target PHP and Magento version') but no format or example values (e.g. '8.3', '2.4.7'), and 'path' is entirely unexplained — is it a project root, a composer.json, a store id?
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?
Specific verb+resource ('Builds an upgrade plan') with scope made explicit (against a target PHP and Magento version) and clear differentiation from siblings by naming check_updates, module_risk and fetch_release_notes as its inputs — this is a composite orchestrator, not a duplicate of any sibling.
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?
By stating it combines three sibling tools, the description implies the agent should reach for this when a consolidated verdict is wanted rather than the individual checks. It stops short of an explicit 'use X instead when you only need Y' exclusion, so an agent must infer the selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_updatesfetch_release_notesmodule_riskproject_statusupgrade_planScored across 5 tools
Each tool has a distinct role: project_status inspects current state, fetch_release_notes pulls external notes, check_updates runs compatibility signals, module_risk runs static analysis, and upgrade_plan aggregates them. There is mild overlap since upgrade_plan internally reuses check_updates/module_risk/fetch_release_notes, but the descriptions clearly frame these as components vs. the final aggregate plan.
All names are consistent snake_case, which is the dominant convention. However the pattern is mixed: fetch_release_notes and check_updates use verb_noun while project_status, module_risk and upgrade_plan are noun phrases, so it is not a strictly predictable verb_noun scheme.
Five tools is well-scoped for a focused Magento upgrade-audit server. Each tool earns its place, covering state inspection, external data, two independent analysis signals, and an aggregator, with no redundant or filler tools.
The surface covers the full audit lifecycle: current state, upstream release context, compatibility checks, code risk, and a synthesized upgrade plan with concrete blockers. Minor gaps exist (no config/cache inspection or structured report export), but core audit workflows have no dead ends.
Score a Magento or Adobe Commerce store on eight AI agent-readiness checks.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Agent-readiness scanner (0-5 score), robots.txt + llms.txt generators, managed agent enablement.
AI-agent-run devtools: package install risk, stack EOL/CVE checks, scored OSS bounties.
