Kentico's Management MCP server: AI that builds inside your CMS, and keeps every change reviewable

In late June, midway through a build, my AI coding assistant stopped and told me it was giving up.

It was working through Kentico's Management MCP server - a still-in-preview tool that lets an AI agent build and manage the content and structure of an Xperience by Kentico project - the same way a developer would through the admin UI, except by conversation. I'd asked it to remove two fields from a content type. Simple. Instead, one call appended duplicate items; the next call silently wiped four fields. The tool's behaviour was non-deterministic - the same instruction produced a different result depending on when you sent it. My assistant said, in as many words: "I can't drive this reliably - I'm going to stop before it gets worse."

I restored the database and I added the fields by hand in the admin UI, the old-fashioned way.

I'm telling you that story first because a few weeks later the same tool, against the same platform, handled the initial setup of four brand microsites in an afternoon - and I want you to believe the second half.

The Management MCP has been in preview since late 2025, improving steadily through the first half of 2026 - but the June update was the leap: a wave of new tools, and the usability and dependability to match. The sharp edges I'd just hit were gone. I'd written about the MCP server back in May, when it was still called the Content Management MCP Server. At that point it was more or less limited to content types, and had some teething issues, but with Kentico iterating and completing that agentic development story, it is getting far better.

Plenty of teams have tried building their own MCP servers and tools, wired up to a CMS through screen-scraping or hacking around databases or APIs. What sets this one apart is that it's official.

As part of this, Kentico built a REST API, shipped as a supported NuGet package which powers the first-party MCP server. The MCP server is a flagship tool within Kentico's KentiCopilot suite of AI development tools. That means an AI agent is a first-class way to operate the platform, sanctioned by the people who build it, not a clever hack layered on top.

That distinction matters more than it sounds. An official, versioned surface is one you can reason about, that moves with the product, and that the vendor is accountable for. Kentico being serious about this - the API is explicitly pitched at "agent-driven workflows," down to new CLI flags designed for automation - is a signal about where they think this is going. That's not cheerleading; it's coming from the person the same tool had defeated a few weeks before.

The test was a real client project under real constraints: four brand sites with an August launch deadline, served from a single Xperience application - a parent site plus three brand microsites, one deploy artefact, built multilingual-first even though only English ships at launch. Not a sandbox. A multi-brand build with a hard, external deadline.

Across three working sessions we made roughly 153 Management MCP tool calls using thirty distinct tools. The agent executed exactly the actions required, using the appropriate MCP tools.

Two moments stand out. On day one, four website channels, their scopes, four home pages and brand-specific templates went from nothing to four different headings rendering on four local ports - an afternoon's conversation. On day two I pointed the assistant at the project's status document and typed, more or less, "we've set up the channels, what was next?". From that one prompt it continued planning and building the rest of the microsite functionality. It built out the content model, folders, real sample content, multiple pages, and a number of Page Builder widgets. The MCP did the CMS side by conversation; the C# was written the normal way, with nineteen passing unit tests behind the business logic.

Here's where I'd push back on the usual framing. The interesting thing is not that an AI clicked around the CMS for me. If that were all it was, I'd be nervous - invisible changes to content, made by a model, with no paper trail, is a governance nightmare, which would make signing it off risky.

What makes this workable is the loop underneath it. Every change the agent made through the MCP got serialized to Kentico's CI repository and committed as a diff. Content types, channels, workspaces, languages - all of it landed as reviewable XML in a pull request, in exactly the same source-control workflow we already use for code. So an AI-driven CMS change isn't a mystery mutation in a database somewhere. It's a diff a human reviews, approves, or rejects. It inherits every bit of governance we already trust for code: review, history, blame, rollback, environments.

That is the unlock. Speed is nice and it's real, but speed without accountability is a liability. Reviewability is what lets a technical director actually allow this on client work. If you're evaluating any AI-assisted platform tooling, that's the question I'd put first - not "how fast", but "where does the change land, and can a human see it before it ships?" On this platform, the answer is: in your repo, as a diff, every time.

The honest boundaries are as important as the wins.

The Management API is disabled entirely in production, by design - so the Management MCP server built on it can't reach production either. It's a developer tool for local, agentic work, and keeping it out of production means that whole class of risk simply isn't there.

Another boundary showed up when we needed a custom admin application. We needed a new module created for editing translations, and importing them. To begin with, the agent tried looking for tools to add a custom module to the admin application, still thinking in a Kentico Xperience 13 mindset. After it checked the documentation, it realised it could just go ahead and build the module using Xperience by Kentico's code-first approach to building a module.

For a team choosing a DXP: the question is no longer just "does it have the features". It's "can an agent operate it through a surface the vendor supports, and does that operation stay reviewable?". Kentico can now answer yes to both. That's a genuine differentiator, and I'd weigh it.

For agencies pricing builds: the standing-up of channels, content models and content - the structural typing that used to eat days of careful clicking - compresses hard. What doesn't compress is the judgement: the architecture, the boundaries, the review. Price accordingly, and be honest with clients about which part got faster.

And for developers wondering what's left: the typing got automated, not the thinking. In every session here, I decided the content model, I set the boundaries, and I reviewed every diff before it landed - the agent did the typing, I did the judging. Think back to the June refusal. An agent can flag that something looks unsafe, but what counts as safe, what's worth building, and what actually ships are human calls. That judgement is the developer's job now, not the tool's - and it didn't shrink when the typing disappeared. It moved up a level, to exactly where it should be.

Everyone's braced for the version where the machine takes the developer's judgement. What I saw was the opposite: it took the typing and handed the judgement back. That's the better ending - and I don't think enough people are betting on it.