Maven Tools
Use this skill to ground JVM dependency decisions in live Maven Central data.
This is an execution skill. Use Maven Tools MCP first for dependency facts, then do the reasoning in-model. Assume Maven Tools MCP is already configured; only discuss setup if the tools are unavailable.
When to Use
Activate when the user asks about:
- Java, Kotlin, Scala, or JVM dependencies
- Maven, Gradle,
pom.xml,build.gradle, orbuild.gradle.kts - latest versions, upgrades, CVEs, licenses, dependency age, or release history
- whether a dependency is safe, current, stale, or worth upgrading
Core Boundary
Use Maven Tools MCP for version, security, license, freshness, and release-pattern facts from Maven Central.
- Do the reasoning in-model: recommend next steps, call out risk, and separate safe-now actions from manual-review items.
- Normalize dependency inputs to
groupId:artifactIdorgroupId:artifactId:versionas needed. - For recommendation questions, evaluate concrete candidates with Maven Tools first, then add documentation context before making a strong call.
- Do not use Maven metadata alone to decide library popularity, framework fit, migration effort, or performance tradeoffs.
Tool Selection
Choose the narrowest tool that matches the request:
| Intent | Tool | Default Parameters |
|---|---|---|
| latest version lookup | get_latest_version | stabilityFilter: PREFER_STABLE |
| check exact version | check_version_exists | none |
| bulk candidate check (no current versions) | check_multiple_dependencies | stabilityFilter: PREFER_STABLE |
| upgrade analysis (with current versions) | compare_dependency_versions | includeSecurityScan: true, stabilityFilter: STABLE_ONLY |
| age/freshness | analyze_dependency_age | use project-appropriate threshold |
| maintenance signal | analyze_release_patterns | monthsToAnalyze: 24 |
| release history | get_version_timeline | versionCount: 20 |
| full project audit | analyze_project_health | includeSecurityScan: true, includeLicenseScan: true, stabilityFilter: PREFER_STABLE |
Default to analyze_project_health when the user says "check my dependencies" or pastes a project dependency set.
Use check_multiple_dependencies for candidate sets without current versions. Use compare_dependency_versions for upgrade decisions on current versions. Use analyze_project_health for broad audits, not every single dependency question.
Workflow
- Extract dependencies from user input or the build file
- Pick the narrowest tool that answers the request
- Report the result in decision-oriented language:
- what is current - what changed - what is safe to do now - what needs manual review
For upgrade questions, prefer compare_dependency_versions with:
includeSecurityScan: truestabilityFilter: STABLE_ONLY
Then interpret the result conservatively:
- patch and minor updates are the default safe path
- major updates should be treated as manual review unless the user explicitly wants a breaking upgrade
When compare_dependency_versions returns same_major_stable_fallback:
- treat the top-level major upgrade as the long-term path
- treat the fallback as the safest immediate upgrade target
- surface both, but recommend the fallback first for conservative maintenance workflows
This is especially important for "safe update" or bot-like maintenance flows.
If the user asks whether a dependency is safe:
- use
compare_dependency_versionswhen remediation guidance matters - use
analyze_release_patternswhen maintenance risk matters - combine the two instead of relying only on "latest version" checks
Documentation Handoff
When the answer needs migration guides, API details, or library usage patterns, add documentation context before giving a strong recommendation.
Use this order:
- use Maven Tools MCP first for dependency facts
- if raw Context7 tools are available in the current tool list, use them directly
- otherwise, if standalone Context7 tools are available, use them
- otherwise, use
WebSearchandWebFetchfor official docs, release notes, and migration guides - if no documentation path is available, say dependency facts are available but deeper doc lookup is not
Use this especially for:
- major upgrades
- migration planning
- recommendation-style comparisons between candidate libraries
Less Helpful / Out of Scope
- private artifact repositories that are not mirrored through Maven Central
- non-JVM ecosystems that do not use Maven coordinates
- trivial one-off lookups where the exact dependency and decision are already obvious
- recommendation questions driven mostly by ecosystem adoption or benchmarks unless you also add docs and broader research
Setup Assumption
Assume the user already has Maven Tools MCP configured.
arvindand/maven-tools-mcp:latestis the default when raw Context7 tools should be exposed through the same serverarvindand/maven-tools-mcp:latest-noc7is the clean option when documentation is handled separately
Only discuss installation when the tools are unavailable.
Recovery
| Issue | Action |
|---|---|
| MCP tools unavailable | Tell the user Maven Tools MCP is not configured and point them to https://github.com/arvindand/maven-tools-mcp. Mention :latest when they want raw Context7 in the same server, or :latest-noc7 when docs are handled separately. |
| Dependency not found | Verify groupId:artifactId format and check whether the artifact is on Maven Central. |
| Raw Context7 tools unavailable | Use standalone Context7 tools if available; otherwise fall back to WebSearch and WebFetch. |
| No documentation path is available | Say dependency facts are available but deeper migration or API docs are not available in the current environment. |
| Security scan is incomplete or slow | Use the partial result, say CVE data may be incomplete, and continue with version/maintenance guidance. |
| Version type is unclear | Treat it as unstable and prefer a known stable release. |
License: MIT Requires: Maven Tools MCP server Pairs with: context7 skill or standalone Context7 tools for documentation-heavy follow-up