find_build_systemLABSCO SUMMARY
The build, not just the source.
Most code servers stop at reading files. This one runs the Gradle build and its tests, and can bump a dependency and then show what the new JAR changed — which is the loop an upgrade actually is.
What it is
A build-system client for JVM-centred projects. It detects which build system a directory uses — Gradle, Maven, NPM or Yarn, Cargo, Python, Makefile or CMake — reads and updates dependency versions, and runs Gradle builds and test tasks directly.
What you get
- The build system in a directory identified, with the paths to its build files
- Top-level dependencies listed with their versions, and the latest available version fetched from the repository
- A dependency version written back into the build file itself
- Gradle builds run with checks optional, and Gradle test tasks run as their own step
- Class usage traced across the codebase, for when the question is what a change would break
- Two JAR files compared, so what a version bump actually changed is visible
- File and resource metadata, whole-file source replacement, and the latest source pulled down
Requirements
A Java runtime — the server builds with Gradle into a JAR, with an experimental native image alongside it. Gradle itself must be usable for the build and test tools; the rest only read your project files.
Setup effort
Build from source — git clone https://github.com/David-Parry/build-scout.git
USE CASES
01
Upgrading a dependency and finding out what it broke
Check the latest version, write it in, run the tests, and diff the JARs when something behaves differently.
02
Getting oriented in a project you did not write
Which build system, which files, and what it depends on — before reading a line of source.
03
Checking a build passes before you push
The build and the test task run from here, so the answer comes back in the conversation.
04
Working out who uses the class you want to change
Usage traced across the codebase, rather than a text search that catches the comments too.
05
Seeing what actually differs between two builds
The JAR comparison answers what changed, when the changelog does not.
13 tools
Listed in project docs. Your client may show a different list.
build_system_file_pathsbuild_gradle_projectgradle_testerdependencies_listupdate_dependency_versionlatest_dependency_versionfind_class_usagejar_diff_reporterget_file_infoget_resource_inforeplace_source_code_completedownload_current_latest_sourceBEFORE YOU INSTALL
What to know first
Tools you get
13 tools named in the project's documentation.
Requires
- Java 21+
- Gradle 8.14+ (the repository includes the gradlew wrapper)
Where it runs
All 3 documented setups run the server on your machine.
INSTALLATION
Connect your client
Server setup
TERMINAL
git clone https://github.com/David-Parry/build-scout.git
cd build-scout
./gradlew clean prebuildMCP Clients
Claude Desktop — Java
CLAUDE DESKTOP — JAVA · JSON
{
"mcpServers": {
"scout-server": {
"command": "java",
"args": [
"-jar",
"<YOUR_PATH_TO_SCOUT_1_0_VERSION>"
]
}
}
}<YOUR_PATH_TO_SCOUT_1_0_VERSION> is the full path of the JAR the build writes to build/libs/ in your clone — scout-1.0.N.jar, where N goes up by one on every build.
Claude Desktop — native image
CLAUDE DESKTOP — NATIVE IMAGE · JSON
{
"mcpServers": {
"scout-server": {
"command": "scout",
"args": [],
"env": {
"BUILD_SCOUT_LOGGING": "ERROR"
}
}
}
}Only after the experimental native build, ./gradlew clean prebuild nativeCompile, which needs GraalVM. It produces a binary named scout; put it on your PATH or use its full path as the command.
GitHub Copilot
GITHUB COPILOT · JSON
{
"servers": {
"scout-server": {
"command": "java",
"args": [
"-jar",
"<YOUR_PATH_TO_SCOUT_1_0_VERSION>"
]
}
}
}This is GitHub Copilot in IntelliJ, in ~/.config/github-copilot/intellij/mcp.json. <YOUR_PATH_TO_SCOUT_1_0_VERSION> is the full path of the JAR the build writes to build/libs/ in your clone — scout-1.0.N.jar, where N goes up by one on every build.
