Loading ToolBench
MCP server for reading and decompiling Maven jar files, with online Maven Central search and comprehensive Java project analysis
Maven Decoder MCP has 11 well-named tools with action verbs (list_, analyze_, search_, decompile_, extract_, download_), all with descriptions present. However, significant gaps exist: parameter descriptions are minimal or missing details about constraints, formats, and valid values; output schemas are not documented; error handling guidance is absent; and several tools lack depth in their descriptions. The tool set is cohesive and focused on Maven/Java analysis, but the implementation falls short of production-grade quality. Average tool score: 58/100.
Analyze Maven dependencies for a project or artifact, including transitive dependencies
Analyze a JAR file and extract its contents including classes, methods, and dependencies
Compare API changes between two versions of the same artifact by analyzing bytecode
Decompile a Java class from a JAR file using CFR, Procyon, or javap
Download a Maven artifact from Maven Central to the local repository cache
Extract class information including methods, fields, and annotations from compiled bytecode
Extract and parse POM (Project Object Model) file contents
Parameter descriptions lack constraint details. For example, 'limit' parameters describe 'Maximum number of results' but do not specify bounds (e.g., 1-1000, default 20). 'decompiler' parameter lists options 'cfr, procyon, or javap' in description but should use enum JSON Schema constraint instead. 'class_pattern' and 'group_id' support wildcards but constraints and syntax rules are not documented.
Output schemas are not documented. The tool definitions show input schemas but no return type documentation. LLMs cannot predict what fields (e.g., class names, method signatures, dependency trees) will be returned, forcing them to reason about structure blindly. This violates pattern:tool requirement that output schemas be documented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 22 | - | v1 |
Get list of available Java decompilers and their versions in the current environment
List all Maven artifacts in the local repository, optionally filtered by group ID, artifact ID, or version
Search for Java classes in the local repository by name pattern
Search Maven Central Repository for artifacts by group ID, artifact ID, or keywords
Error handling lacks recovery guidance. Tools such as download_artifact (WRITE operation) and decompile_class have no documented error conditions or guidance for what an LLM should do if a decompiler is unavailable, a JAR is corrupt, or a network fetch fails. No error categories (retryable, user-fixable, fatal) are defined.
Missing pagination and result limits. Tools like list_artifacts, search_classes, and search_maven_central accept 'limit' but no pagination cursor, offset, or next_page token is mentioned. Large result sets could blow context windows. No guidance on default or maximum limit values.
Tool descriptions are too brief (60-70 characters average). E.g., 'Search for Java classes in the local repository by name pattern' (65 chars) lacks context on WHEN to use it (instead of search_maven_central?), whether it only searches local cache or remote repos, and what structure it returns. Descriptions should be 50-200 chars and answer: WHAT, WHEN, and what it returns.
Destructive operation (download_artifact) has WRITE risk but no dry-run, confirmation, or undo mechanism documented. Per pattern:confirmation-request, irreversible operations should support user confirmation. No guidance on what happens if the artifact already exists (overwrite? skip?).
Tool composition gaps. When search_maven_central returns an artifact, does it return group_id, artifact_id, version as distinct fields so they can be directly passed to download_artifact and analyze_jar? If not, the LLM must parse and re-structure results, wasting tokens and introducing error.
Ambiguous parameter semantics. 'scope' parameter in analyze_dependencies lists options 'compile, test, provided, runtime' but does not clarify: can multiple scopes be queried in one call? Are they mutually exclusive? What is the default? Does 'compile' include transitive 'compile' deps from transitive 'runtime' deps?