Maven Tools Skill | Agent Skills

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:

| 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 (single coordinate, with current version) | compare_dependency_versions | includeSecurityScan: true, stabilityFilter: STABLE_ONLY | | whole-POM upgrade plan (raw pom.xml) | recommend_pom_upgrades | mode: MINOR_PATCH | | resolve effective POM versions (raw pom.xml) | analyze_pom_dependencies | none | | age/freshness | analyze_dependency_age | use project-appropriate threshold | | maintenance signal / release history | analyze_release_patterns | monthsToAnalyze: 24 | | 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.

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

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

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 deterministic_actions[] directly — these are mechanical <version> edits (explicit_bump for declared deps, bom_bump for user-controllable BOMs)
route needs_attention[] (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:

use compare_dependency_versions when remediation guidance matters
use analyze_release_patterns when 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 WebSearch and WebFetch for 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: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

| 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

Agent Skills: Maven Tools

Install this agent skill to your local

Skill Files