Ein MCP-Server (Model Context Protocol), der Tools zur Überprüfung von Maven-Abhängigkeitsversionen bereitstellt. Dieser Server ermöglicht es LLMs, Maven-Abhängigkeiten zu verifizieren und deren neueste Versionen aus dem Maven Central Repository abzurufen.
Sie können diesen MCP-Server global über npm installieren:
npm install -g mcp-maven-depsOder führen Sie ihn direkt mit npx aus:
npx mcp-maven-depsUm den Maven Dependencies Server für Claude Desktop automatisch über Smithery zu installieren:
npx -y @smithery/cli install maven-deps-server --client claudeRelated MCP server: Maven Decoder MCP Server
Abrufen der neuesten stabilen Version einer beliebigen Maven-Abhängigkeit (schließt Vorabversionen standardmäßig aus)
Überprüfung, ob eine Maven-Abhängigkeit existiert
Überprüfung, ob eine bestimmte Version einer Abhängigkeit existiert
Auflisten von Maven-Abhängigkeitsversionen mit optionaler Filterung von Vorabversionen
Intelligente Erkennung von Vorabversionen (Alpha, Beta, Milestone, RC, Snapshot)
Unterstützung für vollständige Maven-Koordinaten einschließlich Packaging und Classifier
Echtzeitzugriff auf Daten des Maven Central Repository
Kompatibel mit verschiedenen Build-Tool-Formaten (Maven, Gradle, SBT, Mill)
Für die Entwicklung:
Klonen Sie dieses Repository
Installieren Sie die Abhängigkeiten: npm install
Erstellen Sie den Server: npm run build
Fügen Sie den Server zu Ihrer MCP-Einstellungskonfigurationsdatei hinzu:
{
"mcpServers": {
"maven-deps-server": {
"command": "npx",
"args": ["mcp-maven-deps"]
}
}
}Bei globaler Installation können Sie auch Folgendes verwenden:
{
"mcpServers": {
"maven-deps-server": {
"command": "mcp-maven-deps"
}
}
}Der Server unterstützt zwei Transportmodi:
stdio (Standard) - Standard-Eingabe/Ausgabe-Kommunikation
SSE (Server-Sent Events) - HTTP-basierte Kommunikation mit optionalem Fernzugriff
Um den SSE-Transport zu verwenden, können Sie sowohl Host als auch Port angeben:
# Local access only (default host: localhost)
npx mcp-maven-deps --port=3000
# Remote access
npx mcp-maven-deps --host=0.0.0.0 --port=3000Bei Verwendung des SSE-Transports in Ihren MCP-Einstellungen:
{
"mcpServers": {
"maven-deps-server": {
"command": "npx",
"args": ["mcp-maven-deps", "--port=3000"]
}
}
}Für den Fernzugriff verwenden Sie die IP oder den Hostnamen des Servers in Ihrer Client-Konfiguration:
{
"mcpServers": {
"maven-deps-server": {
"command": "npx",
"args": ["mcp-maven-deps", "--host=your-server-ip", "--port=3000"]
}
}
}Ruft die neueste stabile Release-Version einer Maven-Abhängigkeit ab. Standardmäßig werden Vorabversionen (Alpha, Beta, Milestone, RC, Snapshot) ausgeschlossen, um sicherzustellen, dass Sie produktionsreife Versionen erhalten.
Eingabeschema:
{
"type": "object",
"properties": {
"dependency": {
"type": "string",
"description": "Maven coordinate in format \"groupId:artifactId[:version][:packaging][:classifier]\" (e.g. \"org.springframework:spring-core\" or \"org.springframework:spring-core:5.3.20:jar\")"
},
"excludePreReleases": {
"type": "boolean",
"description": "Whether to exclude pre-release versions (alpha, beta, milestone, RC, snapshot). Default: true",
"default": true
}
},
"required": ["dependency"]
}Beispielanwendung:
// Get latest stable release (default behavior)
const result1 = await mcpClient.callTool("maven-deps-server", "get_latest_release", {
dependency: "org.springframework:spring-core"
});
// Returns: "6.2.8" (latest stable, excludes "7.0.0-M6" milestone)
// Include pre-releases if needed
const result2 = await mcpClient.callTool("maven-deps-server", "get_latest_release", {
dependency: "org.springframework:spring-core",
excludePreReleases: false
});
// Returns: "7.0.0-M6" (includes pre-releases)Überprüft, ob eine bestimmte Version einer Maven-Abhängigkeit existiert. Die Version kann entweder im Abhängigkeits-String oder als separater Parameter angegeben werden.
Eingabeschema:
{
"type": "object",
"properties": {
"dependency": {
"type": "string",
"description": "Maven coordinate in format \"groupId:artifactId[:version][:packaging][:classifier]\" (e.g. \"org.springframework:spring-core\" or \"org.springframework:spring-core:5.3.20:jar\")"
},
"version": {
"type": "string",
"description": "Version to check if not included in dependency string"
}
},
"required": ["dependency"]
}Beispielanwendung:
// Using version in dependency string
const result1 = await mcpClient.callTool("maven-deps-server", "check_maven_version_exists", {
dependency: "org.springframework:spring-core:5.3.20"
});
// Using separate version parameter
const result2 = await mcpClient.callTool("maven-deps-server", "check_maven_version_exists", {
dependency: "org.springframework:spring-core",
version: "5.3.20"
});Listet Maven-Abhängigkeitsversionen in der Reihenfolge der Bereitstellung auf, beginnend mit der aktuellsten, mit optionaler Filterung von Vorabversionen und Tiefenkontrolle. Die Ausgabe erfolgt als eine Version pro Zeile.
Eingabeschema:
{
"type": "object",
"properties": {
"dependency": {
"type": "string",
"description": "Maven coordinate in format \"groupId:artifactId[:packaging][:classifier]\" (e.g. \"org.springframework:spring-core\" or \"org.springframework:spring-core:jar\")"
},
"depth": {
"type": "number",
"description": "Number of versions to return (default: 15)",
"minimum": 1,
"maximum": 100
},
"excludePreReleases": {
"type": "boolean",
"description": "Whether to exclude pre-release versions (alpha, beta, milestone, RC, snapshot). Default: true",
"default": true
}
},
"required": ["dependency"]
}Beispielanwendung:
// Get last 15 stable versions (default - excludes pre-releases)
const result1 = await mcpClient.callTool("maven-deps-server", "list_maven_versions", {
dependency: "org.springframework:spring-core"
});
// Returns only stable versions: "6.2.8\n6.1.21\n6.2.7\n..."
// Get last 5 versions including pre-releases
const result2 = await mcpClient.callTool("maven-deps-server", "list_maven_versions", {
dependency: "org.springframework:spring-core",
depth: 5,
excludePreReleases: false
});
// Returns: "7.0.0-M6\n6.2.8\n6.1.21\n7.0.0-M5\n6.2.7"Fragt maven-metadata.xml direkt auf Maven Central ab (https://repo1.maven.org/maven2/<g>/<a>/maven-metadata.xml) – die maßgebliche Datei, die Maven und Gradle selbst bei der Abhängigkeitsauflösung konsultieren. Sie wird innerhalb von Sekunden nach einer Bereitstellung aktualisiert, sodass die Ergebnisse niemals veraltet sind.
Unterstützt vollständige Maven-Koordinaten (groupId:artifactId:version:packaging:classifier)
Intelligente Erkennung von Vorabversionen mittels Regex-Musterabgleich
Gibt Versionen in der Reihenfolge der Bereitstellung zurück (die aktuellste zuerst), wie in maven-metadata.xml aufgezeichnet
Enthält Fehlerbehandlung für ungültige Abhängigkeiten und API-Probleme
Gibt saubere, analysierbare Versions-Strings für gültige Abhängigkeiten zurück
Bietet boolesche Antworten für Überprüfungen der Versions-Existenz
Der Server erkennt Vorabversionen automatisch anhand der folgenden Muster:
Alpha: -alpha, -a
Beta: -beta, -b
Milestone: -milestone, -m, -M
Release Candidate: -rc, -cr
Snapshot: -snapshot
Beispiele:
7.0.0-M6 → Vorabversion (Milestone)
6.2.8 → Stabile Version
3.1.0-SNAPSHOT → Vorabversion (Snapshot)
2.5.0-RC1 → Vorabversion (Release Candidate)
Hinweis zu Breaking Changes: Das Tool wurde von get_maven_last_updated_version in get_latest_release umbenannt und schließt nun standardmäßig Vorabversionen aus. Dies stellt sicher, dass Produktionsanwendungen standardmäßig stabile Versionen erhalten, während bei Bedarf weiterhin Zugriff auf Vorabversionen möglich ist.
Der Server behandelt verschiedene Fehlerfälle:
Ungültiges Abhängigkeitsformat
Ungültiges Versionsformat
Nicht existierende Abhängigkeiten
Keine stabilen Releases gefunden (wenn Filterung aktiviert ist)
API-Verbindungsprobleme
Fehlerhafte Antworten
Fehlende Versionsinformationen
Um den Server zu ändern oder zu erweitern:
Nehmen Sie Änderungen an src/index.ts vor
Erstellen Sie das Projekt neu mit npm run build
Starten Sie den MCP-Server neu, um die Änderungen anzuwenden
MIT
Check if a specific version of a Maven dependency exists
| Name | Required | Description | Default |
|---|---|---|---|
| dependency | Yes | Maven coordinate in format "groupId:artifactId[:version][:packaging][:classifier]" (e.g. "org.springframework:spring-core" or "org.springframework:spring-core:5.3.20:jar") | |
| version | No | Version to check if not included in dependency string |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: e.g., whether it queries a local repository or remote server, what the return value looks like (boolean, status code, error messages), or any performance or reliability considerations. This leaves significant gaps for an agent to understand the tool's operation.
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 a single, clear sentence that directly states the tool's purpose without any fluff or redundant information. It's front-loaded and efficiently communicates the core functionality, making it easy for an agent to parse quickly.
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 the lack of annotations and output schema, the description is insufficient for a tool that performs a query operation. It doesn't explain what the output will be (e.g., true/false, error details), how to interpret results, or any dependencies like network connectivity. For a tool with two parameters and no structured output information, more context is needed.
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?
Schema description coverage is 100%, with clear documentation for both parameters in the input schema. The description doesn't add any semantic details beyond what's in the schema, such as explaining the relationship between 'dependency' and 'version' parameters or providing usage examples. This meets the baseline for high schema coverage.
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 action ('Check if exists') and the resource ('specific version of a Maven dependency'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_latest_release' or 'list_maven_versions', but the specificity of checking existence of a particular version is reasonably distinct.
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 provides no guidance on when to use this tool versus alternatives like 'list_maven_versions' or 'get_latest_release'. It doesn't mention prerequisites, error conditions, or typical use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest release version of a Maven dependency (excludes pre-releases by default)
| Name | Required | Description | Default |
|---|---|---|---|
| dependency | Yes | Maven coordinate in format "groupId:artifactId[:version][:packaging][:classifier]" (e.g. "org.springframework:spring-core" or "org.springframework:spring-core:5.3.20:jar") | |
| excludePreReleases | No | Whether to exclude pre-release versions (alpha, beta, milestone, RC, snapshot). Default: true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the default exclusion of pre-releases, which is useful behavioral context. However, it doesn't mention error handling (e.g., if dependency doesn't exist), rate limits, authentication needs, or what the return value looks like (since no output schema exists).
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 a single, efficient sentence that front-loads the core purpose and includes the key behavioral detail (default exclusion). Every word earns its place with zero waste or redundancy.
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 the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is adequate but has gaps. It covers the purpose and default behavior well, but lacks details on return values, error cases, or advanced usage scenarios. Without annotations or output schema, more context would be helpful for an agent.
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?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain the dependency format or pre-release types further). Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Get the latest release version') and resource ('a Maven dependency'), with explicit scope ('excludes pre-releases by default'). It distinguishes from sibling tools like 'check_maven_version_exists' (which verifies existence) and 'list_maven_versions' (which lists multiple versions).
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 provides clear context about when to use this tool (to get the latest release, excluding pre-releases by default). However, it doesn't explicitly state when not to use it or name specific alternatives (e.g., 'list_maven_versions' for multiple versions). The default behavior is mentioned, but no exclusions are detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Maven dependency versions sorted by last updated date (most recent first)
| Name | Required | Description | Default |
|---|---|---|---|
| dependency | Yes | Maven coordinate in format "groupId:artifactId[:packaging][:classifier]" (e.g. "org.springframework:spring-core" or "org.springframework:spring-core:jar") | |
| depth | No | Number of versions to return (default: 15) | |
| excludePreReleases | No | Whether to exclude pre-release versions (alpha, beta, milestone, RC, snapshot). Default: true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions sorting behavior but doesn't disclose other important traits like whether this is a read-only operation, potential rate limits, authentication needs, error conditions, or what the return format looks like (e.g., list structure). For a tool with no annotation coverage, this leaves significant behavioral 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 a single, efficient sentence that front-loads the core purpose with no wasted words. Every element ('List Maven dependency versions', 'sorted by last updated date', 'most recent first') earns its place by clarifying scope and behavior.
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 no annotations and no output schema, the description is incomplete for a tool with 3 parameters. It covers the basic purpose and sorting but lacks information about return values, error handling, authentication, or other behavioral context needed for reliable agent use. The high schema coverage helps, but overall completeness is inadequate.
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?
Schema description coverage is 100%, so the schema already fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline is 3 when schema does the heavy lifting, and the description doesn't compensate with additional semantic context.
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 verb ('List') and resource ('Maven dependency versions') with specific sorting criteria ('sorted by last updated date (most recent first)'). It distinguishes from sibling tools like 'check_maven_version_exists' (which checks existence) and 'get_latest_release' (which returns only the latest).
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 when needing multiple versions sorted by recency, but doesn't explicitly state when to use this tool versus alternatives like 'get_latest_release' for just the latest version or 'check_maven_version_exists' for existence checking. No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0check_maven_version_existsget_latest_releaselist_maven_versionsScored across 3 tools
Each tool has a clearly distinct purpose: checking if a specific version exists, getting the latest release version, and listing all versions sorted by recency. There is no overlap in functionality, and an agent can easily distinguish between them based on their specific use cases.
All tool names follow a consistent verb_noun pattern (check_maven_version_exists, get_latest_release, list_maven_versions), using snake_case throughout. The naming is predictable and readable, with no deviations in style or convention.
With only 3 tools, the server feels thin for a Maven dependency management domain. While the tools cover core query operations, the scope might be too limited, potentially lacking features like dependency resolution or artifact metadata retrieval that could be expected in such a server.
The tools provide good coverage for querying dependency versions, but there are notable gaps. For a Maven server, operations like searching for dependencies, retrieving artifact details (e.g., pom.xml), or managing repositories are missing, which could limit agent workflows in more complex scenarios.
MCP Server for JFrog, providing tools for development and artifact management.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
