Skip to main content
Glama

VulnFeed — Dependency Vulnerability Monitoring for Claude Code

CI PyPI License: MIT vulnfeed-mcp MCP server

An MCP server that scans your project dependencies for known vulnerabilities, enriches with EPSS exploit probability scores, and recommends fix versions.

Free tier — 10 scans/day, 1 monitored project, no signup required. Single-CVE lookup and webhooks need a license key or x402.

Homepage: vulnfeed.novadyne.ai

Install

uvx vulnfeed-mcp

MCP client config

Add to your MCP client config (~/.claude/settings.json for Claude Code, claude_desktop_config.json for Claude Desktop):

Free tier (no signup, no API key):

{
  "mcpServers": {
    "vulnfeed": {
      "command": "uvx",
      "args": ["vulnfeed-mcp"]
    }
  }
}

Paid ($14/mo, unlimited scans + projects):

{
  "mcpServers": {
    "vulnfeed": {
      "command": "uvx",
      "args": ["vulnfeed-mcp"],
      "env": {
        "VULNFEED_API_KEY": "YOUR_LICENSE_KEY_HERE"
      }
    }
  }
}

Get a license key at vulnfeed.novadyne.ai.

x402 micropayments

VulnFeed also accepts x402 micropayments — AI agents can pay per scan with USDC on Base, no API key or signup needed. When the free tier limit is reached, the API returns HTTP 402 with payment requirements that x402-compatible clients handle automatically.

  • $0.01 per scan

  • $0.002 per CVE lookup

  • $0.50 per project per 30 days of hourly webhook monitoring (renewable; the webhook receives an expiring event with the renew URL a day before)

Related MCP server: locklens

Tools

Scanning

Tool

Description

scan_project

Auto-detect and scan all lockfiles in a directory

scan_lockfile

Scan a specific lockfile

check_package

Check a single package for vulnerabilities

lookup_cve

Detailed CVE info with EPSS + fix versions (license key or x402)

Monitoring

Tool

Description

monitor_project

Register for continuous monitoring (optional webhook_url for push alerts)

check_alerts

New vulns since last scan

set_webhook

Set, rotate or remove a project's webhook

update_deps

Update snapshot after upgrading packages

list_monitored

See all monitored projects

unmonitor_project

Remove from monitoring

Supported lockfiles

  • package-lock.json (npm)

  • yarn.lock (Yarn)

  • pnpm-lock.yaml (pnpm)

  • requirements.txt (pip)

  • Pipfile.lock (Pipenv)

  • go.sum / go.mod (Go)

  • Cargo.lock (Rust)

  • Gemfile.lock (Ruby)

  • composer.lock (PHP)

How it works

  1. Parses your lockfile to extract dependency names + versions

  2. Queries OSV.dev (GitHub Advisories plus each ecosystem's security database) for known CVEs

  3. Enriches with EPSS exploit probability scores

  4. Filters noise — suppresses low-EPSS, non-critical CVEs by default

  5. Sorts by exploitability — most likely to be exploited first

  6. Returns fix versions from each advisory's affected-version ranges

Smart filtering

By default, VulnFeed suppresses low-priority CVEs (EPSS < 10% AND CVSS < 9.0). This cuts noise by ~80%.

Pass show_all=True to any scan tool to see everything.

Continuous monitoring

  1. monitor_project — takes a baseline snapshot of current deps + known vulns

  2. check_alerts — diffs against baseline, surfaces only new vulns

  3. Either run check_alerts periodically, or pass webhook_url and let VulnFeed do it

With a webhook (a paid feature: a license key, or for agents x402 at $0.50 per project per 30-day term), VulnFeed re-scans the project every hour and POSTs new findings to your URL:

{
  "event": "vulnfeed.new_vulns",
  "delivery_id": "…", "project_id": "…", "project_name": "…", "sent_at": "…",
  "count": 1,
  "new_vulns": [{ "id": "GHSA-…", "package": "express", "version": "4.18.2", "severity": "HIGH",
                  "epss": { "score": 0.42 }, "fix_version": "4.19.2", "summary": "…" }],
  "alerts_url": "https://vulnfeed-api.novadyne.ai/vulnscan/alerts?project=…"
}

Every delivery carries X-VulnFeed-Signature: sha256=<hex>, the HMAC-SHA256 of the raw body under the webhook_secret returned once when the webhook was set. Verify it. Failed deliveries are retried on later sweeps for about a day, then dropped and counted. Rotate or remove the webhook with set_webhook.

License

MIT

Available Tools

9 tools
check_alertsA

Check for new vulnerabilities since the last scan of a monitored project.

Compares current vulnerability data against the stored baseline. Returns new vulnerabilities (not seen before) and resolved ones (previously known, no longer present).

Args: project_id: The project ID returned by monitor_project.

Inputs: project_id (required). Returns: result

check_packageA

Check a single package for known vulnerabilities.

Args: name: Package name (e.g. "express", "django", "golang.org/x/net"). version: Package version (e.g. "4.18.2", "3.2.0"). ecosystem: Package ecosystem — "npm", "PyPI", or "Go". Defaults to "npm". show_all: Show all vulnerabilities including low-priority ones.

Inputs: name (required), version (required), ecosystem, show_all. Returns: result

list_monitoredA

List all projects registered for vulnerability monitoring.

Shows project names, IDs, package counts, and registration dates.

Inputs: no named parameters. Returns: result

lookup_cveA

Look up detailed information about a specific vulnerability.

Returns full details including severity, EPSS exploit probability, affected packages, fix versions, and references.

Args: cve_id: Vulnerability ID (e.g. "CVE-2024-29041", "GHSA-rv95-896h-c2vc").

Inputs: cve_id (required). Returns: result

monitor_projectA

Register a project for continuous vulnerability monitoring.

Scans the project's lockfiles, records the current vulnerability baseline, and stores a snapshot. Use check_alerts later to see new vulnerabilities that appeared since registration.

Args: project_path: Path to the project root. Defaults to current directory. project_name: Human-readable name for the project. Defaults to directory name.

Inputs: project_path, project_name. Returns: result

scan_lockfileA

Scan a lockfile for known vulnerabilities.

Reads a package lockfile (package-lock.json, requirements.txt, go.sum), queries NVD + GitHub Advisories, enriches with EPSS exploit probability, and returns a prioritized vulnerability report with fix recommendations.

By default, suppresses low-priority CVEs (EPSS < 10% and CVSS < 9). Set show_all=True to see every vulnerability.

Args: lockfile_path: Absolute path to the lockfile to scan. show_all: Show all vulnerabilities including low-priority ones.

Inputs: lockfile_path (required), show_all. Returns: result

scan_projectA

Auto-detect and scan all lockfiles in a project directory.

Walks the project directory looking for lockfiles (package-lock.json, requirements.txt, go.sum, etc.) and scans each one. Skips node_modules, .git, and vendor directories.

By default, suppresses low-priority CVEs (EPSS < 10% and CVSS < 9).

Args: project_path: Path to the project root. Defaults to current directory. show_all: Show all vulnerabilities including low-priority ones.

Inputs: project_path, show_all. Returns: result

unmonitor_projectB

Remove a project from vulnerability monitoring.

Deletes the stored dependency snapshot and vulnerability baseline.

Args: project_id: The project ID to remove.

Inputs: project_id (required). Returns: result

update_depsA

Update a monitored project's dependency snapshot after upgrading packages.

Re-reads lockfiles from the project directory and updates the stored dependency list. Preserves vulnerability history: existing known vulns that still apply are kept; new vulns from upgraded deps are flagged; vulns from removed deps are marked resolved.

Args: project_id: The project ID to update. project_path: Path to the project root. Defaults to current directory.

Inputs: project_id (required), project_path. Returns: result

Tool Schema Changelog

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

Loading tool schema changelog…

    TDQS

    A4.1/5.0

    Scored across 9 tools

    Disambiguation5/5

    Each tool targets a distinct resource and action: scanning lockfiles vs. whole projects, looking up packages vs. CVEs, and monitoring lifecycle actions like register, update, check, list, and unmonitor. Even the scanning tools are clearly separated by scope (single lockfile vs. project directory).

    Naming Consistency5/5

    All tool names follow a consistent snake_case verb_noun pattern: scan_lockfile, scan_project, check_package, lookup_cve, monitor_project, update_deps, check_alerts, list_monitored, unmonitor_project. The pattern makes the set predictable and easy to navigate.

    Tool Count5/5

    Nine tools is well-scoped for a vulnerability scanning and monitoring server. Each tool earns its place, covering scanning, lookup, registration, alerting, updating, listing, and removal without unnecessary duplication.

    Completeness4/5

    The tool surface covers the core lifecycle well: scan, lookup, monitor, update baselines, check alerts, list, and unmonitor. A minor gap is the lack of a direct way to retrieve the full stored vulnerability baseline for a monitored project, though scanning again or check_alerts can work around it.

    Maintenance

    ActivityNo data
    ResponsivenessSyncing

    Related MCP Connectors

    Related MCP Servers