Maven依存関係のバージョンを確認するためのツールを提供するMCP（Model Context Protocol）サーバーです。このサーバーにより、LLMはMaven依存関係を検証し、Maven Central Repositoryから最新バージョンを取得できるようになります。
npmを使用して、このMCPサーバーをグローバルにインストールできます：
npm install -g mcp-maven-depsまたは、npxを使用して直接実行することもできます：
npx mcp-maven-depsSmithery を介してClaude Desktop用のMaven Dependencies Serverを自動的にインストールするには：
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 Central Repositoryデータへのリアルタイムアクセス
複数のビルドツール形式（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"
}
}
}サーバーは2つのトランスポートモードをサポートしています：
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=3000MCP設定で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依存関係のバージョンをデプロイ順（最新のものから）に一覧表示します。オプションでプレリリースフィルタリングと深さ制御が可能です。出力は1行につき1バージョンです。
入力スキーマ：
{
"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 Centralの 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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Bigsy/maven-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
