The expansion pattern is what makes it work in a conversation: hotspots come back with ids, and expanding one returns its back trace or children, so the model can walk down a call tree the way a person would click through it. Attaching to a JVM inside a Docker container is supported directly, which is where most of the awkwardness usually is.
JProfiler's own MCP server. It starts a profiling session, attaches to a live JVM or loads an existing snapshot, and hands the recorded data back as structured hotspots and heap summaries an assistant can drill into — CPU, JDBC, JPA, HTTP server and client, and MongoDB.
- prepare_profiling — the JVM parameter to add to a Java process so it records stack traces for the CPU, JDBC, JPA, HTTP server, HTTP client and MongoDB subsystems
- attach — attach to a running JVM by PID, or one inside a Docker container, and record until you stop it
- load_snapshot — open an existing .jps, .hprof or .jfr file for analysis
- check_status — the session's progress, which subsystems were recorded, and the way to stop recording; data is ready when it reports so
- get_performance_hotspots and expand_performance_hotspot — the top hotspots with timing and expansion ids, then the back trace of one or the children of a call tree node
- create_heap_dump and get_heap_data — dump a local or containerised JVM's heap to HPROF and load it, then read biggest objects, retained class lists and class histograms
- list_jvms — the local or containerised JVMs with their command lines and PIDs, which is where attach and create_heap_dump start
A JProfiler license — on first use you can start a free 10-day evaluation or enter an existing key. Clients run npx -y @ej-technologies/jprofiler-mcp over stdio. Optional startup arguments narrow what is exposed: --filter takes tool name patterns, --subsystems limits which subsystems are enabled, and --max-depth caps call tree expansion.
One command — npx -y @ej-technologies/jprofiler-mcp