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, or build.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:artifactId or groupId:artifactId:version as 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:

Default to analyze_project_health when the user says "check my dependencies" or pastes a project dependency set.

When the user provides raw pom.xml content, prefer the POM-aware tools: analyze_pom_dependencies resolves and classifies effective versions (EXPLICIT / MANAGED / EXPLICIT_OVERRIDE) and surfaces multi-BOM conflicts; recommend_pom_upgrades returns an actionable upgrade plan. Both walk the parent chain, apply <dependencyManagement>, and resolve <scope>import</scope> BOMs; pass sideloadedPoms for monorepo siblings or unreleased parents.

Use check_multiple_dependencies for candidate sets without current versions. Use compare_dependency_versions for single-coordinate upgrade decisions. Use analyze_project_health for broad audits, not every single dependency question.

Workflow

1. Extract dependencies from user input or the build file
2. Pick the narrowest tool that answers the request
3. Report the result in decision-oriented language:
   • what is current
   • what changed
   • what is safe to do now
   • what needs manual review

Whole-POM upgrades and bot-like maintenance

When the user hands you a raw pom.xml and wants to know what to upgrade ("what can I safely bump?", scheduled maintenance, dependency-bot replacement), lead with recommend_pom_upgrades:

• mode: MINOR_PATCH (default) keeps major upgrades out of the safe path
• apply deterministicActions[] directly — these are mechanical <version> edits:
  • explicit_bump — declared dependencies
  • bom_bump — user-controllable BOMs
  • managed_decl_bump — direct, non-import <dependencyManagement> entries the input POM owns, including platform/master POMs with no normal <dependencies> usage (3.2.0+)
  • plugin_dep_bump — direct dependencies under build/plugins and build/pluginManagement, such as com.puppycrawl.tools:checkstyle inside maven-checkstyle-plugin (3.2.0+)
• Validate the action against the current XML location and version before editing. Property edits must remain consistent across all references; stop for stale or ambiguous actions.
• owned-declaration actions carry edit-location metadata (editTarget, propertyName, declaredIn) telling you whether to edit a literal <version> or the backing property; plugin_dep_bump also names the owner plugin and build path, so apply the edit inside that plugin block rather than at the top level
• route needsAttention[] (majors, multi-BOM conflicts, explicit overrides) to human or LLM review; each entry carries the Maven Central latest for context

One call returns everything mechanical plus the review queue — no per-coordinate fan-out for whole-POM flows. Reach for analyze_pom_dependencies first when the user wants the raw resolution ("what does my POM actually resolve to?") without recommendations.

Single-coordinate upgrade decisions

For a specific dependency ("should I upgrade X from 2.7 to 3.2?"), prefer compare_dependency_versions with:

• includeSecurityScan: true
• stabilityFilter: 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

If the user asks whether a dependency is safe:

1. use compare_dependency_versions when remediation guidance matters
2. use analyze_release_patterns when maintenance risk matters
3. 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:

1. use Maven Tools MCP first for dependency facts
2. if raw Context7 tools are available in the current tool list, use them directly
3. otherwise, if standalone Context7 tools are available, use them
4. otherwise, use WebSearch and WebFetch for official docs, release notes, and migration guides
5. 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:latest is the default when raw Context7 tools should be exposed through the same server
• arvindand/maven-tools-mcp:latest-noc7 is the clean option when documentation is handled separately

Only discuss installation when the tools are unavailable.

Recovery

License: MIT Requires: Maven Tools MCP server Pairs with: context7 skill or standalone Context7 tools for documentation-heavy follow-up