Skip to main content
Glama
dependency-audit-mcp

dependency-audit-mcp

by Anicodeth

dependency-audit-mcp

Give your coding agent real eyes on how stale and risky your dependencies are.

An MCP server that audits a project's npm dependencies against the live registry. Feed it a package.json and the agent gets a per-dependency report: how far behind latest each package is (patch / minor / major), how many versions behind, whether it's deprecated, and its license — real facts, not a guess from training data.

Why this exists

Ask an agent "what's outdated here?" and it will happily hallucinate version numbers. The npm registry knows the truth. This server hands the agent that truth in one call, and pairs naturally with breaking-changes-mcp — audit to find what's behind, then check the breaking changes before you bump.

Related MCP server: npm-mcp

Tools

Tool

What it does

audit_dependencies

Full report from a package.json: freshness gap, versions-behind, deprecation, and license for every dependency, sorted worst-first with deprecated/major callouts.

check_package

One-off lookup for a single package — latest version, how far behind your range is, deprecation, license.

No API key required.

Quick start

npx dependency-audit-mcp

Claude Code

claude mcp add dependency-audit -- npx -y dependency-audit-mcp

Claude Desktop / Cursor / Windsurf / any MCP client

{
  "mcpServers": {
    "dependency-audit": {
      "command": "npx",
      "args": ["-y", "dependency-audit-mcp"]
    }
  }
}

Example prompts

  • "Audit this repo's dependencies — what's outdated or deprecated?" (agent reads package.json, calls audit_dependencies)

  • "Is request deprecated? What should I use instead?"

  • "How far behind is my ^4.17.0 of lodash?"

Output at a glance

✓ up-to-date   ·  patch   △ minor   ⚠ major behind

  package                      range        → latest       gap         behind     license
⚠ react                        ^17.0.2      → 19.1.0        major       210        MIT
△ zod                          ^3.20.0      → 3.23.8        minor       28         MIT
⚠ request                      ^2.88.0      → 2.88.2        patch                  Apache-2.0  DEPRECATED

Config

Env var

Default

Purpose

NPM_REGISTRY

https://registry.npmjs.org

Override for private/mirror registries.

How it works

package.json text
   │
   ├─ parse dependencies / devDependencies (+ optional peer)
   ├─ for each dep → npm registry metadata (bounded concurrency)
   ├─ semver-diff installed lower-bound vs dist-tags.latest
   └─ collect deprecation + license ──► sorted, worst-first report

Non-registry ranges (workspace:, file:, git+…, *) are listed as skipped rather than guessed at.

Develop

npm install
npm run build
node dist/index.js

License

MIT © Anicodeth

Available Tools

2 tools
audit_dependenciesAudit a project's npm dependenciesA

Given the contents of a package.json, report every dependency's freshness against the npm registry: how far behind latest it is (patch/minor/major), how many versions behind, whether it's DEPRECATED, and its license. Reach for this when asked to 'update dependencies', 'check what's outdated', 'is anything deprecated', or before a dependency bump — it gives the agent real registry facts instead of guessing from stale training data. Read the repo's package.json and pass its full text as packageJson.

Inputs: packageJson (required), includeDev, includePeer.

check_packageCheck a single package's statusA

Look up one npm package: its latest version, how far a given range/version is behind, deprecation status, and license. Use for a quick one-off check ('is X deprecated?', 'what's the latest Y?', 'how far behind is my Z?') without needing a whole package.json.

Inputs: name (required), range.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.2/5.0

    Scored across 2 tools

    Disambiguation5/5

    The two tools have clearly distinct scopes: audit_dependencies evaluates an entire package.json against the registry, while check_package focuses on a single package. There is no ambiguity about which tool to use for a given request.

    Naming Consistency5/5

    Both tools follow the same verb_noun pattern with lowercase and underscores: 'audit_dependencies' and 'check_package'. The naming is consistent and predictable.

    Tool Count3/5

    With only two tools, the server feels thin for a general dependency-audit purpose, but it does cover the two primary use cases: whole-project audit and single-package lookup. The count is borderline but not unreasonable for such a narrow domain.

    Completeness4/5

    The core auditing operations are covered: checking a full dependency set and checking an individual package. Minor gaps exist, such as lack of support for lockfiles or batch version comparisons, but these are workarounds and not severe.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers