Provides structured compilation, build, and test execution for Gradle-based Java projects, including error and test result parsing.
Executes Jest test suites and returns parsed test results (passed, failed, skipped) with failure details.
Executes Mocha test suites and returns parsed test results with failure details.
Supports building, testing, and type-checking Node.js projects, leveraging npm, pnpm, or yarn as package managers.
Allows building and testing Node.js/TypeScript projects using npm as the package manager.
Allows building and testing Node.js/TypeScript projects using pnpm as the package manager.
Performs type checking via tsc --noEmit on TypeScript projects.
Executes Vitest test suites and returns parsed test results with failure details.
Allows building and testing Node.js/TypeScript projects using Yarn as the package manager.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Build Runner MCP Server run tests for UserServiceTest and show failures"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides structured build, compile, and test operations with parsed output to reduce token usage and improve readability.
Java version switching via SDKMAN (sdk use java <version>)
Compilation with structured error output
Build/Package with success/failure summary
Test execution with parsed test results (passed, failed, skipped)
Multi-build-system support: Maven, Gradle, npm/pnpm/yarn
Related MCP server: MCP Build Environment Service
# Clone the repository
git clone <repository-url>
cd build-runner-mcp
# Install dependencies
npm install
# Build the project
npm run buildAdd to your Claude Code settings (~/.claude.json):
{
"mcpServers": {
"build-runner": {
"command": "node",
"args": ["/path/to/build-runner-mcp/build/index.js"]
}
}
}detect_projectDetect project type, build system, test framework, and configuration.
{
"projectPath": "/path/to/project"
}Returns: Project info including languages, build system, package manager, and test framework.
set_java_versionSwitch Java version using SDKMAN before running commands.
Available versions: 17.0.16-amzn, 21.0.8-tem, 21.0.9-amzn, 25.0.1-tem
{
"version": "17.0.16-amzn"
}compile_projectCompile a Java project using Maven or Gradle.
{
"projectPath": "/path/to/project",
"javaVersion": "17.0.16-amzn",
"clean": false,
"module": "core"
}Returns: Structured compile errors and warnings with file, line, column, and message.
build_projectBuild/package a Java project.
{
"projectPath": "/path/to/project",
"javaVersion": "21.0.8-tem",
"skipTests": true,
"clean": true
}Returns: Build artifacts with paths and sizes, duration, and any errors.
run_testsRun tests for a Java project with structured results.
{
"projectPath": "/path/to/project",
"javaVersion": "17.0.16-amzn",
"testPattern": "UserServiceTest",
"module": "api",
"failFast": true
}Returns:
{
"success": false,
"summary": { "total": 50, "passed": 47, "failed": 2, "skipped": 1, "duration": "12.5s" },
"failures": [
{
"testClass": "UserServiceTest",
"testMethod": "testLogin",
"message": "Expected 200 but got 401",
"stackTrace": "...",
"file": "UserServiceTest.java",
"line": 42
}
]
}node_buildBuild a Node.js/TypeScript project.
{
"projectPath": "/path/to/project",
"script": "build",
"packageManager": "pnpm"
}node_typecheckType check a TypeScript project using tsc --noEmit.
{
"projectPath": "/path/to/project"
}node_testRun tests for a Node.js/TypeScript project (Jest, Vitest, or Mocha).
{
"projectPath": "/path/to/project",
"testPattern": "user.test.ts",
"failFast": true,
"coverage": true
}[INFO] Scanning for projects...
[INFO] --- maven-surefire-plugin:3.0.0:test ---
... (hundreds of lines)
[ERROR] Tests run: 50, Failures: 2, Errors: 0, Skipped: 1{
"success": false,
"summary": { "total": 50, "passed": 47, "failed": 2, "skipped": 1 },
"failures": [
{ "testClass": "UserServiceTest", "testMethod": "testLogin", "message": "Expected 200 but got 401" }
]
}The server automatically sources SDKMAN and switches Java versions when specified:
source "$HOME/.sdkman/bin/sdkman-init.sh" && sdk use java 17.0.16-amzn && mvn compile# Run in development mode
npm run dev
# Build
npm run build
# Clean build artifacts
npm run cleanMIT
Build/package a Java project using Maven or Gradle. Returns build artifacts and duration.
| Name | Required | Description | Default |
|---|---|---|---|
| clean | No | Run clean before build (default: false) | |
| module | No | Module(s) to include/exclude (e.g., "core,api" or "!slow-tests" or "core,!tests") | |
| alsoMake | No | Build required dependencies with -am flag (default: true, Maven only) | |
| skipTests | No | Skip running tests during build (default: true) | |
| javaVersion | No | Java version to use (e.g., "17.0.16-amzn", "21.0.8-tem") | |
| projectPath | Yes | Path to the project root directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It adds that the tool returns build artifacts and duration, but does not disclose side effects such as writes to target directories, test execution behavior, or failure modes; these remain mostly implied by 'build/package'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The primary action and return information are front-loaded, and every phrase adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core operation and a basic return summary, but with no output schema and no annotations it does not fully cover behavior such as how the build tool is selected, output location, or when to prefer a sibling. It is minimally sufficient but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters. The description adds no parameter-level detail beyond the supported build tools, which fits the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear action (build/package) and resource (Java project via Maven/Gradle), plus what is returned. However, it does not explicitly differentiate from sibling compile_project or install_project, so the distinction is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over siblings like compile_project, install_project, or detect_project. There are no exclusions, prerequisites, or alternative routing conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compile a Java project using Maven or Gradle. Returns structured error/warning information.
| Name | Required | Description | Default |
|---|---|---|---|
| clean | No | Run clean before compile (default: false) | |
| module | No | Module(s) to include/exclude (e.g., "core,api" or "!slow-tests" or "core,!tests") | |
| alsoMake | No | Build required dependencies with -am flag (default: true, Maven only) | |
| javaVersion | No | Java version to use (e.g., "17.0.16-amzn", "21.0.8-tem") | |
| projectPath | Yes | Path to the project root directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does add useful output behavior by stating that the tool returns structured error/warning information, but it does not disclose side effects such as writing build artifacts, downloading dependencies, or the time/network implications of compilation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. The key action and build systems are stated first, and the output behavior is included without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is too sparse to be fully actionable. It does not explain how the tool chooses between Maven and Gradle, what the structured error/warning output contains, or how this tool relates to build_project and install_project, so an agent lacks important context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all five parameters clearly. The description adds no additional parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compiles a Java project using Maven or Gradle, which is a specific verb and resource. However, it does not distinguish compile_project from sibling tools like build_project or install_project, so the differentiation is incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need to compile a Java Maven/Gradle project. It gives no explicit guidance about when not to use it, no alternatives, and no mention of prerequisites like detect_project or set_java_version, leaving the choice among sibling build tools to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect project type, build system, test framework, and configuration. Supports Maven, Gradle, npm, pnpm, and yarn projects.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the project root directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It is transparent about what the tool detects and which project types are supported, but it does not disclose what happens for unsupported projects, whether the operation is read-only, or what the success/failure response looks like. Given the simplicity of a detection tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. The first states the core action and object; the second lists supported ecosystems. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter detection tool, the description covers the main purpose and scope. However, with no output schema and no annotations, it lacks detail on expected return values and behavior for unsupported project types. The gaps are notable but not severe for a simple detection operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the sole parameter (projectPath). The description adds context about supported ecosystems, which implies valid project-root paths, but does not add additional parameter-specific semantics beyond that. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Detect') with a clear resource ('project type, build system, test framework, and configuration'). It also enumerates supported ecosystems (Maven, Gradle, npm, pnpm, yarn), which distinguishes it from sibling build/test/install tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance about when to use this tool versus alternatives. It implies usage as a pre-step to build/test tools, but there is no statement like 'use before build_project' or 'for unsupported project types, use X'. The supported-ecosystem list gives some context but not direct routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install a Java project to the local Maven repository using Maven (mvn install) or Gradle (publishToMavenLocal). Supports multi-module projects with -pl flag for inclusion/exclusion.
| Name | Required | Description | Default |
|---|---|---|---|
| clean | No | Run clean before install (default: false) | |
| module | No | Module(s) to include/exclude (e.g., "core,api" or "!slow-tests" or "core,!tests") | |
| alsoMake | No | Build required dependencies with -am flag (default: true, Maven only) | |
| skipTests | No | Skip running tests during install (default: true) | |
| javaVersion | No | Java version to use (e.g., "17.0.16-amzn", "21.0.8-tem") | |
| projectPath | Yes | Path to the project root directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does state the underlying commands and the effect on the local Maven repository, which is useful. However, it does not mention side effects not captured elsewhere, such as test execution defaults, dependency building behavior, or overwriting existing local artifacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action and target repository are stated first, and the multi-module capability is added in the second sentence. Every word contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, supported build tools, and multi-module capability, and the schema covers all parameters. Still, with no output schema and no annotations, it leaves some contextual gaps, such as what success/failure output looks like and how Java version selection is applied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter schema already documents all 6 parameters. The description adds some context around multi-module support via the -pl flag, but it does not materially extend the meaning of the parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action — install a Java project to the local Maven repository — and names the exact mechanisms (mvn install / publishToMavenLocal). This distinguishes it from sibling tools like build_project and compile_project, which do not install artifacts to a local repository.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool is appropriate: when a Java project needs to be installed locally via Maven or Gradle. It also notes multi-module support, but it does not explicitly contrast the tool with siblings such as build_project or run_tests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a Node.js/TypeScript project using npm, pnpm, or yarn.
| Name | Required | Description | Default |
|---|---|---|---|
| script | No | NPM script to run (default: "build") | |
| projectPath | Yes | Path to the project root directory | |
| packageManager | No | Package manager to use (auto-detected if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the package managers but not whether dependencies are installed first, what side effects occur (e.g., output artifacts), what the return behavior is, or whether the operation is safe. For a build operation, this is a meaningful transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-constructed sentence with no filler. It front-loads the core action and resource, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description is moderately complete: it identifies the operation and package managers, and the schema covers parameters. However, it omits context about whether a specific script must exist, whether installation happens first, and what success/failure looks like, so an agent may still need to probe behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented. The description adds a little extra meaning by reaffirming the accepted package managers (npm, pnpm, yarn) and the Node.js/TypeScript context, but it does not go beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Build') and resource ('Node.js/TypeScript project'), and names the supported package managers. It is distinguishable from siblings like set_java_version or node_test by its language and build focus, but it does not explicitly contrast itself with the more generic build_project or compile_project siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to choose this tool over build_project, compile_project, or install_project. It implies usage for Node.js/TypeScript builds but never states exclusions or alternatives, leaving the agent to infer selection criteria from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run tests for a Node.js/TypeScript project using Jest, Vitest, or Mocha. Returns structured test results.
| Name | Required | Description | Default |
|---|---|---|---|
| coverage | No | Generate coverage report (default: false) | |
| failFast | No | Stop on first failure (default: false) | |
| projectPath | Yes | Path to the project root directory | |
| testPattern | No | Test file or name pattern | |
| testFramework | No | Test framework (auto-detected if not specified) | |
| packageManager | No | Package manager to use (auto-detected if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that results are returned in structured form, which is useful behavioral information. However, with no annotations, it does not mention potential side effects such as coverage artifacts, prerequisites like installed dependencies, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with the core action first and the return behavior second. There is no filler, repetition of schema fields, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter tool with no annotations and no output schema, this description is too thin. It omits when to use this versus run_tests, what the structured results contain, and how framework/package-manager auto-detection behaves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all six parameters with 100% coverage, so the baseline is 3. The description adds little beyond the schema, and it only indirectly references the framework options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Run tests') and a specific resource ('Node.js/TypeScript project'), and narrows the scope to Jest, Vitest, or Mocha. It does not explicitly contrast itself with the generic sibling run_tests, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Node.js/TypeScript scope and listed frameworks give implied guidance about when to use the tool. However, it does not explicitly explain when to choose it over the overlapping sibling run_tests or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type check a TypeScript project using tsc --noEmit.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the project root directory | |
| packageManager | No | Package manager to use (auto-detected if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'tsc --noEmit' is a meaningful disclosure: the tool performs a type check and does not emit compiled output. However, it does not explain failure behavior, exit codes, whether dependencies must be installed first, or what happens when type errors are found, leaving transparency partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the key action is front-loaded immediately. Every word contributes: the operation, the target resource, and the command-line mode.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents the parameters and the operation is simple, so an agent can invoke it with minimal risk. However, with no annotations, no output schema, and no usage-guidance context, some gaps remain around expected outcomes and when to prefer this over sibling tools. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline applies since the schema already documents both projectPath and packageManager. The description adds no extra meaning beyond tying the action to a TypeScript project; it does not elaborate on path expectations, package-manager resolution, or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Type check') and resource ('a TypeScript project'), and names the exact mechanism ('tsc --noEmit'). This clearly distinguishes it from sibling tools like build_project, compile_project, and node_test, because type-checking without emit is a distinct validation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over its siblings, such as compile_project, node_test, or run_tests. The description implies its use only through the verb 'type check' and provides no exclusions, prerequisites, or alternative routing. An agent must infer usage context from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run tests for a Java project using Maven or Gradle. Returns structured test results with failures and stack traces.
| Name | Required | Description | Default |
|---|---|---|---|
| clean | No | Run clean before tests (default: false) | |
| module | No | Module(s) to include/exclude (e.g., "core,api" or "!slow-tests" or "core,!tests") | |
| alsoMake | No | Build required dependencies with -am flag (default: true, Maven only) | |
| failFast | No | Stop on first failure (default: false) | |
| javaVersion | No | Java version to use (e.g., "17.0.16-amzn", "21.0.8-tem") | |
| projectPath | Yes | Path to the project root directory | |
| testPattern | No | Specific test class or method pattern (e.g., "UserServiceTest", "UserServiceTest#testLogin") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses the return shape ('structured test results with failures and stack traces'), which is useful, but it does not mention potential side effects of running arbitrary test code (e.g., executing project code, downloading dependencies, or producing build artifacts). It is not misleading, just incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the action and scope, the second states the return value. Every word earns its place, with no redundant detail or complex structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides only a high-level result summary. It does not clarify prerequisites (e.g., whether the project must already be built), how Maven vs Gradle is detected, or timeout/performance expectations. The 7 parameters are well documented in the schema, but the operational context is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter already has a descriptive comment, so the description does not need to add parameter details. It adds no additional meaning beyond the schema, keeping it at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and resource ('tests for a Java project'), and names the build tools (Maven or Gradle). It clearly distinguishes from Node-focused siblings like node_test and from build/compile tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it — for Java projects using Maven/Gradle, not Node projects — but does not explicitly state when not to use it or how it compares to alternatives like build_project, compile_project, or detect_project. Usage context is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch Java version using SDKMAN before running commands. Available versions: 17.0.16-amzn, 21.0.8-tem, 21.0.9-amzn, 25.0.1-tem
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes | Java version to switch to (e.g., "17.0.16-amzn", "21.0.8-tem") | |
| projectPath | No | Optional: project path to verify the switch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the mechanism (SDKMAN), available versions, and the intended timing, but it does not describe side effects, persistence of the switch, or failure behavior. This is a partial but not complete behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence that leads with the action, then gives the mechanism, timing, and a list of valid values. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers purpose, mechanism, valid inputs, and usage timing. Return values are not described and there is no output schema, but for a switch command this is a minor gap; an agent can likely infer success from the command outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by enumerating the exact available versions, which is more specific than the schema's examples. It doesn't add anything about projectPath, but the schema already explains it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Switch Java version') with a clear method ('using SDKMAN') and temporal context ('before running commands'). This clearly distinguishes it from sibling build/test tools, which address different concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'before running commands', giving the agent a clear when-to-use signal. It does not mention when-not-to-use or alternatives, but no alternative Java-version-switching tool exists among the siblings, so exclusions are unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0build_projectcompile_projectdetect_projectinstall_projectnode_buildnode_testnode_typecheckrun_testsset_java_versionScored across 9 tools
Most tools cleanly separate by ecosystem and build phase: Java build/install/compile/test versus Node build/test/typecheck. The only real ambiguity is compile_project vs build_project, since compilation is normally part of a build, but the descriptions clarify that compile focuses on diagnostics while build produces artifacts.
Naming is mixed: Java tools mostly follow verb_project (build_project, install_project, compile_project), while Node tools follow node_verb (node_test, node_build, node_typecheck). run_tests breaks the Java pattern by using a generic verb instead of something like test_project, and set_java_version follows yet another style.
Nine tools is well-scoped for a multi-language build runner. Each tool covers a meaningful build, test, install, detect, or environment-management action without feeling padded or redundant.
The surface covers the core Java and Node.js workflows: detection, building, compiling, testing, installing for Java, and type checking for TypeScript projects. Minor gaps like a Node install/publish command or a generic clean task are absent, but agents can still complete typical build-and-test workflows.
Agentic CI operations for build inspection, failure diagnosis, and runner troubleshooting.
Structured knowledge base for AI agent solutions. Search, explore, and retrieve build logs.
Discover software problems, analyze evidence, and create implementation-ready Build plans.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
