一个提供检查 Maven 依赖版本工具的 MCP (Model Context Protocol) 服务器。该服务器使 LLM 能够验证 Maven 依赖项并从 Maven 中央仓库检索其最新版本。
您可以使用 npm 全局安装此 MCP 服务器：
npm install -g mcp-maven-deps或者使用 npx 直接运行：
npx mcp-maven-deps要通过 Smithery 自动为 Claude Desktop 安装 Maven 依赖服务器：
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 坐标，包括打包方式和分类器
实时访问 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在 MCP 设置中使用 SSE 传输时：
{
"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 中央仓库上的 maven-metadata.xml (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)
