Prepare a profiling session by retrieving a JVM parameter to be added to a Java process call to record performance data with stack traces for the following subsystems: cpu, jdbc, jpa, mongo_db, cassandra, http_server, http_client, ws, jndi, jms, kafka_consumer, rmi, grpc, ai, process. The result is a JSON object containing a 'jvmParameter' to be added (quoted) to the Java process at startup. Add it verbatim and do not create or modify any files; the configuration is already set up for you. If the result contains 'additionalJvmParameters' (discovery of injected custom probes), add each element as a separate VM argument as well. Keep this MCP server running and run the Java process. It waits for the server to connect before application startup. During recording, attached_action can perform live actions. The recording is saved automatically when the JVM terminates, after the optional maximum duration, or when check_status is called with 'stopRecording: true'. Then call check_status to access the data - do not load the saved snapshot file yourself. Saving disconnects from the JVM. Use attach with its PID for another recording if it is still running.

Load an existing .jps, .hprof, or .jfr file for analysis. You must call check_status to check the loading progress and - after this returns 'data_ready' - retrieve data with the query tool. To compare two performance snapshots, load both in a single call: set filePath to the run to analyze and baselineFilePath to the baseline; the differences are then reported in the hotspots and call trees of that run.

Attach to a running JVM by PID or to a JVM inside a Docker container. Records performance data for the following subsystems: cpu, jdbc, jpa, mongo_db, cassandra, http_server, http_client, ws, jndi, jms, kafka_consumer, rmi, grpc, ai, process until check_status is called with 'stopRecording: true', or allocation data when "recordingConfig": {"recordAllocations": true} is passed. Pass "recordingConfig": {"recordMonitors": true} to additionally record monitor and lock events. You can use list_jvms to discover JVMs.

Check the status of a profiling session and discover which subsystems were recorded. Can be used to stop recording. When the data is ready provides information about the recorded subsystems (e.g. cpu, jdbc, http_client).

Query a performance or heap dataset with a jq expression and return the result. The dataset is materialized lazily and cached per session. Each query is independent, there is no current object: builtins take explicit ids bound from earlier results, e.g. .instances[0].id as $id | {value: preview($id), keptAliveBy: pathToRoot($id).paths[0].path | map(.class)}

Dump the heap of a locally running JVM or of a JVM inside a Docker container and load it for analysis. If allocation data is recorded for the JVM, the heap dump includes per-object allocation data. A recording session delivers a single heap dump, for a later dump attach again. You must call check_status to check the loading progress and - after this returns 'data_ready' - retrieve data with the query tool. You can use list_jvms to discover JVMs.

Perform a point-in-time action on the connected JVM: thread and monitor dumps, heap marking and heap dumps, MBean snapshots, and starting or stopping subsystem recording. Requires a recording session started with attach or prepare_profiling. The action names and parameters are the same as for the actions of recordingConfig.triggers.

List locally running JVMs or JVMs running in a Docker container with their command line and PID. Use the information to call attach or create_heap_dump.