Integrates Trivy vulnerability scanning for Java projects to detect CVEs and security issues in dependencies.
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., "@mvn-mcp-server Check if Spring Core 5.3.0 has any updates available"
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.
AI-powered Maven dependency management through natural language.
Maven MCP Server enables AI assistants to interact with Maven Central repository, providing comprehensive tools for version checking, security scanning, and dependency analysis—all through conversational interfaces.
Traditional Maven workflow:
mvn versions:display-dependency-updates # Check all dependencies
# Read through XML output, manually check each update
# Manually verify security advisories
# Repeat for each project...With Maven MCP Server:
You: "Scan this project for vulnerabilities and create an update plan"
AI: ✅ Found 3 critical CVEs, 12 outdated dependencies
📋 Created prioritized update plan with file locations
🎯 Ready to implementKey Benefits:
Natural language instead of complex Maven commands
Single workflow combining version checks + security + planning
AI-assisted decision making with full context
Intelligent caching for faster repeated queries
Enterprise-ready with audit trails and traceability
Related MCP server: Maven Decoder MCP Server
Category | Capabilities |
Version Management | Check single or batch dependency versions • Discover available updates (major/minor/patch) • List version history grouped by tracks |
Security Scanning | Integrate Trivy vulnerability scanning • CVE detection with severity filtering • Multi-module project support • Profile-based scanning for multi-cloud deployments |
Enterprise Workflows | Guided dependency triage analysis • Actionable remediation planning • Complete audit trail with CVE traceability |
AI-Optimized | Single-call comprehensive responses • Batch operations for efficiency • Intelligent caching |
Prerequisites:
mcp add mvn-mcp-server -- uvx mvn-mcp-serverOr add manually to your MCP configuration:
{
"mcpServers": {
"mvn-mcp-server": {
"command": "uvx",
"args": ["mvn-mcp-server"]
}
}
}"Check if Spring Core 5.3.0 has any updates available"
"Scan my Java project for security vulnerabilities"
Install Trivy for vulnerability detection:
# macOS
brew install trivy
# Linux
# See: https://aquasecurity.github.io/trivy/latest/getting-started/installation/Without Trivy, version checking and dependency analysis work normally. Security scanning tools will gracefully report Trivy unavailable.
Security Note: All processing happens locally. No source code or project data is sent to external services (except public Maven Central API queries for version information).
Tool | Description | Example Query |
check_version_tool | Check single dependency version |
|
check_version_batch_tool | Check multiple dependencies |
|
list_available_versions_tool | List version history by tracks |
|
scan_java_project_tool | Security scan with Trivy |
|
analyze_pom_file_tool | Analyze POM file |
|
Prompt | Description | Example Query |
list_mcp_assets_prompt | Show all capabilities with examples |
|
triage | Complete dependency and vulnerability analysis |
|
plan | Generate actionable remediation plan |
|
This project is licensed under the MIT License - see LICENSE for details.
Analyze a single Maven POM file without scanning the entire workspace
| Name | Required | Description | Default |
|---|---|---|---|
| pom_file_path | Yes | ||
| include_vulnerability_check | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral transparency. It only says 'analyze' without specifying read-only/write nature, side effects, error handling, or any other behavior beyond the basic action.
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 with no wasted words. It is concise, though slightly too minimal for the amount of information needed.
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, no output schema, and zero schema descriptions, the description is critically incomplete. It does not cover input parameters, output, or any behavioral details, leaving the agent underinformed.
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?
With 0% schema description coverage, the description fails to add any meaning to the two parameters. It does not explain what pom_file_path should be formatted or what include_vulnerability_check controls.
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 'analyze' and the resource 'single Maven POM file'. It also explicitly distinguishes from scanning the entire workspace, which differentiates it from siblings like scan_java_project_tool.
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 hints at when to use this tool (to avoid full workspace scan) but does not explicitly state when not to use it or name alternative tools. The guidance is implied but not direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Process multiple Maven dependency version checks in a single batch request
| Name | Required | Description | Default |
|---|---|---|---|
| dependencies | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors (e.g., read-only, destructive, rate limits). It only states it processes checks, lacking details on side effects, response, or error handling.
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, concise but sacrificing necessary detail. It is front-loaded but not sufficiently informative.
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 batch processing and nested object parameters, the description fails to explain input structure, output expectations, or behavior. It is incomplete for safe and effective tool invocation.
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 coverage is 0%, so the description must explain the 'dependencies' array structure. It only hints at Maven dependencies but doesn't specify required fields (e.g., groupId, artifactId) or format.
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 processes multiple Maven dependency version checks in a batch, distinguishing it from the sibling 'check_version_tool' which likely handles single checks.
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 batch tool versus alternatives like 'check_version_tool' or other siblings. The user is left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a Maven version and get all version update information in a single call
| Name | Required | Description | Default |
|---|---|---|---|
| dependency | Yes | ||
| version | Yes | ||
| packaging | No | jar | |
| classifier | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits like whether the tool is read-only, requires authentication, or has rate limits. It only promises 'version update information' without specifics.
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, but it is underspecified and lacks structure. It front-loads the purpose but omits crucial details.
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 4 parameters, no output schema, and no annotations, the description is far from complete. It does not explain what 'version update information' entails or how parameters affect the call.
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 0%, and the description adds no meaning beyond the parameter names. The terms 'dependency', 'version', 'packaging', and 'classifier' are left undefined.
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 checks a Maven version and retrieves version update information in a single call. However, it does not explicitly differentiate from sibling tools like check_version_batch_tool or list_available_versions_tool.
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, such as batch checking or listing versions. There is no mention of context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available versions of a Maven artifact grouped by minor version tracks
| Name | Required | Description | Default |
|---|---|---|---|
| dependency | Yes | ||
| version | Yes | ||
| packaging | No | jar | |
| classifier | No | ||
| include_all_versions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions grouping by minor version tracks but omits critical behavioral details like side effects, network calls, or prerequisites.
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?
Single sentence is concise but too brief given the tool's 5 parameters and missing schema descriptions.
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?
No output schema, no annotations, and incomplete parameter info; description fails to explain return format or detailed grouping behavior.
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 0%, and the description provides no explanation for any of the 5 parameters (dependency, version, packaging, classifier, include_all_versions).
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?
Description states 'List all available versions of a Maven artifact grouped by minor version tracks' — specific verb, resource, and grouping, clearly distinguishing from siblings like check_version_tool.
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 on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Java-specific tool for scanning Maven projects for vulnerabilities
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | ||
| include_profiles | No | List of Maven profiles to activate | |
| scan_all_modules | No | ||
| scan_mode | No | workspace | |
| pom_file | No | ||
| severity_filter | No | List of severity levels to include (CRITICAL, HIGH, MEDIUM, LOW) | |
| max_results | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits such as read-only vs destructive, authentication requirements, or side effects. The description is too brief to inform the agent about tool 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?
Single sentence, concise, but lacks structure and detail. While brief, it sacrifices informativeness for brevity.
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?
With 8 parameters, no output schema, and low schema coverage, the description is insufficient. It does not cover pagination, scan modes, or output format, leaving significant gaps.
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 low (25%), and the description does not explain any parameters. It fails to add meaning beyond the schema for the 8 parameters.
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?
Description clearly states it scans Maven projects for vulnerabilities, specifying Java and Maven. It implies a whole-project scan, but does not explicitly differentiate from sibling tools like analyze_pom_file_tool.
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 on when to use this tool vs alternatives like analyze_pom_file_tool or check_version_tool. The description lacks context for usage scenarios.
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.
v2.3.0analyze_pom_file_toolcheck_version_batch_toolcheck_version_toollist_available_versions_toolscan_java_project_toolScored across 5 tools
Tools are mostly distinct: analyze POM, check version (single and batch), list versions, and scan vulnerabilities. The two version check tools (single and batch) could cause minor confusion, but their purposes are clearly separated by batch vs single.
All tools follow a consistent verb_noun_tool pattern (e.g., analyze_pom_file_tool, check_version_tool). The naming is uniform and predictable, making it easy for an agent to understand the action and target.
5 tools is well-suited for a Maven analysis server. Each tool covers a distinct area (POM analysis, version checking, version listing, vulnerability scanning) without being too sparse or overwhelming.
The toolset covers core Maven analysis tasks, but lacks tools for modifying POM files or performing dependency updates. This is a minor gap for a server focused on analysis, as agents can work around missing actions.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
GibsonAI MCP server: manage your databases with natural language
The OpenZeppelin Solidity Contracts MCP server integrates OpenZeppelin's security and style rules into AI-driven development workflows, enabling AI assistants to generate safe, correct, and production-ready smart contracts. It automatically validates generated code against OpenZeppelin standards (including imports, modifiers, naming conventions, and security checks) and supports various contract types including ERC-20, ERC-721, ERC-1155, Stablecoins, RWA, Governor, and Account contracts through prompt-driven workflows.
MCP Server for JFrog, providing tools for development and artifact management.
