MCP-сервер (Model Context Protocol), предоставляющий инструменты для проверки версий зависимостей Maven. Этот сервер позволяет LLM проверять зависимости Maven и получать их последние версии из центрального репозитория Maven (Maven Central Repository).
Вы можете установить этот MCP-сервер глобально с помощью npm:
npm install -g mcp-maven-depsИли запустить его напрямую с помощью npx:
npx mcp-maven-depsЧтобы автоматически установить сервер зависимостей Maven для Claude Desktop через Smithery:
npx -y @smithery/cli install maven-deps-server --client claudeRelated MCP server: Maven Decoder MCP Server
Получение последней стабильной версии любой зависимости Maven (по умолчанию исключает предварительные релизы)
Проверка существования зависимости Maven
Проверка существования конкретной версии зависимости
Список версий зависимостей Maven с опциональной фильтрацией предварительных релизов
Интеллектуальное обнаружение предварительных релизов (alpha, beta, milestone, RC, snapshot)
Поддержка полных координат Maven, включая упаковку (packaging) и классификатор (classifier)
Доступ в реальном времени к данным центрального репозитория Maven
Совместимость с различными форматами инструментов сборки (Maven, Gradle, SBT, Mill)
Для разработки:
Клонируйте этот репозиторий
Установите зависимости: npm install
Соберите сервер: npm run build
Добавьте сервер в файл конфигурации настроек MCP:
{
"mcpServers": {
"maven-deps-server": {
"command": "npx",
"args": ["mcp-maven-deps"]
}
}
}Если сервер установлен глобально, вы также можете использовать:
{
"mcpServers": {
"maven-deps-server": {
"command": "mcp-maven-deps"
}
}
}Сервер поддерживает два режима транспорта:
stdio (по умолчанию) — обмен данными через стандартный ввод/вывод
SSE (Server-Sent Events) — обмен данными по HTTP с опциональным удаленным доступом
Чтобы использовать транспорт SSE, вы можете указать хост и порт:
# Local access only (default host: localhost)
npx mcp-maven-deps --port=3000
# Remote access
npx mcp-maven-deps --host=0.0.0.0 --port=3000При использовании транспорта SSE в настройках MCP:
{
"mcpServers": {
"maven-deps-server": {
"command": "npx",
"args": ["mcp-maven-deps", "--port=3000"]
}
}
}Для удаленного доступа используйте IP-адрес или имя хоста сервера в конфигурации клиента:
{
"mcpServers": {
"maven-deps-server": {
"command": "npx",
"args": ["mcp-maven-deps", "--host=your-server-ip", "--port=3000"]
}
}
}Получает последнюю стабильную версию зависимости Maven. По умолчанию исключает предварительные версии (alpha, beta, milestone, RC, snapshot), чтобы гарантировать получение версий, готовых к использованию в продакшене.
Схема входных данных:
{
"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"]
}Пример использования:
// 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)Проверяет, существует ли конкретная версия зависимости Maven. Версия может быть предоставлена либо в строке зависимости, либо как отдельный параметр.
Схема входных данных:
{
"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"]
}Пример использования:
// 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"
});Выводит список версий зависимости Maven в порядке развертывания (самые новые первыми) с опциональной фильтрацией предварительных релизов и контролем глубины. Вывод — по одной версии на строку.
Схема входных данных:
{
"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"]
}Пример использования:
// 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"Напрямую запрашивает maven-metadata.xml в Maven Central (https://repo1.maven.org/maven2/<g>/<a>/maven-metadata.xml) — это авторитетный файл, к которому обращаются Maven и Gradle при разрешении зависимостей. Он обновляется в течение нескольких секунд после развертывания, поэтому результаты всегда актуальны.
Поддерживает полные координаты Maven (groupId:artifactId:version:packaging:classifier)
Интеллектуальное обнаружение предварительных релизов с использованием регулярных выражений
Возвращает версии в порядке развертывания (самые новые первыми), как указано в maven-metadata.xml
Включает обработку ошибок для неверных зависимостей и проблем с API
Возвращает чистые, парсируемые строки версий для корректных зависимостей
Предоставляет логические ответы для проверок существования версий
Сервер автоматически обнаруживает предварительные версии, используя следующие шаблоны:
Alpha: -alpha, -a
Beta: -beta, -b
Milestone: -milestone, -m, -M
Release Candidate: -rc, -cr
Snapshot: -snapshot
Примеры:
7.0.0-M6 → Предварительный релиз (milestone)
6.2.8 → Стабильный релиз
3.1.0-SNAPSHOT → Предварительный релиз (snapshot)
2.5.0-RC1 → Предварительный релиз (release candidate)
Примечание о критических изменениях: Инструмент был переименован из get_maven_last_updated_version в get_latest_release и теперь по умолчанию исключает предварительные релизы. Это гарантирует, что производственные приложения по умолчанию получают стабильные версии, при этом сохраняется возможность доступа к предварительным релизам при необходимости.
Сервер обрабатывает различные случаи ошибок:
Неверный формат зависимости
Неверный формат версии
Несуществующие зависимости
Стабильные релизы не найдены (когда включена фильтрация)
Проблемы с подключением к API
Некорректные ответы
Отсутствие информации о версии
Чтобы изменить или расширить сервер:
Внесите изменения в src/index.ts
Пересоберите проект с помощью npm run build
Перезапустите MCP-сервер, чтобы применить изменения
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)
