Skip to main content
Glama
theSharque
by theSharque

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
JAVA_HOMENoPath to JDK root if not automatically found

Capabilities

Features and capabilities supported by this server

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_java_processesA

Lists all running Java processes on the machine. Returns an array of objects with pid, mainClass, and args. Use this tool first to discover the target process PID before calling start_profiling or analyze_threads. Data is obtained via jps -l -m.

start_profilingA

Starts JFR on the target PID. Rotates recordings (old_profile.jfr ← new_profile.jfr). Default preset is profile. Optional preset or settingsFile (.jfc, cwd-relative or absolute)—mutually exclusive. Builtin presets may omit socket/I/O/native/locks; use a custom .jfc for jdk.SocketRead/Write, FileRead/Write, JavaMonitorBlocked, jdk.ThreadPark, NativeMethodSample. Then list_jfr_recordings and stop_profiling.

stop_profilingA

Stops an active JFR recording and saves it to recordings/new_profile.jfr. Use recordings/new_profile.jfr for current data, recordings/old_profile.jfr for previous (before/after comparison).

check_deadlockA

Checks for Java-level deadlocks in the specified process. Parses jcmd Thread.print output and returns structured JSON: which threads are involved, what locks they hold/wait for, and the deadlock cycle. Use for automated analysis and reports.

list_jfr_recordingsA

Lists active and recent JFR recordings for a Java process (jcmd JFR.check). Returns recording id, duration, state (running/stopped), and filename. Use before stop_profiling to get the correct recordingId.

analyze_threadsA

Thread dump (jstack -l). Default: plain text. Set structured=true for JSON lock-wait chains (live snapshot). Historical contention: profile_jfr_locks. Deadlock cycle: check_deadlock.

heap_histogramA

Static class histogram (jcmd GC.class_histogram). For live growth over time use heap_live_histogram_diff instead.

heap_live_histogram_diffA

Two GC.class_histogram snapshots spaced by intervalSeconds; returns classes whose instance count grew most. Use first in memory-leak workflow; then profile_memory and heap_dump (MAT path-to-GC-roots). Each snapshot walks the heap and may pause the app.

heap_dumpA

Creates .hprof for Eclipse MAT / VisualVM. After heap_live_histogram_diff picks a growing class, use MAT Path to GC Roots (exclude weak/soft). Saved to recordings/heap_dump.hprof. Warning: large file.

heap_infoA

Brief heap usage summary: capacities, used, committed regions. Quick snapshot without full dump.

vm_infoA

JVM information: uptime, version, and flags. Useful for environment verification.

trace_methodA

Builds a call tree for a specific method from a .jfr file. Filters ExecutionSample events to find stack traces containing the given class and method, then aggregates call paths. Use when you want to see who calls a particular method and from where. Limitation: JFR sampling (~10 ms) may miss very fast methods.

parse_jfr_summaryA

Parses a .jfr file and returns a structured summary: top methods by CPU samples, GC statistics, thread allocation stats, and anomaly hints (e.g. high GC count). Use for a quick high-level overview of the recording before diving into specific profiles.

profile_memoryA

JFR memory profile: top allocators by bytes/count, allocation stacks, OldObjectSample by class (allocation site, not GC roots). Pair with heap_live_histogram_diff, gc_efficiency, heap_dump+MAT. Requires profile preset recording.

gc_efficiencyA

GC efficiency from .jfr: pause time vs freed bytes per collector/cause. Use after stop_profiling; complements profile_memory and heap_info. Not a general JFR summary (see parse_jfr_summary).

profile_timeA

CPU time (bottleneck) profile from a .jfr file. Uses bottom-up aggregation: each method is counted in every sample where it appears in the stack, including time spent in callees. Returns methods consuming the most CPU time. Use when the goal is to find performance bottlenecks and slow code paths.

profile_frequencyA

Call frequency profile from a .jfr file. Counts methods that appear at the leaf (top) of the stack in ExecutionSample events — i.e. methods that were actively executing when sampled. Returns the most frequently sampled methods (exclusive, not cumulative). Use when looking for hot spots or the most often executed code paths.

profile_jfr_networkA

Summarize JDK socket I/O from a .jfr (jdk.SocketRead, jdk.SocketWrite): event counts, total bytes read/written where available, top endpoints (host:port / address), and cumulative stack hotspots. Recording must include those events (custom .jfc or preset that enables them). If emptyEvents, use start_profiling settingsFile.

profile_jfr_file_ioA

Summarize file read/write events (jdk.FileRead, jdk.FileWrite): counts, bytes, top paths, stack hotspots. Events must exist in recording; configure via start_profiling preset or settingsFile (.jfc).

profile_jfr_locksA

Lock contention from JFR: synchronized monitors (JavaMonitorBlocked) and j.u.c parking (ThreadPark). Live wait chains: analyze_threads structured=true. Deadlocks: check_deadlock. Enable events via custom .jfc if missing.

profile_jfr_nativeB

CPU-style cumulative hotspots from jdk.NativeMethodSample stacks. Recording must enable NativeMethodSample (often requires custom .jfc).

native_memory_summaryA

jcmd VM.native_memory summary=true. Requires JVM started with -XX:NativeMemoryTracking=summary or detail; otherwise explains how to enable.

gc_class_statsA

jcmd GC.class_stats (class loader / metaspace style stats where supported—often JDK 21+). On older JDK returns error hint; use heap_info or heap_histogram instead.

gc_finalizer_infoC

jcmd GC.finalizer_info — finalizer queue diagnostics for the live process.

compiler_codecacheC

jcmd Compiler.codecache — code heap usage and related JVM output.

compiler_queueC

jcmd Compiler.queue — methods queued for JIT compilation.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/theSharque/mcp-jperf'

If you have feedback or need assistance with the MCP directory API, please join our Discord server