Java Project Runner MCP

project_inspect

Inspect a registered Java project to verify POM, Maven wrapper, Java home, and JAR path resolvability, probe Maven version, and summarize configuration.

Instructions

Inspect a registered project: pom/wrapper/javaHome/jarPath resolvability, Maven version probe, and config summary

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_inspect"
  }
}

Input Schema

Name	Required	Description	Default
`projectId`	Yes	Registry project id

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.3.1Nov 2, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description must carry behavioral weight. The enumerated checks do disclose meaningful behavior (a Maven version probe implies invoking an external process, resolvability checks imply filesystem access), but it never states whether the tool is side-effect free, whether the probe is expensive/slow, or how failures surface.

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?

A single front-loaded sentence with a dense, specific enumeration and zero filler. Every clause adds a distinct check the agent would otherwise have to guess at.

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?

There is no output schema and no annotations, but the enumerated checks effectively preview what inspection reports back, which is the key thing an agent needs. The remaining gap is whether failures are returned as data or errors, which is minor for a one-parameter read-style tool.

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

Parameters3/5

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

Schema description coverage is 100% with a single 'projectId' parameter already documented as 'Registry project id'. The description adds nothing about the id's origin or format (e.g. whether it comes from project_register output), so the baseline 3 applies.

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?

States a specific verb ('Inspect') and resource ('a registered project'), then enumerates exactly what is checked: pom/wrapper/javaHome/jarPath resolvability, Maven version probe, config summary. This separates it in substance from project_build/project_start, though it never names project_status as the contrasting sibling for plain state reads.

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?

Usage is only implied: the checks listed (resolvability, Maven probe) suggest pre-build diagnostics, but there is no explicit 'use when X, not when Y' statement and no mention of project_status as the alternative for simple state queries.

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

Deploy Server