Loading ToolBench
JD MCP Duo is a specialized decompiler toolkit with 7 tools covering Java bytecode analysis and batch processing. Tool definitions are mostly present with schemas and descriptions, but several critical gaps limit LLM usability: (1) Parameter descriptions lack format constraints, type suffixes, and actionable guidance, e.g., 'engine' parameter has no enum of valid decompilers, 'path' lacks guidance on file vs directory handling. (2) Output schemas are entirely absent, LLMs cannot predict return structures or plan chaining. (3) Error handling is not documented, no guidance on what failures mean or how to recover. (4) Tool names use compound suffixes (AdvancedDecompileTool, BatchDecompileTool) rather than verb-noun conventions, harming LLM parsing. (5) Several parameters are mutually exclusive or conditionally required but lack explicit documentation. (6) No pagination guidance for tools returning lists. Overall, the tools are functional for expert users but poorly optimized for autonomous agent composition.
Advanced decompilation with auto engine selection and method-level JD-Core v1/v0 patching.
Analyze supported archives under a directory and summarize class counts and sizes.
Batch decompile classes from supported archives in a directory.
Batch decompile classes from a directory root.
Generate Maven/Gradle build skeleton files from archives with inferred dependency coordinates.
Build a static caller/callee chain for a method inside the current archive or directory.
Inspect class-level metadata, methods, fields, annotations, and bytecode version.
Tool names violate verb_noun convention; use compound nouns ending in 'Tool' instead of imperative verbs (AdvancedDecompileTool vs decompile_advanced, BatchDecompileJarsTool vs batch_decompile_archives). LLMs parse verb-first names more reliably for intent inference.
NO output schemas documented for any tool. LLMs cannot predict return field structures, forcing them to guess downstream parameter names. This breaks tool chaining and invites hallucinated field references. BatchDecompileTool returns class decompilation results, what fields? AnalyzeDirectoryTool returns a summary, structured or text? Undocumented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2025-06-18+ | v2 |
Parameter 'engine' (AdvancedDecompileTool, BatchDecompileJarsTool, BatchDecompileTool) lacks an enum constraint. Description says 'auto, cfr, fernflower, etc.' but 'etc.' invites hallucination. What decompilers are actually supported? Must be an explicit enum: ["auto", "cfr", "fernflower", ...]. LLMs will invent invalid values.
Parameter 'path' across all tools lacks clarity. Is it a file or directory? Required vs optional? What formats (JAR, ZIP, class files, directories)? Description should state: 'Path to a JAR/ZIP archive or directory containing class files. If a directory, will scan for supported archives recursively if recursive=true.'
Parameter 'renderLineNumbers' (BatchDecompileJarsTool, BatchDecompileTool) lacks an enum constraint. Description says 'decompiled, source, both, or none' but should be declared as enum ["decompiled", "source", "both", "none"]. Free-form string invites typos.
Tools accepting list parameters (classpath as array vs string, files as array vs string in BuildSkeletonTool) lack clear documentation on format. Can I pass both? Must I pick one? Undocumented polymorphism invites LLM confusion.
AnalyzeDirectoryTool, BatchDecompileJarsTool, BatchDecompileTool all return results via 'summaryOnly' and 'verbose' flags but no output schema documents the returned structure. What fields are in the summary? What does verbose add? LLMs must infer or hallucinate.
No error handling documentation. What happens if 'path' does not exist? If decompilation fails for a single class in a batch? If a timeout occurs? LLMs get no guidance on recovery. Should be: 'If timeout, increase attemptTimeoutMillis or split the directory.' 'If path not found, verify the path exists and is readable.'
BatchDecompileJarsTool and BatchDecompileTool accept 'limit' and 'offset' but no indication of pagination strategy or total count returned. Without total, LLM cannot plan batch iteration. Should document: 'Returns count of processed items; offset defaults to 0. Call again with offset += count to paginate.'
CallChainTool's 'indexPath' parameter defaults to ~/.jd-mcp-duo/index.sqlite but this is opaque state. Parameter description should note: 'Local SQLite database for caching analysis. If not specified, a default user directory is used. Providing a custom path allows multi-user isolation.' This hints at dependency and state concerns.
No tool composition guidance. If an agent wants to decompile and then analyze call chains, which tools sequence? Can BatchDecompileTool output feed CallChainTool? Output schemas would clarify this, but they're absent.