Skip to main content
Glama
L1ch404

io.github.L1ch404/jolink-runtime

by L1ch404

java_fast_test

Run selected Java tests in Maven or Gradle projects with incremental compilation, returning results or a background run ID for continued tracking.

Instructions

Run selected Java tests in Maven or Gradle projects, incrementally compiling changed sources. Supports JUnit 4/5 and TestNG. No application launch is required, and an existing application is left running. Provide project_path and tests (Class or Class#method); action defaults to run. First-time preparation and compilation can take minutes; subsequent calls reuse unchanged results. Waits up to timeout (maximum 30 seconds); unfinished work returns its test_run_id and continues in the background. Observe it with java_status or cancel it here using action='cancel' and the same test_run_id. If compilation fails before run returns, it includes compiler diagnostics directly. java_status stays compact; use action='result' with test_run_id for background error diagnostics and failed-test details without rerunning tests. This is not the complete Maven/Gradle verification or packaging lifecycle.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
testsNoExplicit Fast Test selectors as fully qualified Class or Class#method. Fast Test v1 supports JUnit 4/5 and TestNG.
actionNoOmit or use run to execute tests; use result with test_run_id to read diagnostics and failure details without rerunning; use cancel to stop that test run.run
timeoutNoSeconds to wait for this test result: default 30, values above 30 wait only 30, zero submits immediately. Expiry leaves the same task running. This controls how long the call waits, not the test execution time limit.
test_run_idNoTest run ID returned by java_fast_test; required for action='cancel' or 'result'. Results are retained for the active and most recently finished run in this MCP session.
build_systemNoOptional authoritative build system for tests; specify maven or gradle when both exist.
project_pathNoMaven project or Gradle Wrapper project directory containing the selected tests. No IDEA launch configuration or running application is required.
source_filesNoOptional changed Java source paths relative to project_path, including module prefixes. May include added, edited, or deleted main/test files. Normally omit: changes are detected automatically.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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 incremental compilation, caching behavior ('subsequent calls reuse unchanged results'), async background continuation, timeout clamping to 30 seconds, compile-failure diagnostics, and that an existing application is left running. This is a comprehensive behavioral contract for an async tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every clause earns its place. It front-loads the core purpose, then covers invocation, performance, timeout, background behavior, observation, and limitations in a logical order. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex async tool with no output schema, the description covers invocation, cancellation, result retrieval, background execution, and error diagnostics. The only gap is that it does not explicitly describe the success response payload for a normal run, though test_run_id and compiler diagnostics are covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds meaning beyond the schema: test selector format ('Class or Class#method'), action defaults to 'run', timeout semantics ('values above 30 wait only 30, zero submits immediately'), and when test_run_id is required. It also clarifies that source_files should normally be omitted, which is valuable guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Run selected Java tests in Maven or Gradle projects, incrementally compiling changed sources.' It differentiates from siblings with 'No application launch is required' and 'This is not the complete Maven/Gradle verification or packaging lifecycle.' An agent can immediately distinguish it from java_application and java_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for use: 'Provide project_path and tests', and explains when to use java_status for observation and action='result' for background diagnostics. It also states an exclusion ('not the complete Maven/Gradle verification or packaging lifecycle'). However, it does not explicitly enumerate alternatives like java_application or java_debugger, leaving some inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.