search_classesLABSCO SUMMARY
The version the build resolves, not the version in the cache.
The failure this fixes is specific and expensive: four copies of an internal library sit in the Gradle cache, the agent picks one, and the answer is confidently wrong. Asking Gradle rather than the filesystem is what makes the signatures trustworthy, and the sourceAvailable flag is honest about when you are reading decompiled output instead of real source. Gradle-only is the real constraint to check first.
What it is
An MCP server and CLI that asks your build tool which dependencies this project actually resolves to, then serves source and signatures from those exact artifacts. The problem it removes is a familiar one: without the classpath an agent walks ~/.gradle/caches by hand, picks a JAR by guesswork, and answers from the wrong version. jvmsrc caches the resolved classpath and tracks build-file changes to stay current.
What you get
search_classes— find a class by simple name or glob and get compact fully-qualified names with the library each one came fromget_class_structure— a class overview with method names, or the declared signatures, chosen by scopeget_method_signature— the real overloads for a method, with parameter names and genericsfind_in_class_source— regex or substring search inside one resolved classget_class_source— method bodies or line ranges, positioned as the last resort rather than the defaultsearch_in_artifact— grep across every class in one resolved dependency JARresolve_dependencies— inspect the dependency graph the project actually uses, transitive resolutions included- Every source response carries
sourceAvailable, which is true for real sources with Javadoc and parameter names, and false when the answer came from CFR decompilation — structure reliable, names possibly synthetic
Requirements
Nothing — no account, no key, and the default configuration needs no environment variables. Node 20 or higher and Java on PATH for the CFR decompiler and javap. The package is jvmsrc (1.15.0 in package.json and server.json), installed with npm install -g jvmsrc, and the client entry runs jvmsrc with the argument mcp over stdio. Gradle only today, multimodule included; Maven and Bazel are planned, and a Maven-only tree returns an explicit unsupported error. Private repositories need their credential environment variables set on the MCP process itself, since hosts do not inherit your shell. JVMSRC_ALLOWED_ROOTS restricts which project roots it may resolve.
Setup effort
One command — npm install -g jvmsrc
USE CASES
Finding out what a superclass actually offers
Locate the class in the resolved classpath, read its structure, and get the real signature of the method you want to override.
Reading source for an internal library with no Javadoc online
Pull the source or the decompiled structure for the exact version this project resolves, without opening a JAR by hand.
Hunting for a usage pattern across a dependency
Grep every class in one resolved JAR for the call you are looking for.
Working out where a transitive version came from
Inspect the resolved dependency graph rather than the declarations in the build file.
7 tools
Listed in project docs. Your client may show a different list.
get_class_structureget_method_signaturefind_in_class_sourceget_class_sourcesearch_in_artifactresolve_dependenciesBEFORE YOU INSTALL
What to know first
Tools you get
7 tools named in the project's documentation.
Requires
jvmsrc on PATH
Where it runs
All 3 documented clients run the server on your machine.
INSTALLATION
Connect your client
Server setup
npm install -g jvmsrcMCP Clients
Claude Code, Cursor, Windsurf
{
"mcpServers": {
"jvmsrc": {
"command": "jvmsrc",
"args": [
"mcp"
]
}
}
}