# Reported issues for Umbraco-CMS-MCP-Dev Pod holds 23 of 53 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user. Back to [Umbraco-CMS-MCP-Dev](/mcp/umbraco-cms-mcp-dev). ## Most discussed ### Upgrade mcp Base and hosted mcp to beta.35 for v17 line ## Problem `v17/dev`'s `package.json` pins `@umbraco-cms/mcp-server-sdk` and `@umbraco-cms/mcp-hosted` to `^17.0.0-beta.28` — a separate npm version line from the one `dev` is already on (`^1.0.0-beta.35`). That `17.0.0-beta.x` line stopped publishing at `beta.29` and never picked up the version-check hardening `dev` got via #358/#362: `expectedUmbracoMajor` is now a required argument to `checkUmbracoVersion`, `configureVersionCheckHook()` turns a mismatch into an actual warning instead of a si [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/370) · 2026-08-07 · closed · outside contributor · 5 comments ### create-media filePath uploads always rejected on Windows — SDK regex blocks documented UMBRACO_ALLOWED_MEDIA_PATHS allowlist ## Summary On Windows, every `create-media` call with `sourceType: filePath` is rejected with HTTP 400 *"Field 'filePath' contains a path traversal or absolute path"*, regardless of `UMBRACO_ALLOWED_MEDIA_PATHS` configuration. The cause is a generic SDK input validator that runs before the tool's own allowlist code is reached. The allowlist code path appears to be unreachable on Windows. ## Environment | Item | Value | |---|---| | OS | Windows 11 Pro 24H2 (build 26200) | | Node | 22.12.0 (Vol [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/180) · 2026-05-05 · closed · external user · 4 comments ### The MCP Tools Return Empty Data Hi Dev Team, i got an issue that GET tools like get-document-type-by-id, get-all-document-types, get-data-type, get-all-data-types...return empty data in the response. It caused the issue that AI Agent could not update a document type as i request. In fact AI Agent could create a new document type but could not update it later. **My Configuration:** - Umbraco version: 17.2.1 - Umbraco Developer MCP: ``` { "mcpServers": { "umbraco-mcp": { "command": "npx", "a [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/122) · 2026-03-09 · closed · external user · 3 comments ### UMBRACO_EXCLUDE_TOOL_COLLECTIONS doesn't work Hello, I am using VSCode. With or without this setting I get the same number of tools discovered when I start the MCP server. `"UMBRACO_EXCLUDE_TOOL_COLLECTIONS": "member,member-group,member-type,user-group,webhook"` I have some doubts if `UMBRACO_EXCLUDE_TOOL_COLLECTIONS` setting was actually released because when I install the MCP server I don't see an empty setting for it in the `env `section of the `mcp.json` file. If that's the case, what is the way to track what is released? Also, [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/33) · 2025-10-06 · closed · external user · 3 comments ### Documentation on Umbraco MCP specific rules I think it would be useful to have a set of rules that would be useful specifically for working with the Umbraco MCP Server. This could be a basic guide with a few rules to get strted or something more complete with different rules for different scenarios/use cases. I've been experimenting with Augment in Jetbrains Rider to create a new site from a Bootstrap template then populate that from the front end view of an old V8 site I built years ago. I have to say that I've been really impressed wit [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/28) · 2025-10-02 · closed · external user · 6 comments ### Trying to create media items and upload the image file I'm not sure this is an issue with the MCP server as such, or if it's the way I'm trying to use it, but this is failing for me when trying to uplaod the file. It might be that I need a small change to the prompt I'm using and I'd be happy to try alternatives. Here are the steps I'm using: - Create a new website - Add an API user and create Client Credentials - Configure the MCP server - Test the MCP server connection (Use Umbraco-MCP-Test and add a new Textstring property to the Image media ty [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/25) · 2025-09-30 · closed · external user · 5 comments ### Feature: Enhance json update performance A blockgrid can contain quite a lot of json data in my case. Is it possible to optimize updating of blockgrid content data? Perhaps there is a json patch mcp tool that can enhance the speed and possibly limit the amount of tokens used? [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/21) · 2025-09-21 · closed · external user · 5 comments ### VSCode: Error: self-signed certificate Hello, I installed the server via the VSCode button and configured the env variables. However, when I try to start the server I get an error: 2025-09-05 13:53:56.755 [warning] [server stderr] cause: Error: self-signed certificate 2025-09-05 13:53:56.755 [warning] [server stderr] at TLSSocket.onConnectSecure (node:_tls_wrap:1679:34) 2025-09-05 13:53:56.755 [warning] [server stderr] at TLSSocket.emit (node:events:518:28) 2025-09-05 13:53:56.755 [warning] [server stderr] at [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/6) · 2025-09-05 · closed · external user · 4 comments ## Most recent ### create-document-type hardcodes variesBySegment: false — can't create a segment-varying content type ## What should change `create-document-type` hardcodes `variesBySegment: false` on both the document type and every property it creates: ```ts // src/umbraco-api/tools/document-type/post/create-document-type.ts variesByCulture: false, variesBySegment: false, container: containerId ? { id: containerId } : undefined, ... variesByCulture: false, variesBySegment: false, ``` There's no field on `createDocumentTypeSchema` to request segment (or culture) variation at all, so a caller building a docu [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/429) · 2026-08-26 · open · outside contributor · 1 comment ### Warn when the CLI major doesn't match the target site's Umbraco major ## What should change Tool schemas track the Management API of the CLI's own major, but nothing checks the server. Running `@latest` (18.x) against a 17.x site "works" until a shape mismatch fails confusingly mid-task. Since the CLI already authenticates against the server, it could fetch the server version once and print a warning (or refuse without `--force`) when majors differ. A docs note recommending `@umbraco-cms/mcp-dev@` over `@latest` would help too. ## Provenance - 2026- [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/426) · 2026-08-22 · open · outside contributor · 2 comments ### create-element-type / create-document-type silently drop description, mandatory, sortOrder on properties ## What should change The create tools' property input accepts only `{name, alias, dataTypeId, tab, group}`. Passing `description`, `mandatory`, or `sortOrder` neither errors nor applies — the fields are silently discarded, and the caller only finds out via a follow-up GET. Either support these fields on create (they're standard property metadata, and `update-document-type` accepts them) or reject unknown keys so the caller learns immediately. ## Provenance - 2026-07-24 — CLI 18.0.0 against U [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/425) · 2026-08-22 · open · outside contributor · 1 comment ### --call should not wait on stdin: programmatic invocation with piped stdin hangs as an MCP server ## What should change When the CLI is invoked programmatically (e.g. `execFileSync(node, [cliPath, '--call', tool, ...])`) with stdin left open/piped, it waits for MCP protocol input and hangs indefinitely instead of executing the `--call`. Callers must know to pass `stdio: ['ignore', ...]`. When `--call` (or any introspection flag) is present, the CLI should never enter server mode or read stdin. ## Provenance - 2026-07-24 — CLI 18.0.0, Windows 11 / Node 22: direct invocation hung until stdi [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/424) · 2026-08-22 · open · outside contributor · 1 comment ### --call-args needs a file/stdin input option: large or non-ASCII inline JSON fails silently on Windows ## What should change `--call-args` only accepts inline JSON on the command line. On Windows this fails in ways that are hard to detect: - Inline JSON over ~8 KB makes the mutation silently no-op — exit 0, no error output, nothing written (verified: a 2.6 KB payload applied, a 9.9 KB payload did nothing). - The `npx.cmd` shim mangles multiline JSON, non-ASCII, and shell-special characters (`[b]`, smart quotes) — "Invalid JSON for --call-args" at best, silent corruption at worst. - Even bypassi [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/423) · 2026-08-22 · closed · outside contributor · 2 comments ### [from-learnings] MCP Registry publish has been silently failing since 18.1.0 — registry is 2 releases stale ## What should change The Azure DevOps release pipeline's `Deploy_MCP_Registry` stage has been silently failing for at least the last two releases (18.1.0 and 18.1.1) — the live MCP Registry listing has no entry past 18.0.1 for `@umbraco-cms/mcp-dev`. `get_job_logs` 404's for this job (logs unavailable via API), so this was confirmed by cross-checking the Azure DevOps build results page against the live registry listing directly. A "published" release currently only means npm + GitHub Release — [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/421) · 2026-08-22 · closed · outside contributor · 0 comments ### [from-learnings] sync-main-to-dev dev-sync PR gets stuck in action_required because the run is bot-triggered ## What should change `sync-main-to-dev.yml`'s auto-opened dev-sync PR gets its required "Test Suite" check stuck in `action_required` (workflow run needs manual approval) because the run is triggered by `github-actions[bot]`. auto-release-loop has to notice this via `list_workflow_runs` and re-trigger the run under its own authenticated identity to clear the gate before the PR can merge — this happens on every release that goes through this path. Consider whether the repo's Actions settings ( [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/419) · 2026-08-22 · closed · outside contributor · 0 comments ### Release 17.6.3 blocked by pre-publish review The `auto-release-loop` pre-publish review (Step 2.5) **BLOCKED** publishing v17.6.3. Release PR: #416 (`release/17.6.3` → `v17/main`) Triggering issue: #415 ## Blocking finding `.github/workflows/release-tag.yml` (43 new lines, added in PR #416) duplicates and races the repo's **existing** Azure Pipelines release automation. - `build/azure-pipelines.yml`'s `Create_GitHub_Release` stage already tags and creates the GitHub Release for the `v17/main` line, gated on `Deploy_Npm` succeeding firs [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/417) · 2026-08-21 · closed · outside contributor · 1 comment ### Hosted Worker doesn't opt into OTel tracing — no MCP spans are recorded ## Summary The hosted Worker never opts into OpenTelemetry tracing, so it produces no MCP spans — silently, with a perfectly healthy deploy. Two lines in `src/worker.ts` fix it. ## Why nothing is recorded `@umbraco-cms/mcp-hosted` instruments tool calls, but the wiring is **opt-in**: `tracing` has to be handed in from the consumer, because `cloudflare:workers` only resolves inside the Workers runtime and the library can't import it (same reason `McpAgent` and `OAuthProvider` are wired up in ` [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/399) · 2026-08-19 · closed · outside contributor · 1 comment ### upgrade to MCP base SDK 36 for v17 line ## Problem The `v17/dev` branch pins the base SDK packages to beta.35: ``` "@umbraco-cms/mcp-hosted": "^1.0.0-beta.35", "@umbraco-cms/mcp-server-sdk": "^1.0.0-beta.35", ``` Umbraco-MCP-Base has since published `1.0.0-beta.36`. This line should track it. Checked what beta.36 actually changes (diff between the beta.35 and beta.36 tags in umbraco-mcp-base): a behaviour-neutral OTel telemetry seam (dark until a host wires up an exporter — see `feat: OTel tracing` in that repo), plus two dependen [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/392) · 2026-08-19 · closed · outside contributor · 2 comments ### upgrade to MCP base SDK 36 ## Problem `package.json` pins `@umbraco-cms/mcp-hosted` and `@umbraco-cms/mcp-server-sdk` to `^1.0.0-beta.35`. `1.0.0-beta.36` of both packages is now published and we should track it. I diffed the published `beta.35` → `beta.36` dist output for both packages (`npm pack` + extract, no source repo access needed): - SDK adds an OpenTelemetry-style telemetry API: `TelemetryAdapter`, `TelemetrySpan`, `TelemetryAttributes`, `SpanAttributes`, `AttributeValue`, `setTelemetryAdapter`/`getTelemetryAd [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/390) · 2026-08-18 · closed · outside contributor · 1 comment ### MCP Registry publish failing since 18.0.2 The `Deploy_MCP_Registry` stage in `build/azure-pipelines.yml` (job "Push to MCP Registry") has been failing on stable releases for at least two release cycles now: - **18.0.2** — npm published fine; GitHub Release created fine. - **18.1.0** — same: npm published fine, GitHub Release created fine. Evidence: [registry.modelcontextprotocol.io](https://registry.modelcontextprotocol.io) still shows `18.0.1` as the latest published version of `io.github.umbraco/Umbraco-CMS-MCP-Dev`, even though `18 [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/389) · 2026-08-13 · open · outside contributor · 0 comments ### Upgrade mcp nase and hosted mcp to beta.35 https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/358 replicate this [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/369) · 2026-08-07 · closed · outside contributor · 2 comments ### Upgrade to @umbraco-cms/mcp-server-sdk beta.35: orval helpers moved, target major now discovered This repo is on `^1.0.0-beta.31`. Three SDK changes since then need action here, and they interact with the open PR #353. ## 1. Orval helpers moved to a `/orval` subpath — **breaking** umbraco/Umbraco-MCP-Base#247 moved the build-time codegen helpers out of the SDK's main entry, because that barrel is what `@umbraco-cms/mcp-hosted` bundles into a Cloudflare Worker and these modules import `fs`/`path`. The root re-exports were removed outright (no deprecation cycle — the SDK is beta and consume [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/358) · 2026-07-31 · closed · outside contributor · 1 comment ### Upgrade to the latest MCP base beta of version 34 ## Problem `package.json` pins `@umbraco-cms/mcp-hosted` and `@umbraco-cms/mcp-server-sdk` at `^1.0.0-beta.31`. The base package (`umbraco/Umbraco-MCP-Base`) has since released `1.0.0-beta.34` — confirmed as both the `latest` and `beta` npm dist-tags for both packages, so it's the real latest (the higher-numbered `17.0.0-beta.x` versions also on npm predate the `1.0.0-beta.x` renumbering done in beta.30 and are not newer). Checked the beta.32 → beta.34 changelogs in `Umbraco-MCP-Base` for anyt [Read the thread](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues/356) · 2026-07-30 · closed · outside contributor · 2 comments The remaining reports are on [the project's issue tracker](https://github.com/umbraco/Umbraco-CMS-MCP-Dev/issues).