# MCP Module - Persistent 405 Error **URL:** \ **Category:** Ignition Early Access\ **Created:** [September 8, 2026, 8:17pm UTC](https://forum.inductiveautomation.com/t/mcp-module-persistent-405-error/117021 "2026-09-08T20:17:30Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Eric\_Doucet](https://avatars.discourse-cdn.com/v4/letter/e/8edcca/32.png) [@Eric\_Doucet](https://forum.inductiveautomation.com/u/Eric_Doucet)\ **Post date:** [September 8, 2026, 8:17pm UTC](https://forum.inductiveautomation.com/t/mcp-module-persistent-405-error/117021/1 "2026-09-08T20:17:30Z")
Continuing the discussion from [MCP Module Early Access](https://forum.inductiveautomation.com/t/mcp-module-early-access/113966): # Persistent 403 Forbidden on /data/mcp/ — everything checks out except the actual request I'm stuck on a generic 403 Forbidden from the MCP module's runtime endpoint that persists after eliminating every cause I can find from the client/config side. Hoping someone from IA (or anyone who's hit this) can point at what else determines a pass/fail here. ## Environment - Ignition standard **8.3.8 (b2026071409)**, running in Docker Desktop on Windows (named volume `ignition83_gw-data`) - MCP module: **Model Context Protocol, v1.3.5-SNAPSHOT (b2026021307)** — shows **Active** , License **Free** , not faulted, not trial-limited - Client: Claude Desktop (Windows) connecting via the `mcp-remote` bridge (`npx mcp-remote --header "X-Ignition-API-Token: ..."`) - Server-config name: `testing`, backed by project `Hutto_2` (non-inheritable, contains a Tool resource) ## The error Every request to `POST http://localhost:9088/data/mcp/testing` returns: ```python HTTP/1.1 403 Forbidden Content-Type: application/json { "message": "Forbidden", "url": "/data/mcp/testing", "status": "403" } ``` This happens **identically** whether the request comes from `mcp-remote` (via Claude Desktop) or a raw `curl.exe` call made directly on the Docker host — so it's not a client-side quirk, header-casing issue, or network/loopback problem. It's the gateway itself rejecting the request. ## What I've already ruled out 1. **Network path** — confirmed working. `curl.exe` against the same gateway gets real, structured HTTP responses (403s, 404s, 401s with correct bodies) — not connection refusals or timeouts. Docker's published port (`9088:8088`) is reachable fine from the host. 2. **API key token format** — found and fixed a real issue: the token must be sent as `:` (e.g. `Claude:AbC123...`), not just the bare secret. Using the bare secret returned **401 Unauthorized** on the generic `/data/api/v1/resources/...` endpoint. Switching to the full `name:secret` format eliminated the 401 (a bad token would still 401; instead we got a 404 on an unsupported route), confirming the token itself now authenticates correctly. This didn't change the 403 behavior on `/data/mcp/testing`, though. 3. **`config.json`'s `tools` key** — caught that I'd left the walkthrough's literal placeholder `project/$test` in place instead of substituting a real project name. Fixed to reference `project/Hutto_2`, a real, non-inheritable project containing a Tool resource created in the Designer. Confirmed via Docker Desktop's file browser that the edit saved and the JSON is valid. 4. **`resource.json`** — matches the walkthrough's example exactly (`scope: A`, `restricted: false`, `overridable: true`, valid UUID). 5. **Gateway Read/Write/Access Permissions** — granted the API key's security level (`Authenticated > Roles > `) explicit checkmarks in all three trees under Security → General Settings. 6. **Module health** — Config → System → Modules shows the MCP module as **Active** , Free license, no fault indicators. 7. **Full gateway restart** — restarted the container after every config change to rule out stale in-memory state. 8. **SSL/TLS** — not even configured on this gateway (no certificate installed, "SSL/TLS NOT ENABLED" shown on Web Server Settings), so a forced-HTTPS redirect is not possible here. 9. **Gateway-side logs** — checked Diagnostics → Logs with Min Level set to ALL, filtering by `mcp`, `403`, and `Forbidden` — no matching log entry appears at all, at any level, corresponding to the rejected requests. Whatever is producing this 403 doesn't appear to log through the standard logger viewer. ## Possible lead The module build (`1.3.5-SNAPSHOT`, `b2026021307` — mid-February) is about five months older than the platform build it's running on (`8.3.8`, `b2026071409` — mid-July). Wondering if there's an internal API mismatch between this module snapshot and a newer platform security/permissions API that could cause a permission check to fail closed (deny-all) while the module still reports itself as healthy. ## Question What else, beyond a valid API token and a correctly-referenced non-inheritable project, determines whether `/data/mcp/` accepts vs. rejects a request with this generic 403? Is there a `Config → Logging` logger specific to the MCP module that needs to be raised to DEBUG/TRACE to actually see the rejection reason (I haven't found one by name yet), or a known compatibility requirement between module and platform build numbers I should check? ---
**Author:** ![Eric\_Doucet](https://avatars.discourse-cdn.com/v4/letter/e/8edcca/32.png) [@Eric\_Doucet](https://forum.inductiveautomation.com/u/Eric_Doucet)\ **Post date:** [September 10, 2026, 6:24pm UTC](https://forum.inductiveautomation.com/t/mcp-module-persistent-405-error/117021/2 "2026-09-10T18:24:35Z")
ok my issue has been resolved. Paul mention creating a security level APIAccess below the Athenticated sercurity level. I had mine under Authenticated/Roles/APIAcess and would get a 403 error. Here is the change I made Authenticated/APIAccess and now no errors. After this change I was able to go to the API Key and update the security Level to use APIAccess.