What can you do with this server?

Heap Seance is an MCP server and CLI toolkit for Java memory leak investigation, offering a two-stage escalation model with structured forensic workflows. Two Main Workflows: * /leak-scan — Conservative mode: takes 3 class histogram snapshots and GC pressure analysis, returning a verdict with confidence level and recommended next steps * /leak-deep — Full forensics mode: escalates from /leak-scan by adding JFR recordings, heap dumps, MAT leak analysis, and async-profiler allocation profiling to produce a root holder hypothesis and remediation suggestions Individual Capabilities: * Discover JVM processes (java_list_processes): List all running JVMs via jcmd -l to identify investigation targets * Capture class histograms (java_class_histogram): Snapshot live object counts/sizes per class to detect monotonically growing types * Monitor GC pressure (java_gc_snapshot): Sample jstat -gcutil over time to assess old-gen usage and GC strain * Start JFR recordings (java_jfr_start): Capture Java Flight Recorder data with configurable duration/profile * Summarize JFR files (java_jfr_summary): Parse .jfr files to extract event types and counts * Generate heap dumps (java_heap_dump): Produce .hprof files for offline memory forensics * Run MAT analysis (java_mat_suspects): Execute Eclipse MAT on heap dumps to identify leak suspects, dominator trees, and retention chains * Profile allocations (java_async_alloc_profile): Generate async-profiler flame graphs showing which call paths drive the most allocations All tools return a unified schema including status, evidence, metrics, a confidence level (none/low/medium/high), next recommended action, and paths to saved artifacts (.jfr, .hprof, MAT reports). Supports Java 8+ targets (full support for Java 8; additional JFR features for Java 9+), integrates with Claude Code via slash commands, and can run standalone via CLI.

heap-seance

by SegfaultSorcerer

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

How It Works

Heap Seance follows a two-stage escalation model. No deep forensics unless the evidence demands it.

 /leak-scan                          /leak-deep
     |                                   |
     v                                   v
  3x class histogram               (all of scan, plus)
  + GC pressure snapshot            JFR recording
     |                              heap dump
     v                              MAT leak suspects
  monotonic growth?                 async-profiler alloc profile
  old-gen pressure?                     |
     |                                  v
     +--- both true? -----> auto-escalate to deep
     |
     +--- otherwise ------> verdict + next steps

Confidence is earned, not assumed. high requires at least two independent strong signals. A single growing class is watch. Growth plus GC pressure is suspicious. Add a MAT dominator or JFR correlation and you get probable_memory_leak.

Related MCP server: javaperf

Quick Start

Requires uv, Python 3.10+, and a JDK 17+ for tooling (the target app can run any Java version).

1. Clone

git clone https://github.com/your-org/heap-seance.git

2. Add `.mcp.json` to your Java project

In the project you want to investigate, create a .mcp.json:

{
  "mcpServers": {
    "heap-seance": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/heap-seance", "python", "-m", "heap_seance_mcp.server"],
      "env": {
        "JAVA_HOME": "/path/to/jdk-17",
        "MAT_BIN": "/path/to/ParseHeapDump.sh",
        "ASYNC_PROFILER_BIN": "/path/to/asprof"
      }
    }
  }
}

--directory points to where you cloned Heap Seance. uv run handles the virtual environment and dependencies automatically. ASYNC_PROFILER_BIN is optional — if missing, deep mode continues with JFR + MAT.

3. Copy the Claude Code commands

Copy the .claude/commands/ folder into your Java project so the /leak-scan and /leak-deep slash commands are available:

cp -r /path/to/heap-seance/.claude/commands/ .claude/commands/

4. Run

/leak-scan my-service        # conservative scan
/leak-deep 12345             # full forensics by PID

Heap Seance resolves the target process, collects evidence, and returns a structured verdict.

MCP Tools

Tool	What it does
`java_list_processes()`	Discover running JVMs via `jcmd -l`
`java_class_histogram(pid)`	Snapshot live object counts per class
`java_gc_snapshot(pid)`	Sample `jstat -gcutil` over time
`java_jfr_start(pid)`	Capture a JFR recording
`java_jfr_summary(jfr_file)`	Summarize JFR event types and counts
`java_heap_dump(pid)`	Full heap dump (`.hprof`)
`java_mat_suspects(heap_dump)`	Run MAT leak suspects analysis
`java_async_alloc_profile(pid)`	Allocation flame graph via async-profiler

Every tool returns the same unified schema:

{
  "status": "ok | warn | error",
  "evidence": ["..."],
  "metrics": {},
  "confidence": "none | low | medium | high",
  "next_recommended_action": "...",
  "raw_artifact_path": "..."
}

Investigation Workflow

Start your app and let it initialize fully.
/leak-scan <name-or-pid> — takes the first histogram snapshot.
Exercise the suspect behavior — the scan prompts you between each of the 3 histogram samples to perform the action you suspect is leaking (open/close views, send requests, repeat workflows). This is critical — without load between samples, leaks stay invisible.
Read the verdict. Focus on Confidence, Key Evidence, Suspect Types.
/leak-deep <name-or-pid> if the scan flags growth, or if you want full forensics regardless.
Fix and re-scan. Bounded caches, weak refs, listener cleanup — then /leak-scan again to confirm the signal drops.
Keep artifacts. .jfr, .hprof, and MAT reports are saved for team review.

What you get back

/leak-scan returns: Verdict, Confidence, Key Evidence, Suspect Types, Artifacts, Next Steps.

/leak-deep goes further: Verdict, Confidence, Root Holder Hypothesis (who retains the growing objects and via which field/chain), Supporting Evidence, Artifacts, Remediation Hypotheses (concrete fix suggestions), Verification Plan.

Confidence ladder

Confidence	What it means	Signals required
`none`	No leak evidence	—
`low`	Weak growth, no GC pressure	histogram only
`medium`	Growth + GC is losing	histogram + GC pressure
`high`	Probable leak, corroborated	histogram + GC + MAT/JFR

Prerequisites

Tooling JDK (required):

JDK 17+ for jcmd, jmap, jstat — set via JAVA_HOME in .mcp.json
The target application can run any Java version (including Java 8)

Deep forensics (for /leak-deep):

Eclipse MAT CLI (ParseHeapDump.sh / .bat) — required for deep mode
async-profiler — optional tie-breaker

Optional tools:

jfr CLI — used for JFR summary if available, falls back to jcmd JFR.view otherwise. JFR is skipped entirely for Java 8 targets (incompatible format).

Check your setup:

./scripts/check_prereqs.sh          # macOS / Linux
scripts\check_prereqs.bat           # Windows

Environment overrides

Set these in your .mcp.json env block (recommended) or as shell variables:

Variable	Required	Description
`JAVA_HOME`	recommended	JDK 17+ installation path — `$JAVA_HOME/bin` is searched first for `jcmd`, `jmap`, `jstat`, `jfr`. Also used to launch MAT with the correct Java version.
`MAT_BIN`	for deep mode	Path to `ParseHeapDump.sh` (macOS/Linux) or `.bat` (Windows)
`ASYNC_PROFILER_BIN`	optional	Path to async-profiler binary — tie-breaker evidence, deep mode works without it
`HEAP_SEANCE_ARTIFACT_DIR`	optional	Where `.jfr`, `.hprof`, and reports are saved (default: system temp dir)
`MCP_TRANSPORT`	optional	Transport protocol: `stdio` (default), `sse`, or `streamable-http`
`MCP_HOST`	optional	Bind address for SSE/HTTP transport (default: `0.0.0.0`)
`MCP_PORT`	optional	Port for SSE/HTTP transport (default: `8000`)

CLI flags --sse and --streamable-http can be used instead of MCP_TRANSPORT.

See .mcp.json.example for a full config template.

Compatibility notes

Java 8 targets: histogram + GC + MAT work fully. JFR is skipped (v0.9 format incompatible with modern tools).
Windows: MAT works via ParseHeapDump.bat. async-profiler is optional — if missing, deep mode continues with JFR + MAT. Locale-specific decimal separators (comma vs dot) in jstat output are handled automatically.
MAT + JAVA_HOME: MAT is launched with the JDK from JAVA_HOME, so it works even if the system default Java is too old for MAT.

CLI Usage (without Claude Code)

uv run heap-seance --mode scan --match your-app
uv run heap-seance --mode deep --pid 12345 --output json

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

python3 -m venv .venv
source .venv/bin/activate       # Windows: .\.venv\Scripts\Activate.ps1
pip install -e .

heap-seance --mode scan --match your-app

Tests

python3 -m unittest discover -s tests -p "test_*.py"

Example Java scenarios for validation live in examples/java-scenarios/ — a real leak, a bounded cache (no leak), and a burst allocator (no leak).

Contributing

Contributions welcome! See CONTRIBUTING.md for guidelines on adding tools, signals, and skills.

License

This project is dual-licensed under either of

at your option.

Available Tools

8 tools

java_async_alloc_profileD

ParametersJSON Schema

Name	Required	Description	Default
`pid`	Yes
`duration_s`	No
`out_file`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

java_class_histogramD

ParametersJSON Schema

Name	Required	Description	Default
`pid`	Yes
`live_only`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

java_gc_snapshotD

ParametersJSON Schema

Name	Required	Description	Default
`pid`	Yes
`interval_s`	No
`samples`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

java_heap_dumpD

ParametersJSON Schema

Name	Required	Description	Default
`pid`	Yes
`live_only`	No
`out_file`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

java_jfr_startD

ParametersJSON Schema

Name	Required	Default
`pid`	Yes
`profile`	No	profile
`duration_s`	No
`out_file`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

java_jfr_summaryD

ParametersJSON Schema

Name	Required	Description	Default
`jfr_file`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

java_list_processesD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

java_mat_suspectsD

ParametersJSON Schema

Name	Required	Description	Default
`heap_dump_file`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv1.0.0Mar 15, 2026
- First observedjava_async_alloc_profile
- First observedjava_class_histogram
- First observedjava_gc_snapshot
- First observedjava_heap_dump
- First observedjava_jfr_start
- First observedjava_jfr_summary
- First observedjava_list_processes
- First observedjava_mat_suspects

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.9/5.0

Scored 2026-09-09 21:46 across 8 tools

Disambiguation4/5

Tools cover distinct diagnostic actions—process listing, heap dump, class histogram, MAT suspects, JFR start/summary, GC snapshot, allocation profile—so an agent can usually pick based on the futored operation. Minor proximity exists between heap_dump and class_histogram, but names plus conceptual roles keep them separate.

Naming Consistency3/5

All names share the java_ prefix and snake_case, which helps. However, the verb placement is inconsistent: list_processes and jfr_start use a verb, while mat_suspects, class_histogram, and gc_snapshot are pure noun phrases without an obvious action word.

Tool Count5/5

Eight tools is well within the ideal range for a focused Java diagnostics server. Each tool covers a distinct diagnostic technique (JFR, heap analysis, allocation profiling, GC snapshots), and none feel redundant or extraneous.

Completeness4/5

The server covers the core heap and JFR workflows: process discovery, heap dumps, class histograms, MAT suspect analysis, and JFR capture/summarization. The main gap is the lack of a JFR stop or thread dump tool, but agents can still achieve the primary diagnosis goals.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
Meeba Brain A
io.github.meemoprasad
Repository knowledge graph MCP server for codebase understanding and debugging.
Code Analysis Developer Tools
51
Git Diff Mcp
io.github.varvararatta
MCP server for git_diff_mcp
Version Control Developer Tools
2

Related MCP Servers

Arthas MCP Server
Monitoring Developer Tools
toby1123yjh
A
license
Not graded
quality
C
maintenance
Java diagnostics MCP server for LLM integration with Alibaba Arthas, enabling analysis and diagnosis of Java applications.
Updated 10 months ago (2025-10-30 07:21 UTC)
56
MIT
javaperf
Developer Tools Monitoring
theSharque
A
license
A
quality
D
maintenance
MCP server for profiling Java applications via JDK utilities (jcmd, jfr, jps). Enables AI assistants to diagnose performance, analyze threads, and inspect JFR recordings without manual CLI usage.
Updated 4 months ago (2026-05-23 19:39 UTC)
26
26
10
MIT
codeweaver-mcp
Code Analysis Version Control Search
nobiehl
A
license
Not graded
quality
C
maintenance
Token-efficient MCP server for multi-language project analysis (Java, TypeScript, JavaScript, Markdown, Python) with plugins, semantic search, and static analysis.
Updated 10 months ago (2025-11-25 20:55 UTC)
MIT
Velociraptor Forensic MCP
Security File Systems Command Line
Hackerobi
A
license
Not graded
quality
D
maintenance
This MCP server connects Claude Desktop to a Velociraptor instance and local forensic tools. It enables remote endpoint investigation and local evidence analysis through natural language commands.
Updated 7 months ago (2026-02-10 14:28 UTC)
1
MIT

How It Works

Quick Start

1. Clone

2. Add .mcp.json to your Java project

3. Copy the Claude Code commands

4. Run

MCP Tools

Investigation Workflow

What you get back

Confidence ladder

Prerequisites

Environment overrides

Compatibility notes

CLI Usage (without Claude Code)

Tests

Contributing

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

2. Add `.mcp.json` to your Java project