Repository navigation
MCP and AI Roadmap
Make AI-assisted Magento development more dependable and useful. Build on the existing MCP capabilities by improving the workflows developers already use and extending them when research demonstrates an unmet need.
Success means developers complete real tasks with fewer errors, less manual investigation, and less rework. The number of MCP tools is not a success measure.
- Maintain existing MCP capabilities, assistant guidance, and documentation as the plugin, supported IDEs, and Magento environments evolve.
- Prioritize reproducible failures and recurring friction in current workflows before expanding the tool set.
- Make results clear and actionable: developers and assistants should understand what was checked or changed, what remains incomplete, and how to recover from a failure.
- Verify complete developer workflows in representative projects, including failure and recovery paths. Successful tool invocation alone is not sufficient validation.
- Turn confirmed defects into regression coverage, and keep setup instructions and examples aligned with actual behavior.
Desired outcome: developers can depend on the existing features to complete their intended tasks consistently, with understandable limitations and fewer repeated attempts.
- Regularly review developer issues, support discussions, community feedback, and observed difficulties in real Magento development tasks.
- Record evidence for each candidate improvement: the affected workflow, a reproducible example or source, the current workaround, and the impact on the developer.
- Check whether existing IDE features, MCP tools, or better guidance already solve the problem before proposing a new capability.
- Prioritize by demonstrated impact, recurrence, and the value the plugin can add. Keep unvalidated ideas in research rather than treating them as delivery commitments.
- Prototype promising improvements and compare the resulting workflow with the current approach using representative tasks.
- Implement and document improvements when the evidence supports them; revise, defer, or drop proposals that do not provide meaningful benefit.
- Review shipped improvements against developer feedback and regression results, and use those findings to guide the next research cycle.
Desired outcome: each extension addresses a documented developer problem and has a concrete way to demonstrate that the workflow improved.
| Question | Expected evidence |
|---|---|
| What task is difficult today, and for whom? | A specific developer workflow and a linked report, reproducible case, or documented observation. |
| Why is the current approach insufficient? | The existing workaround and its limitations, including a check of available IDE and MCP features. |
| What would improve for the developer? | An observable outcome such as fewer manual steps, fewer incorrect changes, more complete findings, or clearer recovery. |
| How will we know it works? | Representative before/after scenarios, acceptance criteria, and regression checks. |
A single well-documented high-impact problem can justify work; popularity alone is not the deciding factor. Research findings should distinguish confirmed behavior from assumptions and keep source dates and resolution status in view.
- Improve an existing tool or workflow when that solves the problem more clearly than adding another tool.
- Keep feature descriptions focused on developer outcomes and explain which environments are supported.
- Include validation, documentation, and ongoing maintenance in the definition of done.
- Keep priorities open to evidence. This roadmap does not preselect speculative features or promise a release date.
