Umbraco's MCP Software Factory: what it actually means for agencies

Umbraco has just done the thing I quietly hoped it would do: it stopped treating MCP as a single feature and turned it into a platform every partner can build on. The headline is a tool called create-umbraco-mcp-server, which HQ is calling a "software factory". Grand name. The interesting part is what sits underneath it, and whether it saves you the week you'd otherwise spend wiring up authentication and transport for the third time this year.

I build on Umbraco for a living, so I read the announcement the way any agency owner would: not "isn't this clever", but "does this remove work I'm currently doing by hand". Mostly, yes. Here's the honest version.

The problem this solves

If you've built anything agent-facing on Umbraco, you already know the tax. Every MCP server needs the same scaffolding: authentication, transport, tool registration, environment handling, and a reliable connection back to a running instance. None of it is the thing you actually wanted to build. It's plumbing, and you re-lay it every single time.

Umbraco hit exactly this internally. They shipped the first CMS Developer MCP last October as a local server over stdio, exposing the Management API to agents like Claude Code and Cursor. It worked, agencies picked it up on day one, and then HQ started designing the next ones for Forms, Engage and Commerce and realised they were about to solve the same four problems all over again. So they extracted the platform. Sensible engineering, and the bit that matters to us is that they've opened it up rather than keeping it in-house.

The Base MCP SDK is the actual product

Strip away the marketing and the foundation is the Umbraco Base MCP SDK. Every Umbraco MCP server now runs on it, HQ's own included, and it's on GitHub for partners and package authors to build against. That's the piece I care about most, because a shared foundation is what makes everything above it credible. If HQ ships their own servers on the same SDK they're handing you, the incentives are aligned to keep it decent.

They've extended that foundation in three directions, and it's worth being clear about what each one is for rather than lumping them together.

MCP as a CLI. The Umbraco CLI wraps the same toolset as the local MCP server, just over a different transport. You run an npx command, get JSON back from the Management API, and pipe it into whatever you like. No MCP server in the middle, no LLM required. This is the one people will underrate. It's genuinely useful outside the AI conversation entirely: CI/CD, client onboarding scripts, environment checks. Point it at a .env file and you're connected.

Hosted MCP. Instead of running locally, the server runs as a streamable HTTP endpoint with full OAuth. You stand up a Cloudflare Worker pointing at your instance, and any agent that supports remote MCP (Claude Desktop, ChatGPT, Cursor) connects with a URL. The consent screen lets you choose which tools and modes are exposed. This is what finally reaches the editor on a client's marketing team who wants to draft content from ChatGPT without touching Visual Studio. Umbraco has said remote MCP will land on all Umbraco Cloud tiers in summer 2026, so treat that as the direction of travel rather than something to promise a client today.

MCP chaining. This is the one I find most interesting for agency work. Chaining lets one MCP server compose with another, so if you build a server for your own package or content structures you don't re-implement document, media or content-type tools. You pull them in from an existing Umbraco MCP server and use them as your own. There are three patterns: proxying (re-expose another server's tools alongside yours), delegation (call a chained server inside your own handlers, keeping your tool the public face), and composite tools (orchestrate several chained calls into one, cutting LLM round-trips). HQ describe it as building MCP servers out of Lego, which is annoyingly accurate.

So what is the "software factory"

create-umbraco-mcp-server is the CLI tool that ties all of that together. HQ define a software factory as a deterministic and agentic system that takes a specification and autonomously produces working, deployed, tested software with minimal human intervention. You hand it an Umbraco package, it hands you back a tested MCP server. The entry requirement is an OpenAPI schema: the moment a package exposes one, it's a few steps from being agent-ready.

It walks through five phases, Create, Initialize, Discovery, Build, and Evaluate & Iterate, covering boilerplate, OAuth setup, OpenAPI analysis, tool generation and evaluation. The phase I'd actually judge it on is the last one. The evaluation tests are described as end-to-end tests for agents: they check your tools work together, not just in isolation. That's the right instinct. Anyone who has watched an LLM confidently misuse a tool that passed its unit tests knows that agent behaviour is where these things fall over, and if the factory bakes that verification in by default, that's the feature, not the boilerplate generation.

Where I'd be careful

I'm not going to pretend "software factory" isn't a big claim. A generator is only as good as the schema you feed it and the evaluation harness behind it, and "minimal human intervention" tends to mean "until it doesn't". I'd want to run one through a real package before I tell a client their integration is agent-ready in an afternoon.

The security surface is the other thing worth slowing down on. Hosted MCP means a live OAuth endpoint that can drive the Management API from outside your network. Umbraco has done the sensible thing by reusing the back-office OAuth flow and existing permissions, and putting tool exposure behind a consent screen, but the responsibility for scoping that correctly lands on whoever deploys the Worker. Handing an agent a URL that can edit content is exactly as powerful, and as dangerous, as it sounds. Configure it like you'd configure any other privileged integration, not like a toy.

Where I'd start

If you want to get a feel for it without committing to anything, the CLI is the low-risk entry point. It's useful on its own, it doesn't require you to expose anything publicly, and it teaches you the tool model before you go near hosted deployments. From there, chaining is where the agency value is: it's what lets you build only the genuinely new part of a client integration and inherit the rest.

The whole lot, the Base MCP SDK, the factory, the chaining patterns and the docs, is open and available now. It's a real step towards Umbraco being a first-class participant in the AI workflows clients already run, rather than a CMS you bolt AI onto after the fact. That's worth an afternoon of your time to evaluate properly.

If you're weighing up how any of this fits a live Umbraco build, get in touch and I'll tell you where it's ready and where it isn't.