Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@maven-mcp get latest version of org.springframework.boot:spring-boot-starter"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Maven Central - search artifacts, check versions, and analyze dependencies.
You need to authenticate with GitHub Packages. See SETUP.md for detailed instructions.
Add to your MCP settings (~/.cursor/mcp.json or ~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"maven-mcp": {
"command": "npx",
"args": ["-y", "@awin/maven-mcp"]
}
}
}Note: Make sure you have configured GitHub Packages authentication before running this command.
Related MCP server: artifactory-mcp
getLibraryVersionsGet all available versions for a Maven artifact.
{ "groupId": "org.springframework.boot", "artifactId": "spring-boot-starter" }getLatestVersionGet only the latest version.
{ "groupId": "org.springframework.boot", "artifactId": "spring-boot-starter" }searchArtifactsSearch Maven artifacts by keyword.
{ "query": "spring-boot", "limit": 5 }getDependenciesGet dependencies for a specific version.
{ "groupId": "org.springframework.boot", "artifactId": "spring-boot-starter", "version": "3.3.0" }compareVersionsCompare dependencies between versions.
{ "groupId": "org.springframework.boot", "artifactId": "spring-boot-starter", "fromVersion": "3.2.0", "toVersion": "3.3.0" }Real-time data from Maven Central (no indexing delays)
Direct queries to maven-metadata.xml
Search, version lookup, and dependency analysis
npm install
npm run build
node dist/index.jsThis package is automatically published to GitHub Packages when a new release is created. To publish manually:
npm run build
npm publishMake sure you have the proper permissions in the @awin organization.
MIT - see LICENSE
Compare dependencies between two versions
| Name | Required | Description | Default |
|---|---|---|---|
| groupId | Yes | Maven group ID | |
| toVersion | Yes | New version | |
| artifactId | Yes | Maven artifact ID | |
| fromVersion | Yes | Old version |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. The description states that it compares dependencies but does not specify what the comparison includes (e.g., added, removed, upgraded dependencies), whether there are any side effects, or if it requires specific permissions or network access. This is minimal but acceptable given that 'compare' implies a read-only analysis.
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 very concise at seven words, which is efficient. However, it could be even more effective with a bit more context about what the comparison reveals. Still, it is appropriately sized and front-loaded with the key action.
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 complexity of a dependency comparison tool with four required parameters and no output schema, the description is minimally adequate. It does not explain what the output looks like or how to interpret the comparison results. With no output schema, the description should provide more details about the return values to be truly complete.
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 baseline is 3. The description adds value by stating that it compares dependencies between two versions, which clarifies the role of 'fromVersion' and 'toVersion' as the old and new versions for comparison. However, it does not provide guidance on how to interpret the output or how the groupId and artifactId are used. The additional context justifies a slight increase above baseline.
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 'Compare dependencies between two versions' clearly states the verb ('compare') and the resource ('dependencies between two versions'). It effectively distinguishes itself from sibling tools like getLatestVersion and getDependencies, though it does not explicitly differentiate itself.
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 for comparing dependencies, but does not provide guidance on when to use this tool versus when to use siblings like getDependencies (which likely fetches dependencies for a single version) or searchArtifacts. There are no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get dependencies for a specific artifact version
| Name | Required | Description | Default |
|---|---|---|---|
| groupId | Yes | Maven group ID | |
| version | Yes | Version | |
| artifactId | Yes | Maven artifact ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden of behavioral disclosure. It only says 'Get dependencies', which implies a read operation, but fails to mention whether authentication is required, how errors are handled (e.g., missing version), response format, or any side effects. The description is critically insufficient for understanding the tool's behavior.
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 sentence, which is concise in length but not in value. It is under-specified, lacking essential details. Brevity at the expense of completeness is not effective conciseness; the description should be longer to provide meaningful guidance.
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 complexity (3 required parameters, no output schema, no annotations), the description is extremely incomplete. It does not explain what the output looks like (e.g., list of dependency coordinates), error conditions, pagination, or how to interpret results. The description fails to provide sufficient context for an AI agent to use the tool correctly.
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 each parameter having a brief description (e.g., 'Maven group ID'). The tool description adds no additional meaning beyond what the schema already provides. Per the rubric, this warrants a baseline of 3, as 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 action ('Get dependencies') and the resource ('for a specific artifact version'). It distinguishes from sibling tools like 'getLatestVersion' and 'searchArtifacts', which deal with different aspects of artifacts. The verb+resource is specific enough to convey the tool's primary function.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not specify prerequisites, context (e.g., when you need to resolve dependencies), or when not to use it. The sibling tools are listed externally but not differentiated in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get only the latest version of an artifact
| Name | Required | Description | Default |
|---|---|---|---|
| groupId | Yes | Maven group ID | |
| artifactId | Yes | Maven artifact ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states that it retrieves the latest version, but does not disclose behavior if the artifact is missing, what determines 'latest', or any side effects. For a read-only operation, minimal transparency is acceptable but still insufficient.
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 concise sentence, front-loaded with the key action. It is not overly verbose, but could include a bit more context (e.g., 'Maven artifact') without losing conciseness.
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 absence of an output schema and annotations, the description lacks details on return format, error handling, or version selection logic. For a tool with two parameters and a specific purpose, more context is needed for an agent to use it correctly.
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% (both params have descriptions). The description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate since the schema already documents the parameters adequately.
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 'Get only the latest version of an artifact' clearly states the verb and resource. The name and sibling tools (searchArtifacts, getDependencies, etc.) imply differentiation, though the description does not explicitly mention that this is for Maven artifacts or contrast with alternatives.
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?
No guidance is provided on when to use this tool vs. siblings (e.g., when you need a single latest version vs. searching all artifacts or comparing versions). The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all available versions for a Maven library
| Name | Required | Description | Default |
|---|---|---|---|
| groupId | Yes | Maven group ID | |
| artifactId | Yes | Maven artifact ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only implies a read operation ('Get') but discloses no behavioral details: no mention of return format, pagination, rate limits, authentication, or error behavior. The description is minimal and does not compensate for missing annotations.
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, concise sentence that directly states the tool's purpose. No extraneous words or redundant information. It is efficiently structured.
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?
The description is minimally adequate given the tool's simplicity and full schema coverage. However, it omits details about the output format, potential limit on number of versions returned, and error conditions. With no output schema, more explanation would improve usability.
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%—both parameters already have clear descriptions in the input schema. The tool description adds no additional meaning beyond what the schema provides. Baseline is 3, and no extra value is added.
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 'Get' and the resource 'all available versions for a Maven library'. This distinguishes the tool from its siblings (e.g., getLatestVersion returns only the latest, searchArtifacts is broader) without needing explicit references.
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 searchArtifacts or getLatestVersion. It lacks any contextual hints about prerequisites, scope, or preference criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Maven artifacts by keyword
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default: 20) | |
| query | Yes | Search query | |
| fetchRealLatest | No | Fetch real-time latest version (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'search by keyword' but doesn't mention side effects (likely none), authentication needs, rate limits, or what happens on failure. The absence of any behavioral context leaves significant gaps for a search tool.
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 at 6 words, which is very concise and front-loaded. It sacrifices no clarity for brevity, though it could be slightly more informative without becoming verbose.
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 has 3 parameters, no output schema, and no annotations, the description is somewhat underpowered. It covers the basic purpose but lacks explanation of return format, default behavior for 'fetchRealLatest', or error handling, making it minimally complete for a search tool.
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 description doesn't need to add much. It does not elaborate on parameters beyond the schema, but the schema's descriptions ('Max results', 'Search query', 'Fetch real-time latest version') are adequate. Baseline 3 is appropriate as the description adds no extra semantic value.
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 tool searches for Maven artifacts by keyword, using the verb 'search' and resource 'Maven artifacts'. While it doesn't differentiate from siblings like 'getLatestVersion' or 'getDependencies', it implies a general search capability, which is distinct enough to avoid confusion.
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?
No guidance is provided on when to use this tool versus siblings. For example, it does not explain that 'searchArtifacts' is for finding artifacts by keyword while 'getLatestVersion' retrieves the latest version of a specific artifact. The agent is left to infer usage from names alone.
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.3compareVersionsgetDependenciesgetLatestVersiongetLibraryVersionssearchArtifactsScored across 5 tools
Each tool has a clear, distinct purpose: search for artifacts, get latest version, get all versions, get dependencies for a specific version, and compare dependencies between two versions. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in camelCase (e.g., searchArtifacts, getLatestVersion). The naming is predictable and uniform across the set.
With 5 tools, the server is well-scoped for Maven artifact operations. It covers essential tasks without being too sparse or bloated, making it easy for an agent to navigate.
The tool set covers core Maven artifact workflows: search, version listing, dependency retrieval, and version comparison. Missing are artifact metadata details (e.g., description, licenses) and transitive dependency analysis, but the surface is mostly complete for common use cases.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Ask any GitHub repository a question. Get source-backed answers.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Versioned documentation registry and semantic search for AI tools and coding assistants.
