MCP Module - Persistent 405 Error

Ignition Early Access
1

Continuing the discussion from MCP Module Early Access:

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 <url> --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:

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 <key-name>:<secret> (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 > <key-name>) 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/<server-config-name> 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?