Nothing about the server decides what the agent may change - the API user does. That is the right place for the decision, because it is the same control your editors already work under, and it means a read-only agent is a read-only API user rather than a configuration flag. Check the repository notice before adopting: the project has moved to an Umbraco-owned home.
A server over Umbraco's Management API. It authenticates as an Umbraco API user, which means the tools an agent can actually use are decided by ordinary Umbraco permissions rather than by the server. Development has moved to an Umbraco-owned repository.
- Data types: search, read one, list children, ancestors and roots, check whether one is in use, and read its references
- Create, update, copy, move and delete data types, and organise them into folders
- The same browse-and-manage shape across the other Management API areas the server covers
- Cultures available in the installation, read back for language work
- An exclusion list so you can hide tools by name from the surface, for agents that cope badly with a long list
An Umbraco installation - the project states it currently works with version 15 - and an API user created in the back office; the access you grant that user is exactly what the agent can do. Run it with npx and the published alpha package. Three environment variables carry the credentials: client id, client secret and base URL. A local instance with a self-signed certificate additionally needs Node's TLS rejection turned off, and the tool list is long enough that a small context window may need trimming with the exclusion variable.
One command plus a key — npx @umbraco-mcp/umbraco-mcp-cms@alpha, then supply credentials