How to integrate your AI agent with Magnolia DXP via MCP

Grounded, context-aware assistance built for enterprise digital experience teams.

AI is becoming part of how digital teams build, manage, and improve customer experiences. The opportunity is clear — faster delivery, less repetitive work, and a way to move from idea to implementation without relying on a senior engineer being free at the right moment. For customers under pressure to ship and for partners trying to scale expertise across engagements, the pull is hard to ignore.

But in enterprise CMS work, generic AI hits a ceiling. A general-purpose assistant can write code or summarize documentation. What it usually cannot do is understand the reality of a specific Magnolia DXP project: How it is structured, where configuration lives, what the running instance knows, which templates and dialogs are available, or which conventions a customer or partner team depends on every day.

In a CMS project, output that looks plausible is not enough. A template that renders but gives editors nothing useful, a dialog that uses the wrong field type, or a configuration value that ignores the deployed environment still creates review work, rework, and risk.

The Magnolia MCP Developer's Server is the layer that closes that gap. Rather than treat AI as a generic capability bolted onto a CMS, it connects assistance to the customer's actual Magnolia DXP environment — the project structure, the running instance, and Magnolia-specific expertise.

A Magnolia DXP project isn't just a folder of source files. It's a graph of templates, dialogs, light-development modules, configuration in YAML and JCR, registered components, and conventions a team has built up over many engagements. Generic AI sees none of that. It looks at a file in isolation, makes a plausible guess, and writes something that resembles what should fit.

The MCP Developer's Server is given a structured view of the project instead. It is built to walk the templates and dialogs that are registered, see how a component is wired up, read the configuration that ships with the project, and follow references between them. When the question is “add a field to the existing hero dialog,” the assistant can answer it using the real definition of the hero dialog rather than inferring one from naming patterns.

This matters most in the places where Magnolia DXP projects become hard to reason about: light modules that override each other, mixed YAML/JCR configuration, multi-site setups where conventions diverge across sites, and partner toolkits layered on top of the stock Magnolia DXP. A context-aware assistant can keep track of the layers and answer questions about the layer that will actually win at runtime, which is usually where bugs live.

None of this runs as one monolithic tool. The MCP Developer's Server is plugin-based: the API plugin talks to Magnolia’s APIs to create JCR content in test scenarios and surface definition problems; the Log plugin watches the running Magnolia DXP log for issues as the assistant works; the CLI plugin gives the assistant everything the Magnolia CLI can do, from creating pages to components; and the Figma plugin generates Magnolia DXP output directly from a Figma design.

Figma generation is where the server is most capable today — it's the primary focus in current testing — with an HTML plugin, generating from existing HTML pages, still a work in progress. That's a deliberate starting point, not a ceiling: the same plugin architecture behind Figma-to-Magnolia today is what lets the next capability get added as its own plugin rather than a rewrite.

Project context tells the assistant what it is. The other half is telling it what should be. That's where curated expertise comes in.

Magnolia DXP expertise doesn't belong in a single prompt, a single model's training cut-off, or a single engineer's head. It belongs in editable, versioned guidance that travels with the project. The MCP Developer's Server is structured around that: best-practice notes, project-type conventions, integration patterns, and “here's how we do this” rules can be written as guidance documents, tagged by task and project type, and selected automatically when relevant.

Two things follow. First, the same guidance a partner shares across implementations is now the same guidance the assistant uses — which means new engineers, internal reviewers, and AI agents all operate from one source of truth instead of three. Second, when the practice changes — a new validation rule, a new design system, a new way of structuring components — the guidance is edited once, and every subsequent AI-assisted task picks it up.

For an enterprise organization, that's the difference between “we adopted AI” and “we governed how AI behaves on our projects.” The model is no longer the only source of authority.

Curated expertise only works if the curation is yours. Magnolia DXP ships a default set of skills — Markdown files with structured frontmatter that tell the assistant how to name a component, which field type belongs in which dialog, and how a light module should be laid out. They encode Magnolia DXP's own recommendations, and for most teams, they are a reasonable starting point. They are not meant to be the last word.

The MCP Developer's Server treats them accordingly. Skills are loaded rather than hardcoded: the server and every plugin contribute a skill directory, the skill loader resolves them into a single set, and each skill carries tags, targets, and a priority. Higher priority wins. A project that needs different component-naming rules does not fork Magnolia DXP's guidance — it layers over the part it disagrees with and keeps inheriting the rest.

The tooling makes it a one-step operation rather than a filesystem exercise. mgnl_dev_list_skills returns everything currently loaded, filtered by tag or target, so a developer can see exactly which guidance is in play before changing anything. mgnl_dev_customize_skill writes a local override copy of an existing skill, leaving the original in place. mgnl_dev_generate_skill scaffolds a new one from scratch when the team's convention has no upstream equivalent. Partners who maintain their own toolkit can go further by shipping skills within their own plugin, so the guidance travels with the code that depends on it.

This is what keeps the guidance layer honest. Magnolia DXP's defaults improve with every release and continue to reach projects that never touched them. The rules a team overrode stay overridden. Nobody has to choose between upstream updates and their own conventions.

Source files describe intent. The running instance describes reality. The two are almost never identical in an enterprise environment, and the gap between them is where most production incidents are born.

The MCP Developer's Server is built to talk to a running Magnolia DXP instance, not just to source. When a generated change depends on something the live system knows — a deployed module's version, an enabled workflow, a permission set, the path of an integration, the state of a published page — the assistant can call into the instance and check rather than guess. When the project and the instance disagree, that disagreement is surfaced rather than papered over.

In practice, this means generated work gets validated in the environment it will actually run in. A dialog change is checked against the live JCR. A configuration value is read back from the deployed system. A diagnosis of a broken page can include relevant log lines and the current node state, not just a guess based on the template code. The distance between “AI suggested this” and “this is safe to merge” gets shorter — which is the real bar for enterprise adoption.

All of the above — project context, curated guidance, live-instance access — could have been built as a closed integration tied to a single AI client or IDE. It isn't. The product's name says where it stands: the Magnolia MCP Developer's Server speaks the Model Context Protocol (MCP), the emerging open standard for connecting AI assistants to external tools and context.

That choice has a few consequences worth being explicit about. The same capabilities can be consumed from any MCP-aware client — a developer's IDE today, a different IDE tomorrow, a partner's own orchestrator, an automated pipeline. They aren't trapped behind one vendor's interface. New capabilities — additional APIs, design-source readers, validation flows, logging integrations, partner-specific tools — can be added as MCP servers and surfaced to every consumer without rewriting the clients.

For Magnolia DXP, MCP is what keeps the AI layer from becoming a fixed experiment. The CMS stays in the system of record. The MCP Developer's Server exposes the AI capabilities as composable tools. Customers and partners can adopt, swap, and extend them at the pace of the broader AI ecosystem rather than at the pace of any single product release.

The MCP Developer's Server runs locally, on the developer's own machine, installed with a single terminal command. It's configured on a server-by-server basis, so a team can run different parameters and plugins for different environments rather than one fixed setup for every project. There's no cloud version — this is a local-first tool by design, which means project code and configuration never leave the developer's own environment.

Getting an agent connected takes a few steps: install the server, tell your agent the details it needs (a Figma access token, the framework you're building in — much of which it can pick up from the local Magnolia DXP project itself), reconnect, and start building from templates.

For Magnolia DXP, that means an assistant that reads the project, talks to the live instance, applies Magnolia-specific expertise, and validates what it produces — not a generic code generator pointed at a CMS.

That is the direction: An AI-ready digital experience platform where intelligent assistance is not a separate product alongside the CMS, but a layer connected to the way teams already build and run digital experiences.