Most conversation about AI and AEM is about content: assistants that edit pages or search the DAM. There is a second, quieter category aimed at the people who build AEM projects: tooling that runs locally next to your AEM SDK and Dispatcher, so an AI coding assistant can see your project’s logs, OSGi state, and Dispatcher configuration instead of guessing. Adobe documents four pieces of it. This post summarizes what the documentation says each does, what each needs, where Adobe says to be careful, and what the page does not tell you.
Status: What the Page Does and Doesn’t Say
| Item | What the documentation says |
| All four tools below | NO STATUS LABELS STATED. Adobe’s “Local Development with AI Tools” page (last updated October 9, 2026) shows no GA, Beta, or Early Access label for any of them. We did not verify when each piece launched, so we don’t call any of them new or long-standing. Confirm maturity with Adobe before building a team process on them. |
| Scope | The page says the AGENTS.md file and skills cover the Java stack only not AEM 6.5 and not Edge Delivery Services. |
Not the same as the AEM MCP Server. Our previous post covered the cloud-hosted, unified AEM MCP Server, which lets assistants work with content and Cloud Manager. The tools here are different: they run on your own machine against a local AEM SDK and a local Dispatcher.
What Runs Where
Local tooling as described in Adobe’s documentation.
The Four Pieces, as Adobe Documents Them
| Piece | What it does (per the page) | Prerequisites and notes |
| AGENTS.md | A project context file at the project root that AI coding tools load at the start of each session. A skill generates it from the project’s pom.xml. Once the file exists, the skill no longer runs, so you edit it directly when your project structure changes. | A skill named ensure-agents-md creates both AGENTS.md and CLAUDE.md. |
| Agent skills (Adobe’s skills repository, AEM as a Cloud Service plugin) | create-component (scaffolds component definitions, dialogs, HTL, Sling Models, tests, and clientlibs); dispatcher (Dispatcher and Apache HTTPD configuration help, routed to six sub-skills); migration (migrates AEM 6.x, AMS, or on-premise code and configs, one pattern at a time); workflow (design, development, and production debugging); code-assessment (finds and fixes best-practice and correctness issues locally; the page says it never commits or pushes); and ensure-agents-md. | Installed through Claude Code marketplace commands, a skills command-line tool, or a GitHub CLI extension; installing once makes the skills available on that machine. The migration skill pairs with the Cloud Migration MCP or a Best Practices Analyzer CSV. The page does not state the AEM SDK version required for the skills. |
| AEM Quickstart MCP server | A content package that exposes runtime data from a local AEM SDK instance to connected AI tools. Three tools are listed: aem-logs, diagnose-osgi-bundle, and recent-requests. | Installed through Package Manager on the local instance. Validated with AEM SDK 2026.2.24678 (February 26, 2026 build) and newer. The endpoint is on the local instance and requires an authorization header. |
| Dispatcher MCP server | Bundled with the AEM Dispatcher SDK. Validates Dispatcher configuration and inspects behavior against a local Dispatcher running in Docker. Tools: validate, lint, sdk, trace_request, inspect_cache, monitor_metrics, tail_logs. Tools only, with no prompts or resources. | Requires Docker Desktop 4.x or later, running, plus the Dispatcher SDK from the Software Distribution Portal, with a configuration-root environment variable set. The page does not state the SDK version required. |
Which AI Tools Work With It
The page lists Claude Code, Cursor, GitHub Copilot CLI, and GitHub Copilot in IntelliJ IDEA. Any MCP client can connect to the AEM Quickstart server. The Dispatcher SDK documentation includes examples for Claude Desktop and VS Code, but this page gives no setup steps for them. It also does not list required versions of any of these tools.
Adobe’s Security and Safety Notes
- A local AEM Quickstart ships with default admin credentials. The page says not to use them in non-local environments.
- Use the Dispatcher MCP server only against a local Docker instance.
- The code-assessment skill never commits or pushes, but the page says to review its diffs before committing.
Documented Limitations
- The context file and skills cover the Java stack only not AEM 6.5 or Edge Delivery Services.
- The migration skill works one pattern per session.
- The page does not state the AEM SDK version required for the Dispatcher MCP server or for the skills, and does not list required versions of the AI tools.
- Adobe notes a workaround for a Docker client-version error some Docker users may see; check the page if you hit it.
How This Might Fit Your Workflow (Our Reading)
This is our interpretation, not Adobe guidance, and we have not used these tools on a customer project. The ideas below are not documented outcomes.
- Start with the project context file. It is the lowest-risk piece: it only gives an assistant background about your project. Review what gets generated, and keep it current.
- Use the Quickstart tools for diagnosis. Logs, recent requests, and OSGi bundle state are what a developer checks first when something fails locally; having an assistant read them directly may save copy-and-paste, though we haven’t measured it.
- Use the Dispatcher tools to check configuration before a pipeline run. Validating and linting locally is a natural fit for mistakes that otherwise surface later.
- Treat all generated code like any other contribution. Review it, run your tests, and keep your normal pull request process.
- Keep credentials local. Don’t point these tools at shared or production environments.
What We Haven’t Verified
- We read Adobe’s page on October 14, 2026 (last updated October 9, 2026). We have not installed or run any of these tools on a project.
- The page states no GA/Beta/Early Access label, and we did not independently confirm maturity or when each piece launched.
- We did not review the individual skill definitions, the tool schemas, or the setup guides for each AI tool in detail.
- We have not measured any productivity or quality benefit. Evaluate on your own codebase.
- Skill and tool names, supported versions, and prerequisites may change; re-check the page before relying on specifics.
Try-It-Safely Checklist
- Confirm with Adobe the current maturity of these tools, since the page gives no label
- Check that your project is on the Java stack (not AEM 6.5, not Edge Delivery Services)
- Pick a supported AI tool and follow Adobe’s current setup guidance for it
- Generate the project context file, then read and correct it before relying on it
- Confirm your local AEM SDK meets the version the Quickstart MCP server was validated with
- Confirm Docker Desktop and the Dispatcher SDK are in place before trying the Dispatcher tools
- Never reuse the default local admin credentials outside your local machine
- Point the Dispatcher MCP server only at local Docker
- Review every diff from the code-assessment and migration skills before committing
- Run your normal tests and pull request review on anything an assistant produced
Final Thoughts
Giving an AI assistant real visibility into a local AEM instance and a local Dispatcher is a sensible direction: the assistant works from your project’s actual state instead of general knowledge. The sensible way to try it is the same as any new developer tool: on a local machine, with nothing shared, and with your usual review process unchanged. Since Adobe’s page doesn’t state a maturity label, treat it as something to evaluate, not something to standardize on yet.
