JVM Source Lens MCP server
io.github.Sintexer/jvmsrc·v1.16.0·4 starsGradle-accurate JVM classpath; fetch Java source, signatures, and class structure for agents.
4 stars73 downloads/wk
Reviews
Write oneNobody has reviewed JVM Source Lens yet.
If you have run it, two minutes of your experience saves the next person an afternoon.
JVM Source Lens tools (7)
write = sends, deletes, buys or postsRead from the package source without running it. The installed server may list more.
find_in_class_sourceget_class_sourceget_class_structureget_method_signatureresolve_dependenciessearch_classessearch_in_artifact
Public scan report
scanner v0.1.10 · 2026-10-15 · same rubric, same numbers if you re-run it
- Code scan4 source files scanned25/25
- –Live reliabilityno gateway calls yet and no remote to proben/a
- –Tool poisoningtools not inspected (local package is not executed); not countedn/a
- Auth qualitylocal package, no credentials required12/15
- Maintenancelast push 1 days ago15/15
- Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10
How JVM Source Lens compares
Against every graded MCP server, from our own scans and uptime checks. Updated after each scan run.
- Safety score
- 92/100
- higher than 93% of 48,243 servers
- Tools
- 7
- the typical server has 7
- Tools that change things
- 0%
- typical: 0%. Fewer write tools means less an agent can break
- GitHub stars
- 4
- more than 82% of 28,706 servers
- Downloads a week
- 73
- more than 54% of 12,306 servers with a package
What its tools let an agent do: 7 read
Install JVM Source Lens in Claude Code, Cursor or VS Code
Runs npx -y jvmsrc on your machine. Read the scan report first; the gateway never runs local packages.
claude mcp add jvmsrc -- npx -y jvmsrc
What the publisher says
From the JVM Source Lens repository's README, as published. We do not edit it. Read it on GitHub
jvmsrc — Give your coding agent a Java IDE
An MCP server and CLI that gives your coding agent the one thing it's missing on JVM codebases: the actual classpath.
The Problem
You use an IDE to write Java. Your coding agent doesn't have one.
When your agent hits an unfamiliar library type — say, a superclass from a proprietary internal library — it spends 25+ turns walking ~/.gradle/caches, opening JARs by hand with jar tf, picking one by guesswork, and trying to answer a question your IDE would answer in one keystroke: does this superclass have a public utility method called X?
The Solution
jvmsrc queries your build tool (Gradle) for this project's resolved classpath, then hands your agent real source, real signatures, and real structure — for the exact version your build actually uses.
- As an MCP server – Connect to Claude Code, Cursor, Windsurf, or any other MCP host and equip your agent with six purpose-built classpath tools.
- As the jvmsrc CLI – Same engine, scriptable, pipe-friendly, and useful on its own when you just want to read a class.
Claude Code resolving HandlerInterceptor signatures via jvmsrc — 3 calls, correct answer, no cache walking.
What it saves, daily
On JVM projects with private libraries and no public Javadocs, jvmsrc is a force multiplier:
- ~50K tokens saved per "what's on this external class" investigation — roughly 70% reduction in cost.
- 15+ agent panic loops avoided daily — no grinding through Gradle caches, opening wrong JARs, or giving up.
- Unlock delegation for complex tasks touching internal SDKs that you previously had to do yourself.
The Difference in Action
Without jvmsrc (The 25-turn blind grind)
User: Override the audit hook from AbstractTradingService — is there a public utility method on it we should reuse?
Agent:
1. Searches workspace for AbstractTradingService.java ➔ 0 hits
2. Runs: find ~/.gradle -name "trading-core*"
3. Finds 4 versions: 2.1.0, 2.3.0, 2.4.1, 3.0.0-SNAPSHOT
4. Guesses: Picks trading-core-2.4.1.jar (the project actually uses 3.0.0-SNAPSHOT!)
5. Runs: jar tf and javap -p on the wrong JAR
6. [22 turns later] "I don't see a utility method, you'll have to implement it yourself."
Reality: 3.0.0-SNAPSHOT added maskSensitiveFields() as a protected helper exactly for this case. The agent didn't hallucinate — it was just blind.
With jvmsrc (The 3-turn instant resolution)
User: Override the audit hook from AbstractTradingService — is there a public utility method on it we should reuse?
Agent:
1. search_classes("AbstractTradingService") ➔ Finds FQN & exact resolved library.
2. getclassstructure(scope: "overview") ➔ Discovers maskSensitiveFields() in 3.0.0-SNAPSHOT.
3. getmethodsignature("maskSensitiveFields") ➔ Gets accurate signature and generics.
Result: Writes the override correctly on the first try. No cache walking, no guessing, no wrong version.
How It Works
Shortened. The full README is on GitHub.
Nothing above is checked by us. What we check is on the safety report.
JVM Source Lens: common questions
- Is JVM Source Lens MCP server safe?
- Yes, by our scan: it is graded A (92/100). Read the JVM Source Lens safety report
- How do I install JVM Source Lens?
- It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.
- Does JVM Source Lens need an API key?
- No secret keys are declared. It reads 6 settings from the environment.
- Is JVM Source Lens maintained?
- The last commit was 22 days ago (2026-10-14). The latest release is v1.16.0.
- How does JVM Source Lens compare with other MCP servers?
- safety score 92/100 (higher than 93% of 48,243 servers); tools 7 (the typical server has 7); tools that change things 0% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.