Java Decompiler MCP Server

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 key behavioral traits: multi-threading support, default output location, and progress display options. However, it doesn't mention potential side effects (e.g., file system writes when save_to_file=true), error handling, performance implications of max_workers, or what '反编译结果信息' (decompilation result information) contains. For a tool with 6 parameters and no annotations, this leaves significant gaps.

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 well-structured with a clear purpose statement followed by organized Args and Returns sections. Every sentence adds value, though the Chinese-to-English translation creates minor verbosity. It's appropriately sized for a 6-parameter tool with no annotations, though could be slightly more concise in the parameter explanations.

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 6 parameters with 0% schema coverage and no annotations, the description does an excellent job explaining parameter semantics. The presence of an output schema means the description doesn't need to detail return values. However, for a file system operation tool, it lacks warnings about destructive potential (when save_to_file=true) and doesn't mention error conditions or performance trade-offs, leaving some contextual 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?

With 0% schema description coverage (schema only provides titles and types), the description compensates fully by explaining all 6 parameters in detail. Each parameter gets clear semantic meaning: directory_path as the scan target, output_dir with default behavior, recursive for subdirectory handling, save_to_file with recommendation, show_progress for verbosity, and max_workers for concurrency control with single-threaded option.

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 specific action ('反编译' - decompile) and target resources ('.class and .jar files in a specified directory'), distinguishing it from sibling tools like decompile_file (single file) and decompile_files (multiple files). It explicitly mentions multi-threading support, which further clarifies its scope.

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 usage context through '指定目录下的所有 .class 和 .jar 文件' (all .class and .jar files in a specified directory), suggesting this is for batch directory processing. However, it doesn't explicitly state when to use this versus alternatives like decompile_file (single file) or decompile_files (multiple specific files), nor does it mention prerequisites or exclusions.

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