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

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

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

TDQS

A3.8/5.0

Scored across 26 tools

Disambiguation5/5

Each tool targets a specific aspect of Java performance profiling (thread analysis, deadlock, GC, heap, JFR, various profiles). Descriptions clearly differentiate them, even where functionality might seem similar (e.g., analyze_threads vs check_deadlock, heap_histogram vs heap_live_histogram_diff).

Naming Consistency5/5

All tool names use consistent snake_case with a verb_noun pattern (e.g., list_java_processes, start_profiling, profile_time). The naming is predictable and adheres to a single convention throughout.

Tool Count4/5

26 tools is slightly above the typical 3-15 range but well-justified for the comprehensive domain of Java performance analysis. Each tool serves a distinct purpose, and the count reflects the complexity of the subject without being excessive.

Completeness5/5

The toolset covers the full lifecycle of performance profiling: discovery, starting/stopping recordings, analyzing CPU, memory, I/O, locks, network, and interpreting results. There are no obvious gaps for local Java process analysis, making it a complete toolkit.

Maintenance

ActivityInactive
ResponsivenessNo issues