depaudit-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEPAUDIT_NPM_URL | No | Overrides the npm registry endpoint used for latest-version lookups (for tests or mirrors). | |
| DEPAUDIT_OSV_URL | No | Overrides the OSV.dev API endpoint (for tests or mirrors). Defaults to https://api.osv.dev. | |
| DEPAUDIT_PYPI_URL | No | Overrides the PyPI registry endpoint used for latest-version lookups (for tests or mirrors). | |
| DEPAUDIT_CRATES_URL | No | Overrides the crates.io endpoint used for latest-version lookups (for tests or mirrors). | |
| DEPAUDIT_GOPROXY_URL | No | Overrides the Go module proxy endpoint used for latest-version lookups (for tests or mirrors). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Audit a project's dependencies by reading its lockfiles (uv.lock, poetry.lock, requirements.txt, package-lock.json, pnpm-lock.yaml, yarn.lock, Cargo.lock, go.sum), so transitive dependencies are covered. Start with scan_project(path) for known vulnerabilities (OSV.dev) with fixed-in versions and the dependency path that pulls in each transitive one. suggest_fixes(path) turns that into a minimal upgrade plan and flags breaking bumps. list_outdated(path) shows packages behind their latest release. check_package checks a single name+version, explain_vulnerability explains one advisory id. Everything is read-only: lockfiles are never modified. Needs internet access to api.osv.dev and the package registries.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_projectA | Scan a project's lockfiles for known vulnerabilities (OSV.dev). path: a project directory (lockfiles are found up to 3 levels deep, skipping node_modules and virtualenvs) or one lockfile. Supports uv.lock, poetry.lock, requirements.txt (== pins only), package-lock.json (v2/v3), pnpm-lock.yaml (v6-v9), yarn.lock (v1), Cargo.lock and go.sum. Reports package counts (direct vs transitive) and, worst first, each vulnerable package version with its advisories (GHSA/PYSEC/CVE merged), severity, CVSS score, fixed-in version and, for transitive ones, the dependency path from a direct dependency. limit caps how many vulnerable packages are listed per lockfile. Read-only. |
| suggest_fixesA | Propose a minimal upgrade plan for the vulnerabilities in a project's lockfiles. For each vulnerable package: the smallest version that fixes every advisory (re-checked against OSV so the target is not itself vulnerable), whether the bump is breaking (major, or minor on 0.x), the dependency path for transitive packages, and the command or manifest change to apply it. This tool NEVER modifies files; it only prints the plan. |
| list_outdatedA | List packages in a project's lockfiles that are behind their latest release. Compares each locked version with the latest stable version on PyPI, the npm registry, crates.io or the Go module proxy, and labels the gap MAJOR, MINOR or PATCH (biggest first). By default only direct dependencies are checked; set include_transitive=True for everything (more requests; transitive packages may be held back by their parents' version ranges). Lookups are concurrent and cached; packages whose lookup fails are listed, not hidden. |
| check_packageA | Check one exact package version for known vulnerabilities, without a lockfile. ecosystem: PyPI, npm, crates.io or Go. Also reports the latest release and how far behind this version is. Example: check_package("PyPI", "requests", "2.19.1"). |
| explain_vulnerabilityA | Explain one advisory: summary, severity, affected version ranges, fix, references. id: an OSV-known id such as GHSA-x84v-xcm2-53pg, CVE-2018-18074, PYSEC-2018-28 or RUSTSEC-2020-0071. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool targets a clearly distinct action+resource: scan_project (lockfile vuln scan), check_package (single-version vuln check), list_outdated (version gap listing), explain_vulnerability (advisory detail), and suggest_fixes (remediation plan). The potential overlap between suggest_fixes and list_outdated is resolved by descriptions (fixes for vulnerabilities vs. behind-latest labels). An agent can unambiguously pick the right tool.
All five tools follow a strict verb_noun snake_case pattern: suggest_fixes, scan_project, list_outdated, check_package, explain_vulnerability. No stylistic deviations or mixed conventions.
Five tools is a tight, well-scoped set for a read-only dependency auditor, with no redundant or filler tools. Each operation (scan, check, list, explain, plan) earns its place.
The surface covers the audit lifecycle well: discover vulnerabilities, check individual packages, identify outdated deps, explain advisories, and plan fixes. The main intentional gap is any apply/upgrade operation (explicitly read-only), and there's no batch or export/report tool, but core workflows are complete.