Loading ToolBench
MCP server for JVM diagnostics — analyze thread dumps, detect deadlocks, parse GC logs, and get JVM tuning recommendations
Server has 7 tools with complete schemas and descriptions. Naming follows verb_noun pattern (analyze_*, generate_*, diagnose_*, compare_*). Descriptions are detailed (150-300 chars) and explain WHAT the tool does and WHEN to use it. However, parameter descriptions lack actionable constraints (no enums, ranges, or format specs). Error handling is minimal, tools catch exceptions but return generic error text without recovery guidance. Output schemas are not formally documented; responses are free-form markdown text rather than structured objects. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Missing pagination for potentially large results (e.g., thread dump analysis could return hundreds of threads).
Parse a JVM GC log and analyze garbage collection patterns, pause times, allocation rates, and memory pressure. Supports G1, ZGC, Parallel, Serial, and Shenandoah GC formats.
Parse jmap -histo output and detect memory leak candidates, object creation hotspots, classloader leaks, and heap composition issues.
Parse JFR (Java Flight Recorder) summary output and detect performance hotspots, GC pressure, allocation patterns, lock contention, and thread churn.
Parse a JVM thread dump (jstack output) and analyze thread states, detect deadlocks, identify lock contention hotspots, and find thread starvation patterns. Handles both platform threads and virtual threads (Java 21+). Note: deadlock detection covers synchronized monitor locks only — java.util.concurrent.locks.ReentrantLock and other j.u.c lock types do not expose their waiters in thread dump lock info and will not be detected.
Compare two jmap -histo snapshots taken at different times to detect memory growth patterns, leak candidates, and new allocations. Captures what is growing between snapshots.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk classifications. generate_report is marked WRITE but tool definition lacks destructiveHint annotation.
Output schemas not formally documented. All tools return free-form markdown text in a generic {content: [{type: 'text', text: '...'}]} wrapper. LLMs cannot parse structured fields or plan downstream tool calls. No pagination or result limits documented despite potentially large outputs (e.g., thread dump with 1000+ threads).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Unified diagnosis from thread dump + GC log. Combines thread state analysis, deadlock detection, contention hotspots, and GC pressure into a single comprehensive report with prioritized recommendations.
Generate an exportable diagnostic report (HTML + PDF) from JVM diagnostic data. Requires a valid Pro license key.
Parameter descriptions lack actionable constraints. 'thread_dump' param says 'The full thread dump text' but does not specify format, size limits, or expected structure. 'license_key' has no validation rules or format hints. No enums, ranges, or regex patterns.
Error handling is generic. Tools catch exceptions and return 'Error analyzing thread dump: <message>' without recovery guidance. No error classification (retryable vs user-fixable vs fatal). LLM cannot determine next action.
generate_report tool accepts license_key as a parameter. Credentials should never be tool parameters, they leak into logs and traces. Use server-side secret injection via environment variables instead.