javaperf
NPM · JAVAPERF
Java profiling MCP via jcmd/jfr/jps. Diagnose performance, analyze threads, inspect JFR recordings.
Available components
Last scanned (14 hours ago)
Scores higher than 97% of npm servers
Category Monitoring and Observability
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security98
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 30 of 92 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency97
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to theSharque/mcp-jperf). View diagnostics → Pass
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 38 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability79
- AI-judged instruction clarity (excellent).Pass
- Tool/resource definitions use about 2587 tokens (~99/item across 26 items; 26 tools + 0 resources), lean.Pass
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage93
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 78% of tool parameters carry a description.Partial
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 26 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 26 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Checks we ran (16)
- Malware scan
- Known CVEs
- Install scripts
- Dependency health
- Source repository
- Provenance
- License
- Maintenance
- Security disclosure
- Schema quality
- Stability
- Tool coverage
- Injection markers
- Destructive annotations
- Judged manipulation
- MCP protocol
Does not apply to this package (2)
- Endpoint SecurityScored on hosted endpoints only. A package has no live endpoint of its own for us to probe.
- Transport & ReachabilityScored on hosted endpoints only. A package has no live endpoint of its own for us to probe.
The score does not measure everything. What the score does not measure →
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 4 Nov 26 0
- Security disclosure: unverified → fail ▼ functional
- 3 Nov 26 0
- Stability: 0.97 → pass security
- Security disclosure: fail → unverified ▼ functional
- 2 Nov 26 0
- Stability: pass → 0.97 functional
- 1 Nov 26 0
- Security disclosure: unverified → fail ▼ functional
- 30 Oct 26 0
- Security disclosure: fail → unverified ▼ functional
- 21 Oct 26 0
- Stability: 0.97 → pass security
- 20 Oct 26 0
- Stability: pass → 0.97 functional
- 17 Oct 26 +2
- Stability: 0.83 → pass security
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Analysed npm/javaperf@1.4.2
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | npm |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | theSharque/mcp-jperf |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/theSharque/mcp-jperf/.github/workflows/publish.yml@refs/heads/main |
| Rekor log index | 2976690990 |
| Predicate type | SLSA build provenance https://slsa.dev/provenance/v1 |
| Subject digest | sha512:84d83e1a4aa1e1a43fb9b4cfd9c0942f885f8b00cb6ea35032cfdc821d2059f11c9de4539fc95252ddba5aa1a557e0546191f4e00c0e14f5a7d6c9d4d |
Background: How many MCP packages publish verified provenance →
Dependencies 92 packages
| Packages resolved | 92 |
|---|---|
| Stale | 30 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
analyze_threads ~124
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.
| Name | Type | Req | Description |
|---|---|---|---|
| pid | integer | yes | Process ID of the Java application. Get this from list_java_processes. |
| structured | boolean | – | Return structured JSON with lockWaitChains instead of plain-text dump. Default: false. |
| topN | integer | – | Maximum number of threads to include in the output. Default: 10. Increase for applications with many threads. |
No output schema declared.
No examples provided.
check_deadlock ~78
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.
| Name | Type | Req | Description |
|---|---|---|---|
| pid | integer | yes | Process ID of the Java application. Get this from list_java_processes. |
No output schema declared.
No examples provided.
compiler_codecache ~30
jcmd Compiler.codecache — code heap usage and related JVM output.
| Name | Type | Req | Description |
|---|---|---|---|
| pid | integer | yes | – |
No output schema declared.
No examples provided.
compiler_queue ~27
jcmd Compiler.queue — methods queued for JIT compilation.
| Name | Type | Req | Description |
|---|---|---|---|
| pid | integer | yes | – |
No output schema declared.
No examples provided.
gc_class_stats ~56
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.
| Name | Type | Req | Description |
|---|---|---|---|
| pid | integer | yes | – |
No output schema declared.
No examples provided.
gc_efficiency ~68
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).
| Name | Type | Req | Description |
|---|---|---|---|
| filepath | string | – | – |
| topN | integer | – | – |
No output schema declared.
No examples provided.
gc_finalizer_info ~33
jcmd GC.finalizer_info — finalizer queue diagnostics for the live process.
| Name | Type | Req | Description |
|---|---|---|---|
| pid | integer | yes | – |
No output schema declared.
No examples provided.
heap_dump ~77
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.
| Name | Type | Req | Description |
|---|---|---|---|
| pid | integer | yes | Process ID of the Java application. Get this from list_java_processes. |
No output schema declared.
No examples provided.
heap_histogram ~94
Static class histogram (jcmd GC.class_histogram). For live growth over time use heap_live_histogram_diff instead.
| Name | Type | Req | Description |
|---|---|---|---|
| all | boolean | – | Include unreachable objects. Triggers full GC and may cause application pause. |
| pid | integer | yes | Process ID of the Java application. Get this from list_java_processes. |
| topN | integer | – | Maximum number of top classes to return. Default: 20. |
No output schema declared.
No examples provided.
heap_info ~47
Brief heap usage summary: capacities, used, committed regions. Quick snapshot without full dump.
| Name | Type | Req | Description |
|---|---|---|---|
| pid | integer | yes | Process ID of the Java application. Get this from list_java_processes. |
No output schema declared.
No examples provided.
heap_live_histogram_diff ~145
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.
| Name | Type | Req | Description |
|---|---|---|---|
| all | boolean | – | Include unreachable objects (-all). Triggers full GC and may pause the app. |
| intervalSeconds | integer | – | Seconds between baseline and snapshot histograms. Default: 5. |
| minInstanceDelta | integer | – | Ignore classes with instance growth below this threshold. |
| pid | integer | yes | Process ID from list_java_processes. |
| topN | integer | – | – |
No output schema declared.
No examples provided.
list_java_processes ~96
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.
| Name | Type | Req | Description |
|---|---|---|---|
| topN | integer | – | Maximum number of processes to return in the list. Default: 10. Use higher values if many Java processes are running. |
No output schema declared.
No examples provided.
list_jfr_recordings ~78
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.
| Name | Type | Req | Description |
|---|---|---|---|
| pid | integer | yes | Process ID of the Java application. Get this from list_java_processes. |
No output schema declared.
No examples provided.
native_memory_summary ~45
jcmd VM.native_memory summary=true. Requires JVM started with -XX:NativeMemoryTracking=summary or detail; otherwise explains how to enable.
| Name | Type | Req | Description |
|---|---|---|---|
| pid | integer | yes | – |
No output schema declared.
No examples provided.
parse_jfr_summary ~172
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.
| Name | Type | Req | Description |
|---|---|---|---|
| events | array | – | Optional list of JFR event types to include. Default: jdk.ExecutionSample, jdk.GarbageCollection, jdk.JavaThreadStatistics, jdk.ThreadAllocationStatistics. |
| filepath | string | – | Path to .jfr file. Shortcuts: 'new_profile' (current, default) or 'old_profile' (previous). Or full path e.g. recordings/new_profile.jfr. |
| topN | integer | – | Maximum number of top methods to include in the summary. Default: 10. |
No output schema declared.
No examples provided.
profile_frequency ~141
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.
| Name | Type | Req | Description |
|---|---|---|---|
| filepath | string | – | Path to .jfr file. Shortcuts: 'new_profile' (current, default) or 'old_profile' (previous). Or full path e.g. recordings/new_profile.jfr. |
| topN | integer | – | Maximum number of top methods by call frequency to return. Default: 10. |
No output schema declared.
No examples provided.
profile_jfr_file_io ~93
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).
| Name | Type | Req | Description |
|---|---|---|---|
| filepath | string | – | Path to .jfr. Shortcuts: new_profile, old_profile. |
| topN | integer | – | Top N paths/methods. |
No output schema declared.
No examples provided.
profile_jfr_locks ~74
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.
| Name | Type | Req | Description |
|---|---|---|---|
| filepath | string | – | – |
| topN | integer | – | – |
No output schema declared.
No examples provided.
profile_jfr_native ~51
CPU-style cumulative hotspots from jdk.NativeMethodSample stacks. Recording must enable NativeMethodSample (often requires custom .jfc).
| Name | Type | Req | Description |
|---|---|---|---|
| filepath | string | – | – |
| topN | integer | – | – |
No output schema declared.
No examples provided.
profile_jfr_network ~124
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.
| Name | Type | Req | Description |
|---|---|---|---|
| filepath | string | – | Path to .jfr. Shortcuts: new_profile, old_profile, or absolute path. |
| topN | integer | – | Top N endpoints and methods. |
No output schema declared.
No examples provided.
profile_memory ~142
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.
| Name | Type | Req | Description |
|---|---|---|---|
| filepath | string | – | Path to .jfr file. Shortcuts: 'new_profile' (current, default) or 'old_profile' (previous). Or full path e.g. recordings/new_profile.jfr. |
| sortBy | string | – | Primary ranking for topAllocators. Default: bytes. |
| topN | integer | – | Maximum number of top allocators to return. Default: 10. |
No output schema declared.
No examples provided.
profile_time ~141
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.
| Name | Type | Req | Description |
|---|---|---|---|
| filepath | string | – | Path to .jfr file. Shortcuts: 'new_profile' (current, default) or 'old_profile' (previous). Or full path e.g. recordings/new_profile.jfr. |
| topN | integer | – | Maximum number of top methods by CPU time to return. Default: 10. |
No output schema declared.
No examples provided.
start_profiling ~256
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.
| Name | Type | Req | Description |
|---|---|---|---|
| duration | integer | yes | Recording duration in seconds. Typical: 10–60 quick, 300+ under load. |
| memorysize | string | – | JFR buffer size, e.g. 20M. Default JVM buffer applies if omitted. |
| pid | integer | yes | Process ID of the Java application. Use list_java_processes. |
| preset | string | – | Builtin settings name (e.g. profile, default). Effective default when omitted is profile. Mutually exclusive with settingsFile. |
| settingsFile | string | – | Path to .jfc file (cwd-relative or absolute). Mutually exclusive with preset. |
| stackdepth | integer | – | Stack depth for JFR events. Default 128. |
No output schema declared.
No examples provided.
stop_profiling ~115
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).
| Name | Type | Req | Description |
|---|---|---|---|
| pid | integer | yes | Process ID of the Java process that has the active recording. Must match the pid used in start_profiling. |
| recordingId | string | yes | ID of the recording to stop. This is the recordingId returned by start_profiling (e.g. '1' or '2'). |
No output schema declared.
No examples provided.
trace_method ~236
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.
| Name | Type | Req | Description |
|---|---|---|---|
| className | string | yes | Fully qualified class name (e.g. com.example.MyService) or a substring to match. Used to filter stack frames. |
| events | array | – | Optional list of JFR event types to parse. Default: jdk.ExecutionSample. Advanced users can specify other event types. |
| filepath | string | – | Path to .jfr file. Shortcuts: 'new_profile' (current, default) or 'old_profile' (previous). Or full path e.g. recordings/new_profile.jfr. |
| methodName | string | yes | Method name to search for (e.g. processRequest). Matches the method in the stack trace. |
| topN | integer | – | Maximum number of call paths (branches) to return in the call tree. Default: 10. |
No output schema declared.
No examples provided.
vm_info ~44
JVM information: uptime, version, and flags. Useful for environment verification.
| Name | Type | Req | Description |
|---|---|---|---|
| pid | integer | yes | Process ID of the Java application. Get this from list_java_processes. |
No output schema declared.
No examples provided.
How do I install the javaperf MCP server?
javaperf runs locally as an npm package, launched with npx -y javaperf. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · javaperf
claude mcp add thesharque-javaperf -- npx -y javaperf
What is the javaperf MCP server?
javaperf is an MCP server listed in the public MCP registry as io.github.theSharque/javaperf. Java profiling MCP via jcmd/jfr/jps. Diagnose performance, analyze threads, inspect JFR recordings. This page covers its npm package (javaperf).
Is the javaperf MCP server safe to use?
javaperf scores 94 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the javaperf MCP server expose?
javaperf exposes 26 tools: list_java_processes, start_profiling, stop_profiling, check_deadlock, list_jfr_recordings, and 21 more. Their descriptions and schemas cost roughly 2,587 tokens of context every time the server is loaded.
Is the javaperf MCP server still maintained?
javaperf is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the javaperf MCP server under?
javaperf declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.
What did VerifyMCP test on the javaperf MCP server?
VerifyMCP ran 16 checks on javaperf, covering Malware scan, Known CVEs, Install scripts, Dependency health and 12 more. Endpoint Security and Transport & Reachability do not apply to an npm package, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.