mcp-magento-audit
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| project_statusB | 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. |
| check_updatesA | 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. |
| module_riskA | 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. |
| fetch_release_notesA | 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. |
| upgrade_planA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.