As of hotfix 31.8.3, we're dropping the preview label from the Xperience by Kentico Management MCP server and the underlying Management API. Nothing in how these interfaces behave changes with this release. The tools, routes and parameters are the same ones you have been using. We're just removing the -preview suffix.

We're confident this is where developer tooling is heading. For the majority of software, interfaces that agentic tooling can operate on are now an expected feature, not an experiment.

The scope of where these tools should be used isn't changing either. These interfaces are still intended for development only, running against a local project.

The Management API currently ships with basic authentication and no granular authorization, so keep it off production deployments and anything else publicly reachable. We've already seen great results from teams it to build production sites, and that feedback is what tells us the preview label was lagging behind how the tooling is already being used.

APIs and MCPs and Agentic Interfaces, Oh My!

The tech world hasn't settled on widely accepted terminology for this yet. We've been seeing everything from Agent-Computer Interfaces (ACI) to Agent-Native APIs. But the trend is clear. APIs have been evolving, and many of the golden standards that have dominated software for years have been challenged, for good reason.

Traditionally, APIs are rigid. Strict rules, slow and expensive changes, and comprehensive documentation so human developers can understand how to use, integrate, and maintain them. Those guarantees exist for a reason: a human reads the documentation once, writes an integration by hand, and that integration is expensive to change.

Agents don't work that way. They discover the schema, write a script against it, and when the schema updates they rewrite the script. They need strong context, but they can take context updates on the fly. MCP servers embrace this model. The routing is dynamic by design, and request parameters and responses are more fluid than a REST contract would usually allow. Models are moving just as quickly, and each generation needs a different amount of hand-holding to be effective. Using an MCP server with GPT-3.5 is a fundamentally different experience from using GPT-5.6.

Developers increasingly don't need to know the specifics of an interface up front, as long as they can communicate intent clearly. That holds whether you're working via MCP or an API. You're generally do not tell the agent to "Use create_post to create a new blog post". The prompt looks more like "For each row in blogs_export.csv create a new blog post", and the agent orchestrates the available tools to get there.

The Management API & MCP Are Written for Agents

Ultimately, the purpose of the Management API and MCP — at least for now — is to enable agentic development on Xperience and serve as the data layer for KentiCopilot. These interfaces will rapidly change and expand in scope as AI tooling matures and agentic development needs evolve.

You should expect regular releases for both our NuGet and npm packages, often shipping with major changes. This means that our regular support policy for APIs cannot apply. The 12-month backward-compatibility period is not guaranteed, and tools, routes, and parameters can be renamed or removed without a transition period. Anything notable is recorded in the changelog. You can read more of the specifics in Update policy and backward compatibility.

What This Means for the Human Developer

While our agent-native APIs are optimized for agents, our developer experience is focused on the human developer. We want our developers to be successful, well-supported, and able to develop with confidence even in a relatively technologically chaotic time.

Based on industry trends and the design intentions behind the Management API & MCP:

  • Account for possible changes to tool names when referencing them in prompts, skills, or agent configurations

  • Do not directly integrate with the Management API, or build and commit an SDK on top of the spec

  • These interfaces will change rapidly. Fixes and updates will be delivered on a best-effort basis

  • Your agents can reference the MCP tool list and the OpenAPI JSON to discover all routes and tools available in the version of the API you're using

  • The KentiCopilot plugin repository is an excellent reference point for building on top of the Management API & MCP

These interfaces are shaped by early feedback, so check the roadmap to see what's coming and share your feedback there. You can also sign up for access to our Feedback MCP. If something breaks, report the issue through the support center.

What's Next

I mentioned feedback and rapid changes, so I’d like to share what our team is working on and give you a look at what might be coming next.

Forms & Consent

From our internal experimentation, we have determined that Forms are one of those big-ticket items that are currently missing from our Management API. We completed the design specification, and our engineers are currently implementing a Forms route in the Management API.

Based on your feedback, being able to manage Consents via the API and MCP is also valuable, so we're prioritizing this work.

New Errors Interface

We're not happy with the error messages currently returned by the Management MCP and API, so we'll be introducing a new standard for error responses. The aim is to provide insightful, actionable errors so your agents know what's wrong and how to resolve the issue.

This should also help us collect better feedback via the Feedback MCP server.

A Benchmark Project

Creating tooling that can largely automate an end-to-end Xperience build presents several challenges.

We need a way to test our changes, measure their impact and generate feedback before we release anything. A traditional integration or regression test will not do this. Running evals for the tools does help (and we just updated our internal evals suite!), but it's not enough.

The solution we came up with is to create a proper benchmark project. The intention is to use KentiCopilot exactly as intended, but in a controlled environment.

This gives us the opportunity to run the benchmark with any features we plan to release, measure the build times, token consumption, error rates, while also gauging build success — especially as new AI models are getting released. I'm looking forward to sharing more details in the coming weeks, but our early results have been very promising.

A New Management MCP Version

The feedback our team received so far about our Management MCP has been overwhelmingly positive, and we all thank you for that. It took our combined efforts across the whole of R&D to get to this point. However, as you can imagine, this is just the first iteration of the Management MCP. We are already seeing ways we can do things better, and we're starting to experience some of the limitations of the MCP protocol.

More specifically:

  • In larger projects, most agents tend to avoid the MCP for bulk operations and instead use the API directly.

  • MCP operations can be slower and more costly than operations performed directly through the API.

  • "Code mode" MCP tools are becoming more of a standard. They are quite performant and efficient.

  • The Management MCP is, to a large extent, a 1:1 representation of the API. This is great as a building block, but if we were to expose the whole Xperience ecosystem following this approach, we’d encounter strict limits on the number of MCP tools that can be active at the same time.

The good news is that the Management API will always be there for your agents, and we can make the Management MCP even better. We have started defining the next version of the Management MCP and are creating a corresponding design specification. We'd also like to add more guardrails so we can eventually take the Management API & MCP beyond your local development environment.