mcp-maven-deps

get_dependency_vulnerabilities

Read-only

Checks Maven dependencies for known vulnerabilities using OSV.dev, returning CVEs and advisory upgrade candidates for pinned versions.

Instructions

Check dependencies for known vulnerabilities using the OSV.dev database. Each dependency requires a pinned version — OSV lookups are version-specific and version-less coordinates are not queried. An empty vulnerabilities list means no known CVE/GHSA advisory was found for that coordinate+version in OSV.dev; it is NOT a safety guarantee (OSV coverage is incomplete and reporting lags real-world disclosure). When ≥1 vulnerability is found, a per-dependency safeUpgrade candidate is synthesized from the already-fetched fixed-version data (the highest fixed version across all known CVEs) — ADVISORY ONLY, a candidate to verify, never a guaranteed-safe pin; fixesAllKnown is false when at least one CVE has no known fix.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`projectPath`	No	Project root used to resolve declared repositories. Defaults to the current working directory.
`dependencies`	Yes	Dependencies to check, each with a pinned version (required).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`results`	Yes
`capabilityUnavailable`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Oct 6, 2026

TDQS

A4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnlyHint/openWorldHint annotations: it explains that an empty list is not a safety guarantee (incomplete OSV coverage, reporting lag), that safeUpgrade is synthesized from fixed-version data and is advisory-only, and that fixesAllKnown=false signals an unfixed CVE. These are exactly the interpretive caveats an agent needs to avoid over-claiming safety.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose before the caveats, and every sentence carries substantive meaning (version pinning, empty-list semantics, safeUpgrade advisories). The safeUpgrade sentence is dense and clause-heavy, but it is load-bearing rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be re-specified, yet the description still supplies the interpretation rules (empty = no advisory, not safe; safeUpgrade = verify, not a guaranteed pin). For a vulnerability tool whose results are easy to misread, this is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented. The description reinforces the pinned-version requirement and notes version-less coordinates are not queried, but adds no syntax or format detail beyond what the schema states — the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Check) and resource (dependencies for known vulnerabilities) and names the data source (OSV.dev), which meaningfully separates it from generic scanners. It never names a sibling such as get_vulnerability_paths or audit_project_dependencies, so an agent still has to infer which related tool applies, keeping it short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It supplies a real usage precondition (each dependency needs a pinned version, version-less coordinates are not queried), which is genuine when-to-use guidance. However there is no when-not or explicit alternative — nothing tells the agent to prefer scan_project_dependencies or get_vulnerability_paths in a given situation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.