Skip to main content
Glama
Sign In
Java Project Runner MCP

Java Project Runner MCP

by vinsmoke-sanji59
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

project_stop

Stops only the managed process group for a Java project using SIGTERM then SIGKILL, avoiding kills by port or main class.

Instructions

Stop the managed process group only (SIGTERM then SIGKILL). Never kills by port/main-class.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>"
    },
    "name": "project_stop"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectIdYes
timeoutSecondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.1

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description does carry real behavioral weight: it discloses the SIGTERM-then-SIGKILL escalation and the targeting scope, which is genuinely useful. It omits whether the call blocks until termination, permission requirements, and what happens if the process is already stopped.

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?

Two tight sentences, with the scope constraint front-loaded and the exclusion following. Nothing redundant.

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

Completeness2/5

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

This is a destructive mutation with no annotations, no output schema, and 0% parameter documentation. The description should say whether it blocks, what the timeout defaults to, and how failure/no-op cases behave; without that, an agent cannot call it confidently.

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

Parameters2/5

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

Schema description coverage is 0% for two parameters. The description never mentions projectId or timeoutSeconds, so the relationship between the timeout and the SIGTERM/SIGKILL escalation is left entirely undocumented.

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

Purpose4/5

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

The description uses a specific verb ('Stop') and names the exact target ('the managed process group'), plus excludes port/main-class targeting. It does not name or distinguish the sibling project_force_stop, so an agent must infer the escalation-vs-force distinction.

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

Usage Guidelines3/5

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

'Never kills by port/main-class' implies a scoping constraint, but the description gives no explicit guidance on when to choose this over project_force_stop, project_restart, or project_reclaim, and no prerequisites are stated.

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