npm Package & Dependency Vulnerability Checker (MCP)

If you're an AI coding agent (or the developer behind one) deciding whether to add or keep a package — and want to know about vulnerabilities buried in its dependencies, not just the package itself — this Actor cross-references npm's registry, OSV.dev, and GitHub Security Advisories on your behalf, so you don't have to check multiple vulnerability databases by hand. Runs as a remote Model Context Protocol (MCP) server for Claude, Cursor, and other MCP clients.

What you get, per check:

• A package's health snapshot — last publish date, maintainer count, license — plus its known vulnerabilities, in one call (check_package_health)
• CVE-matched findings cross-referenced across OSV.dev and GitHub Advisories, enriched with CWE classification and patch-version info when both sources agree (check_vulnerabilities)
• A full package-lock.json dependency-tree scan that catches vulnerabilities buried in indirect dependencies, not just the package you name — the class of incident behind cases like event-stream (check_dependency_tree_risk)

Real example — check_vulnerabilities("lodash", "4.17.15"):

{
  "totalVulnerabilities": 6,
  "criticalOrHighCount": 3,
  "vulnerabilities": [
    {
      "cveId": "CVE-2021-23337",
      "summary": "Command Injection in lodash",
      "severityLevel": "Critical",
      "source": "both",
      "patchInfo": [{ "vulnerableVersionRange": "< 4.17.21", "firstPatchedVersion": "4.17.21" }]
    }
  ]
}

(Full response shape for all 3 tools is in the response-fields table under "What does this Actor do?" below.)

Pay-per-event pricing. Connection details and each tool's full parameter/response schema are further down this page.

⚠️ Disclaimer (please read)

• Vulnerability data comes from OSV.dev and GitHub Security Advisories — this Actor doesn't run its own security research. Coverage is only as complete and current as those two sources.
• Severity levels are an approximation, not an official CVSS score: they're estimated from the confidentiality/integrity/availability impact letters in the raw CVSS vector string, not the formal CVSS calculation formula.
• check_package_health/check_vulnerabilities only look at the single package you name — they don't see its dependencies. Use check_dependency_tree_risk with a package-lock.json to cover transitive (indirect) dependency risk too.
• check_dependency_tree_risk is bounded on large projects: only the first 100 packages found in the lockfile are scanned, and full details are returned only for the top 20 findings at Medium severity or above (a summary count covers everything found either way).
• Without a GITHUB_TOKEN/GH_TOKEN environment variable set, GitHub's Advisories API is rate-limited to 60 requests/hour (vs. 5000/hour authenticated) — this affects the Actor deployment's own rate limit, not something a caller can configure per request.
• Always verify findings against the official advisory before acting on them (e.g. before blocking a release or filing a security report) — this Actor is a research aid, not a certified audit.

How to use

This Actor exposes 3 MCP tools: check_package_health, check_vulnerabilities, and check_dependency_tree_risk. Connect an MCP client to its standby URL using the streamable HTTP transport, passing your Apify API token as a Bearer token:

Authorization: Bearer <YOUR_APIFY_API_TOKEN>

See Apify's MCP documentation for how to point Claude, Cursor, or another MCP client at an Apify Actor's standby MCP endpoint.

What does this Actor do?

• check_package_health: takes a packageName. Reads npm registry metadata to flag maintenance risk (days since last publish, maintainer count, release frequency) and also fetches known vulnerabilities for the package's latest version.
• check_vulnerabilities: takes a packageName (and optionally a version). Queries OSV.dev and GitHub Security Advisories, merges matching results by CVE ID (tagged source: "both" when both sources agree), and enriches GHSA matches with CWE classification and patch-version info.
• check_dependency_tree_risk: takes the full text of a package-lock.json (lockfileVersion 1, 2, or 3). Extracts every {name, version} pair in the tree — including transitive dependencies the other two tools can't see — and batch-queries OSV.dev for known vulnerabilities across all of them.

Each tool's full parameter list is visible in its own MCP schema to any connected client. Response shapes, in brief:

Tool	Key response fields
check_package_health	latestVersion, daysSinceLastPublish, maintainerCount, releasesPerYear, license, repository, flags (plain-language warnings), plus a nested vulnerabilities object (same shape as check_vulnerabilities, run automatically for latestVersion)
check_vulnerabilities	totalVulnerabilities, criticalOrHighCount, and a vulnerabilities array of { id, cveId, summary, severityLevel, cvssVector, publishedDate, references, source } — source: "both" items are additionally enriched with ghsaReviewed, cwes, patchInfo, advisoryUrl
check_dependency_tree_risk	totalPackagesFound, scannedPackageCount (+ packagesTruncated), uniqueVulnerabilityCount, severityBreakdown by level, and topDetails — the top 20 Medium-or-above findings, same per-item shape as check_vulnerabilities plus affectedPackages

Who is this for?

Most package-vulnerability lookups only check the package you name — they miss vulnerabilities buried in your transitive dependencies (the class of incident behind cases like event-stream). This Actor's check_dependency_tree_risk tool exists specifically to close that gap by scanning a project's actual package-lock.json, not just a single package name, and to give an AI coding agent a way to check that on demand during a dependency review or before a release.

Pricing

Event	Price	Trigger
Package health check (check-package-health)	$0.01	Per check_package_health tool call
Vulnerability check (check-vulnerabilities)	$0.01	Per check_vulnerabilities tool call
Dependency tree scan (check-dependency-tree)	$0.03	Per check_dependency_tree_risk tool call

There's no flat actor-start fee — billing is purely per tool call, since this Actor runs as a persistent standby MCP server rather than one-off batch runs.

FAQ

Does this catch vulnerabilities in my dependencies' dependencies, not just my own packages? Only check_dependency_tree_risk does. check_package_health and check_vulnerabilities each look at a single named package only — pass your package-lock.json to check_dependency_tree_risk to cover the full tree, including transitive (indirect) dependencies.

Why do I only get a summary for large projects, not every finding? check_dependency_tree_risk caps scanning at the first 100 packages found in the lockfile, and returns full details only for the top 20 findings at Medium severity or above, to keep response size and OSV.dev query volume bounded on very large dependency trees. severityBreakdown and the total counts still cover everything found, even for findings not included in the detailed list.

How accurate is the severity level? It's an approximation derived from the confidentiality/integrity/availability impact letters in the raw CVSS vector string (cvssVector), not the official CVSS calculation. Treat severityLevel as a rough triage signal and check cvssVector/the linked advisory for the real assessment.

Why is GitHub Advisories data sometimes missing or rate-limited? Without a GITHUB_TOKEN/GH_TOKEN set on the deployment, GitHub's Advisories API allows only 60 requests/hour (vs. 5000/hour authenticated). If GHSA lookup fails for a request, OSV.dev results are still returned, with the failure surfaced in ghsaLookupError.

Can I check a package that isn't on the public npm registry? No — check_package_health and check_vulnerabilities read from registry.npmjs.org directly, so private/unpublished packages aren't supported.

Developer notes (internal)

• Standby idle timeout is currently 90s (lowered from the Apify default of 300s), set via the Actor's Standby settings on Apify Console/API — this is not part of actor.json, since Apify doesn't expose idleTimeoutSecs there. Rationale: with no real users yet, minimizing "accidentally left warm" compute cost during manual testing takes priority over cold-start latency. Revisit (raise it back up) once cold starts become a real problem for actual users.
• After any manual testing session against the deployed standby URL, explicitly abort the run — don't rely on the idle timeout alone:

  npx apify-cli runs ls --actor-id <actorId>       # find the run
  npx apify-cli runs abort <runId>                 # or POST /v2/actor-runs/{runId}/abort
  

  Repeated test calls spaced less than the idle timeout apart keep the same run alive for the whole session. This previously caused runs lasting 4+ hours and real billed compute ($0.88–$1.10) before being caught — see run history for details.
• A normal (non-standby) run has nothing to do by design — see src/main.ts — and now logs at INFO level with one explanatory dataset record instead of an ERROR-level log with no output, after the latter was flagged as an Actor health issue despite the run technically succeeding.

Resources

• What is Anthropic's Model Context Protocol?
• How to use MCP with Apify Actors
• Apify MCP server documentation
• Model Context Protocol documentation