AI agents write more and more of our code, and many bugs only show up in the running system. On the BEAM that system can be inspected while it runs: distribution, process introspection, built-in tracing, supervisors that keep their restart history, hot code loading. otp_debug_mcp hands that to an agent such as Claude Code, through purpose-built tools with guardrails rather than a raw shell.
It’s an MCP server, written in Elixir, that connects to a running node as a hidden node. Nothing is installed on the target, and recon is loaded into memory for the session. The tools:
- diagnose: health checks ranked worst first: message queues, crash loops (including ones that stay just under the restart limit), binary leaks, memory, atoms, schedulers.
- process_info, supervision_tree, snapshot: drill down, and diff snapshots to tell a real leak from a busy moment.
- trace_calls: tracing with hard limits on events, duration and call rate. On OTP 27+ it runs in its own trace session.
- profile: own time, call counts and memory allocated per function.
- cluster: compares every node to find the odd one out.
- load_module: hot-loads a fixed .beam onto the node, only after you approve that load in a dialog.
It works with Elixir, Erlang, Gleam and LFE nodes, Mix releases, TLS distribution, Docker containers and Kubernetes pods. Releases bundle their own runtime, and there’s a Docker image.
Example: pointed at a demo node with “payments fail now and then”, the agent found the crash loop’s cause, file and line from one diagnose call.
It isn’t battle-tested yet. It’s been tested against demo nodes, in CI on OTP 26–28, on a second machine, and on a local Kubernetes cluster, but not on real production systems. Try it on staging first, and remember that tool output goes to your AI provider.
I’d really like feedback: what’s missing for your systems, what goes wrong, and what you’d never let an agent do on a node.