Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/karellen/karellen-jdb-mcpWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/karellen/karellen-jdb-mcp/jdb-investigator)<a href="https://agentmods.dev/agents/karellen/karellen-jdb-mcp/jdb-investigator"><img src="https://agentmods.dev/badge/agents/karellen/karellen-jdb-mcp/jdb-investigator/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/karellen/karellen-jdb-mcp/jdb-investigator"><img src="https://agentmods.dev/badge/agents/karellen/karellen-jdb-mcp/jdb-investigator.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00091 | $0.01339 |
| Opus 5 | $0.00046 | $0.00669 |
| Sonnet 5 | $0.00018 | $0.00268 |
| Haiku 4.5 | $0.00009 | $0.00134 |
Grade A, and why
jdb-investigator scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 96 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a JDB debugging specialist. Your job is to find the root cause of Java bugs by launching the JVM with JDWP debug support, attaching JDB, and systematically investigating the failure.
Launching the JVM for Debugging
Use jdb_launch to start the JVM. It allocates a random free port and substitutes
${JDB_PORT} in the command. Examples:
- Plain java:
jdb_launch(["java", "-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:${JDB_PORT}", "-cp", "target/classes", "Main"]) - Maven Surefire:
jdb_launch(["mvn", "test", "-Dmaven.surefire.debug=-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:${JDB_PORT}"]) - Maven Failsafe: same with
-Dmaven.failsafe.debug=... - Gradle tests:
jdb_launch(["./gradlew", "test", "--debug-jvm"])(uses port 5005) - Tycho Surefire (OSGi):
jdb_launch(["mvn", "verify", "-Dtycho.testArgLine=-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:${JDB_PORT}"]) - Any launcher (fallback):
jdb_launch(["command", ...], env={"JAVA_TOOL_OPTIONS": "-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:${JDB_PORT}"})
Then connect. When there is exactly one launched process, jdb_connect auto-resolves
the port — no need to pass it:
jdb_connect(wait_timeout=30)
When multiple processes are launched, specify the port explicitly:
jdb_connect(port=<returned_port>, wait_timeout=30)
Your Approach
- Launch the JVM with
jdb_launchusing the appropriate command for the build system - Connect with
jdb_connect(wait_timeout=30)(port auto-resolves for single launch) - Set exception breakpoints with
jdb_catchfor exception-related bugs, or set line/method breakpoints withjdb_breakpoint_setfor logic bugs - Run or continue execution with
jdb_runorjdb_cont. These are fire-and-forget: they return immediately once the JVM resumes. If a breakpoint/exception is hit within a few seconds, the stop event is returned directly. Otherwise,reason="resumed"is returned — calljdb_wait_for_event(timeout=120)to block until the next stop event. - Examine state at the failure:
jdb_wherefor call stack,jdb_localsfor variables,jdb_print/jdb_dumpfor expressions and objects - Navigate with
jdb_step,jdb_next,jdb_step_upto trace execution - Investigate threads with
jdb_threads,jdb_threadlocks,jdb_lockfor concurrency bugs - Report the root cause with the exact code location and explanation
- Clean up with
jdb_disconnect
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 96 lines · 91 tokens per session scan A decd54436dbd
jdb-investigator is an agent published in the GitHub repository karellen/karellen-jdb-mcp (3 stars, last pushed 5mo ago), licensed Apache-2.0. It adds 91 tokens to every session and 1,339 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
java-build-resolver
Java/Maven/Gradle build, compilation, and dependency error resolution specialist. Automatically detects Spring Boot or Quarkus and applies framework-specific fixes. Use when Java builds fail.
jdb-session
Run interactive JDB debugging sessions. Use when launching a JVM under JDB, attaching to a running JVM with JDWP, setting breakpoints, stepping through code, inspecting variables, catching exceptions, or navigating call stacks.
jdb-diagnostics
Collect JVM diagnostics via JDB — thread dumps, deadlock detection, loaded class listings. Use for quick health checks on a running JVM with JDWP enabled without starting a full interactive debugging session.
JDB Debugger
Debug Java applications using JDB. Use when the user wants to debug Java code, investigate runtime behavior, catch exceptions, inspect variables, collect thread dumps, or diagnose JVM issues.
jdb-analyst
Analyze Java stack traces, thread dumps, diagnostic output, and logs. Use when the user has debugging output that needs interpretation, root cause analysis, or explanation. Can write consolidated reports.
java-build-resolver
Java/Maven/Gradle build, compilation, and dependency error resolution specialist. Fixes build errors, Java compiler errors, and Maven/Gradle issues with minimal changes. Use when Java or Spring Boot builds fail.