Un servidor MCP (Model Context Protocol) que proporciona herramientas para verificar las versiones de dependencias de Maven. Este servidor permite a los LLM verificar dependencias de Maven y recuperar sus versiones más recientes desde el Repositorio Central de Maven.
Puede instalar este servidor MCP globalmente usando npm:
npm install -g mcp-maven-depsO ejecutarlo directamente usando npx:
npx mcp-maven-depsPara instalar el servidor de dependencias de Maven para Claude Desktop automáticamente a través de Smithery:
npx -y @smithery/cli install maven-deps-server --client claudeRelated MCP server: Maven Decoder MCP Server
Obtenga la última versión estable de cualquier dependencia de Maven (excluye versiones preliminares por defecto)
Verifique si existe una dependencia de Maven
Compruebe si existe una versión específica de una dependencia
Liste las versiones de dependencias de Maven con filtrado opcional de versiones preliminares
Detección inteligente de versiones preliminares (alpha, beta, milestone, RC, snapshot)
Soporte para coordenadas completas de Maven, incluyendo empaquetado y clasificador
Acceso en tiempo real a los datos del Repositorio Central de Maven
Compatible con múltiples formatos de herramientas de construcción (Maven, Gradle, SBT, Mill)
Para desarrollo:
Clone este repositorio
Instale las dependencias: npm install
Construya el servidor: npm run build
Añada el servidor a su archivo de configuración de ajustes de MCP:
{
"mcpServers": {
"maven-deps-server": {
"command": "npx",
"args": ["mcp-maven-deps"]
}
}
}Si se instaló globalmente, también puede usar:
{
"mcpServers": {
"maven-deps-server": {
"command": "mcp-maven-deps"
}
}
}El servidor admite dos modos de transporte:
stdio (predeterminado) - Comunicación de entrada/salida estándar
SSE (Server-Sent Events) - Comunicación basada en HTTP con acceso remoto opcional
Para usar el transporte SSE, puede especificar tanto el host como el puerto:
# Local access only (default host: localhost)
npx mcp-maven-deps --port=3000
# Remote access
npx mcp-maven-deps --host=0.0.0.0 --port=3000Al usar el transporte SSE en sus ajustes de MCP:
{
"mcpServers": {
"maven-deps-server": {
"command": "npx",
"args": ["mcp-maven-deps", "--port=3000"]
}
}
}Para acceso remoto, use la IP o el nombre de host del servidor en la configuración de su cliente:
{
"mcpServers": {
"maven-deps-server": {
"command": "npx",
"args": ["mcp-maven-deps", "--host=your-server-ip", "--port=3000"]
}
}
}Recupera la última versión estable de una dependencia de Maven. Por defecto, esto excluye versiones preliminares (alpha, beta, milestone, RC, snapshot) para asegurar que obtenga versiones listas para producción.
Esquema de entrada:
{
"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"]
}Ejemplo de uso:
// 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)Comprueba si existe una versión específica de una dependencia de Maven. La versión puede proporcionarse en la cadena de dependencia o como un parámetro separado.
Esquema de entrada:
{
"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"]
}Ejemplo de uso:
// 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"
});Enumera las versiones de dependencias de Maven en orden de despliegue, de la más reciente a la más antigua, con filtrado opcional de versiones preliminares y control de profundidad. La salida es una versión por línea.
Esquema de entrada:
{
"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"]
}Ejemplo de uso:
// 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"Consulta maven-metadata.xml en Maven Central directamente (https://repo1.maven.org/maven2/<g>/<a>/maven-metadata.xml), el archivo autoritativo que Maven y Gradle consultan durante la resolución de dependencias. Se actualiza segundos después de un despliegue, por lo que los resultados nunca están obsoletos.
Soporta coordenadas completas de Maven (groupId:artifactId:version:packaging:classifier)
Detección inteligente de versiones preliminares mediante coincidencia de patrones regex
Devuelve las versiones en orden de despliegue (la más reciente primero) tal como se registra en maven-metadata.xml
Incluye manejo de errores para dependencias no válidas y problemas de API
Devuelve cadenas de versión limpias y analizables para dependencias válidas
Proporciona respuestas booleanas para comprobaciones de existencia de versiones
El servidor detecta automáticamente las versiones preliminares utilizando los siguientes patrones:
Alpha: -alpha, -a
Beta: -beta, -b
Milestone: -milestone, -m, -M
Release Candidate: -rc, -cr
Snapshot: -snapshot
Ejemplos:
7.0.0-M6 → Versión preliminar (milestone)
6.2.8 → Versión estable
3.1.0-SNAPSHOT → Versión preliminar (snapshot)
2.5.0-RC1 → Versión preliminar (release candidate)
Nota sobre cambios importantes: La herramienta ha sido renombrada de get_maven_last_updated_version a get_latest_release y ahora excluye versiones preliminares por defecto. Esto asegura que las aplicaciones de producción obtengan versiones estables por defecto, permitiendo al mismo tiempo el acceso a versiones preliminares cuando sea necesario.
El servidor maneja varios casos de error:
Formato de dependencia no válido
Formato de versión no válido
Dependencias inexistentes
No se encontraron versiones estables (cuando el filtrado está habilitado)
Problemas de conexión a la API
Respuestas mal formadas
Información de versión faltante
Para modificar o extender el servidor:
Realice cambios en src/index.ts
Reconstruya usando npm run build
Reinicie el servidor MCP para aplicar los cambios
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)
