Loading ToolBench
MCP server for interactive Java reverse engineering: decompile, disassemble, search and patch JARs
vineflower-mcp has 22 well-named tools with complete input schemas and descriptions. Naming follows verb_noun convention (decompile_jar, find_references, list_jar_contents). All 22 tools have descriptions (avg ~100 chars) and typed parameters with descriptions. However, output schemas are not documented in the visible code, responses are described only in tool descriptions, not as formal JSON Schema. Error handling is minimal: no recovery guidance, no categorization of retryable vs fatal errors, no actionable error messages. Security is reasonable (no secrets in params), but no permission gates or audit trail declarations. Composition is strong: tools chain well (decompile_jar → get_decompiled_source), and most operations are read-only with clear side effects for write tools (patch_jar, compile_java, inject_method_call). Parameter quality is high: enums used for filter/context, optional params well-documented, no overloaded params. Missing: output schema documentation, error recovery patterns, and per-tool permission declarations.
Compile Java source code into class files
Decompile a single class from a JAR file
Decompile multiple classes from a JAR
Decompile an entire JAR file using Vineflower
Decompile a class with custom Vineflower options
Disassemble a class using javap to show bytecode
Extract enum constants from an enum class
Output schemas not documented. Tool descriptions mention what is returned (e.g., 'workspace_id', 'decompiled source'), but no formal JSON Schema output types are visible in code. LLMs cannot plan downstream tool calls or extract fields reliably without documented return types.
No error recovery guidance. Tools return errors but do not guide the LLM on next steps. E.g., 'JAR file not found' should suggest 'Check the path or call list_available_jars()' (if such a tool existed). No categorization of retryable vs fatal errors.
Destructive operations (patch_jar, inject_method_call, compile_java) lack confirmation or dry-run support. An agent could irreversibly modify a JAR without a safety gate. No idempotency guarantees documented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
Find classes whose <init> method contains a given integer value, optionally filtered by a paired string literal
Find the class hierarchy (superclass chain, interfaces, subclasses) for a class
Find numeric constants in a JAR with optional value or hex filter and context filtering
Find all references to a class or method in a JAR
Find all string literals in a JAR with optional regex filter
Extract and display the constant pool of a class
Retrieve a decompiled source file from a workspace
Extract and display the manifest from a JAR file
Inject a static method call into a method's bytecode
Assemble Krakatau assembly text into class files
Disassemble a class using Krakatau into assembly text format
List the contents of a JAR file with optional filtering
Create a patched JAR by replacing or adding class files from a workspace
Search decompiled source files in a workspace using regex
Trace from a string literal through method calls and class hierarchies
No permission declarations. Tools do not declare required scopes (e.g., 'read:jar', 'write:jar'). Agents cannot be configured with least-privilege access, and audit trails lack permission context.
Result limits not enforced or documented. find_string_literals, find_references, and search_sources could return thousands of matches, exhausting context. No pagination, limit params, or truncation guidance visible.