Hey 
I tested the endpoint from inside the Gateway container/network namespace as suggested, using a separate curl container with --network container:standard-gateway-1 and calling localhost:8088 directly.
The result is still the exact same 403 Forbidden, so this appears to rule out the Docker host port mapping or anything sitting in front of the Gateway.
Since theres now also another independent reproduction in this thread (thanks @lai.yujing) on a native Windows 11 Gateway with no Docker or reverse proxy involved, showing the same blanket 403 on /data/mcp/* while the same API token works correctly against /data/api/v1/gateway-info. --- doesn't it seem less likely that this is environment/proxy related?
Regarding handler registration, I haven't found an explicit "handler registered" log entry. However, before creating my testing-public server config, a request to:
/data/mcp/testing-public
returned the MCP-specific response:
{ "message": "MCP server not found: testing-public", "url": "/data/mcp/testing-public", "status": "404" }
After creating that server config, the same route returns 403 instead. Both testing and testing-public also appear under MCP Server Config in Platform Overview.
That seems to indicate that the /data/mcp/* handler is registered and processing the route, although I haven't found a specific log entry confirming the handler registration itself.
I also searched the Gateway logs for McpGatewayHook, HandlerFactory, com.inductiveautomation.mcp, and NullPointerException; there are no handler/NPE errors, only the normal MCP module startup entry.
If there is a specific logger/category I can enable to see the permission check or route registration in more detail, I’m happy to test that. 
