Skip to main content
Glama
L1ch404

io.github.L1ch404/jolink-runtime

by L1ch404
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

java_application

Manage Java app runtimes: launch, attach, restart, stop, or detach processes, with hotswap-aware restarts for Maven/Gradle projects.

Instructions

Launch, attach, restart, stop, or detach Java applications. For Maven/Gradle, use project_path plus main_class without IDEA, or select an IDEA launch. Use java_fast_test to run tests without launching an application. Launch and restart wait up to timeout (at most 30 seconds), returning the result if finished or the original background task if still running. After editing a managed Maven/Gradle project, use restart: it detects changed sources, incrementally compiles them, and prefers HotSwap (hotswap=true by default). Incompatible changes use the same compiled outputs to restart the JVM. Set hotswap=false for a real process restart and application reinitialization. apply_method reports hotswap or restart; HotSwap does not refresh framework state or count as a JVM startup. previous_startup_ms reports the prior successful startup duration saved locally for this launch, or null if unavailable. It survives MCP restarts and excludes compilation. A pending restart returns reload_id; observe active_operation and last_reload using java_status. Direct JAR/classpath launches restart their existing artifact without source compilation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pidNoLocal Java PID required by attach.
hostNoDebug connection host; localhost only.127.0.0.1
actionYesRuntime operation to perform.
hotswapNoFor restart, default true: incrementally compile edits and prefer HotSwap; if changes cannot be hot-swapped, restart the JVM with those compiled outputs. False forces a JVM restart after compilation. Use false to reinitialize application state or reload framework/startup configuration. No pending code changes also restart the JVM without recompiling.
timeoutNoSeconds to wait for the launch/restart result in this call. Defaults to 30; values above 30 wait only 30 seconds without error. Zero returns immediately after submission. On expiry the same task continues in the background.
vm_argsNoJVM arguments for launch/restart. Replaces imported or current arguments; [] clears them.
app_argsNoApplication arguments for launch/restart. Replaces imported or current arguments; [] clears them.
jar_pathNoExecutable JAR for direct launch/restart; omit with project_path.
classpathNoClasspath for direct launch/restart with main_class; omit with project_path.
java_homeNoApplication JDK home directory for project_path launch.
jdwp_portNoLocal Java debug port for launch or attach.
main_classNoFully qualified application entry class. With project_path, launch without requiring IDEA configuration; otherwise uses classpath.
ready_portNoLocal application TCP port for launch/restart readiness; must differ from jdwp_port.
launch_nameNoOptional exact case-sensitive IDEA launch configuration name; requires project_path. With main_class and no launch_name, no IDEA launch configuration is required. Explicit main_class, java_home, app_args and vm_args override imported values.
build_systemNoOptional authoritative build system for project launch; specify maven or gradle when both exist.
project_pathNoMaven or Gradle project directory. Supply main_class for an IDEA-independent launch, or import an IDEA launch configuration (launch_name selects one). Compiles changed sources before starting the application. Do not combine with direct jar_path or classpath.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses timeout behavior (max 30s, returns result or background task), hotswap vs full restart semantics, persistence of previous_startup_ms across MCP restarts, and pending restart's reload_id. Minor gaps like permission/authentication needs are not mentioned, but given the tool's local nature, this is adequate.

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

Conciseness4/5

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

The description is long but dense and well-structured. It front-loads the core actions, then organizes details logically: Maven/Gradle usage, timeout behavior, restart/hotswap, persistence, and direct launches. Each sentence earns its place, and the flow mirrors how an agent would reason about the tool, avoiding redundancy.

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?

Given the tool's complexity (16 parameters, 5 actions, multiple launch modes), the description is remarkably complete. It covers return values (result vs background task, previous_startup_ms, reload_id), integration with java_status, and all parameter interactions. Without an output schema, it adequately explains what an agent should expect back, leaving little ambiguity for a well-designed tool.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema, such as explaining that project_path compiles changed sources, that hotswap defaults to true but false forces a JVM restart, and that timeout above 30 waits only 30 seconds. It also clarifies interplay between launch_name, main_class, and project_path, which the schema alone does not.

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?

The description opens with a precise verb set ('Launch, attach, restart, stop, or detach Java applications'), clearly identifying the tool's scope. It also distinguishes itself from siblings by explicitly directing test runs to java_fast_test and status checks to java_status, so an agent can immediately tell it apart.

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

Usage Guidelines5/5

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

It provides explicit when-to-use and when-not-to-use guidance: 'Use java_fast_test to run tests without launching an application', and detailed instructions for Maven/Gradle launches (project_path plus main_class vs IDEA launch). It also explains when to set hotswap=false for a real restart, covering alternatives and conditions directly.

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

Deploy Server

Other Tools