The agentic AI space is moving fast. New protocols, new platforms, and new editor-facing capabilities land every few weeks, too fast for most organizations to keep up with while delivering client work. Our Umbraco in AI track exists to watch what's emerging and turn it into tools you can pick up today. We've spent the past year putting that idea to the test with MCP, and the result is a platform anyone in the Umbraco ecosystem can build on.
Imagine being able to:
Have an editor on your client's marketing team open ChatGPT or Claude and update content directly in Umbraco, through a single secure URL, with existing Umbraco permissions in place.
Take any Umbraco package with an OpenAPI schema and let our software factory turn it into a fully-featured MCP server, local, hosted, and CLI, end-to-end, with no plumbing on your side.
Compose your own MCP server from the official Umbraco MCP tools, so you build only what is genuinely new.
That’s the promise of opening Umbraco’s MCP foundation up to the ecosystem. Here’s how we got there, and why it matters for any partners and end clients building on Umbraco.
MCP as a platform
When we released the first version of the Umbraco CMS Developer MCP last October, it was an experiment. A local MCP server, connecting over standard input and output, exposing the Umbraco Management API to agents like Claude Code or Cursor.
That experiment turned out to be successful. Agencies started using it the day it was released. Editors started asking, “Could I just talk to my Umbraco?” And — most importantly for what comes next — we learned a lot from building it.
But the CMS Developer MCP was never going to be the only MCP at Umbraco. The roadmap is full of them: for Umbraco Forms, Engage, Commerce, and beyond. Every time we sat down to design the next one, we realised we’d be re-solving the same problems we’d already solved — authentication, transport, tool registration, environment handling, the connection back to a running Umbraco instance.
So we did what good engineering teams do when they see the same patterns three times in a row: we extracted the platform.
The result is the Umbraco Base MCP SDK — a common foundation that every Umbraco MCP server is now built on. The CMS Developer MCP runs on it. Every future MCP server we ship at Umbraco HQ will run on it. And, as you’ll see, it’s now also available for partners and package authors to use.
Over the last couple of months, we’ve extended this foundation in three significant directions.
MCP as a CLI
CLI tools are having a moment. If you’ve spent any time on LinkedIn recently, you’ll have seen the debates about CLI vs. MCP, and which is the “right” interface for connecting agents to systems.
Our answer is: both. And they should share the same tools.
The Umbraco CLI wraps exactly the same toolset the local MCP server exposes; it just uses a different transport. So you can run an npx command from your terminal, get a JSON response back from your Umbraco instance, and pipe it into anything else. No MCP server in the middle, no LLM required - just you and the Umbraco Management API.
It becomes really powerful inside an agent like Claude Code: paired with our Agent Skill that teaches the agent how the CLI works, you can connect to an Umbraco environment using nothing more than a .env file. But it’s just as useful outside the agentic world too, scripts, CI/CD pipelines, client onboarding automations.
Hosted MCP
The original Umbraco CMS Developer MCP runs locally - agents on your machine connect to Umbraco running anywhere. That’s perfect for developers, but it doesn’t help the editor on a marketing team who wants to ask ChatGPT or Claude to draft an update directly in Umbraco.
Hosted MCP solves that. Instead of running locally over stdin/stdout, an MCP server now runs as a streamable HTTP endpoint with full OAuth. You set up a Cloudflare Worker that points at your Umbraco instance, and any agent that supports remote MCP - Claude Desktop, ChatGPT, Cursor - can connect with just a URL. You go through the same OAuth flow you’d use for the back office, and you’re in.
In the Worker’s consent screen, you choose which tools to expose and which modes are enabled. Or the developer can hard-code that for a specific role for an MCP server that has a specific use.
MCP chaining
This is the one I’m most excited about. MCP chaining lets one MCP server compose with another - so a partner builds an MCP server for a package or just to support their own content structures, and they don't have to re-implement document, media, or content type tools. They can pull them in directly from any Umbraco MCP server and use them as if they were their own.
There are three patterns:
Proxying - re-expose another server’s tools alongside your own, prefixed with the chained server name (e.g. cms_).
Delegation - call a chained server inside your own tool handlers. Your tool stays the public-facing one; the dependency is hidden.
Composite tools - orchestrate multiple chained calls into a single tool, reducing LLM round-trips and giving the model a cleaner interface.
It feels a little bit like building MCP servers using Lego.
Together with hosted MCP and the CLI, these three pillars open the door to a fully featured editor MCP - something we’re currently working on.
Why we’re opening this up
Agentic tooling is moving quickly. Even for an organisation like Umbraco - open source, transparent, with everything we build available on GitHub - expecting our partners and customers to keep up with the pace is hard. For agencies trying to integrate this into client work alongside everything else they’re delivering, it can feel impossible.
That’s why we decided to open the Base MCP SDK up to the Umbraco ecosystem.
Every package author on the marketplace can now turn their package into a fully-featured MCP server - local, hosted, and CLI, all in one. The moment an Umbraco package exposes an OpenAPI schema, it’s a few steps away from being agent-ready.
But MCP is complex to implement, even with a good SDK. So we needed to go one step further.
The Umbraco MCP Software Factory
We took everything we’d learned from twelve months of building MCPs at Umbraco, and turned the whole process into a CLI tool: create-umbraco-mcp-server.
“CLI tool” undersells it. This is a software factory.
A software factory, in the way we mean it, is a deterministic and agentic system that takes a specification and autonomously produces working, deployed, tested software - with minimal human intervention. You hand it a starting point, an Umbraco package; it hands you back a tested MCP server.
create-umbraco-mcp-server walks you through five phases: Create, Initialize, Discovery, Build, and Evaluate & Iterate, covering everything from boilerplate generation through OAuth setup, OpenAPI analysis, tool generation, and LLM-driven evaluation tests. Those evaluation tests are a bit like end-to-end tests, but for agents: they verify your tools actually work together, not just in isolation.
We deliberately built the factory using the same agent infrastructure we use internally at Umbraco HQ. Your output uses the same patterns, the same evaluation harness, and the same conventions we use to ship our own MCP servers. The full breakdown of each phase, including the Claude Code plugin used to generate the tools and tests, lives in the Umbraco in AI documentation.
Where this leaves us
Our goal in the Umbraco in AI track has always been twofold:
Reduce friction for agents using Umbraco by improving Agent Experience - that’s been the through-line of the Skills work covered earlier in this series, and now for MCP.
Enable the ecosystem to build their own agentic tools on top of Umbraco, with as little friction as possible - and that’s what this fourth post is about.
We’re a partner and community-driven, open source platform. It mattered to us that this work didn’t just sit inside Umbraco HQ - that our partners, our package authors, our agencies, and our end clients could come on the journey with us. The Base MCP SDK, the create-umbraco-mcp-server software factory, the chaining patterns, the evaluation tooling, the docs - all of it is open and available today.
Because the future of CMS isn’t just human-friendly. It’s agent-ready.
Want to dive deeper? Check out Bolette and my AI talks at Codegarden:
The Agent-Ready CMS - a 4-part series
This was the final piece of our series. For now. Catch up on the previous blog posts to make sure you’re all updated on the Umbraco AI/Agent foundation that’s ready for you to explore:
What are Agent Skills? - and why they matter for the future of your Umbraco project
Introducing Agent Skills: Umbraco Backoffice Extension Skills
Building Implementation Agent Skills for Umbraco
Enable the Ecosystem: Our base MCP implementation for partners and package developers (the post you're reading now)
