@deepvaultscan/mcp-server

A Model Context Protocol server that lets any MCP-compatible coding agent (Claude Code, Cursor, Windsurf, etc.) check an open-source package's security, license, maintenance, and popularity Trust Score on demand — before it gets added to a project.

No account, no API key, no build step. It calls public registries (npm, PyPI, crates.io, proxy.golang.org) and OSV directly and runs the same scoring engine as the DepVault CLI (@depvault/core), fully bundled — nothing else needs installing.

Install

Add this to your MCP client's config file (.mcp.json for Claude Code, .cursor/mcp.json for Cursor, or your client's equivalent):

{
  "mcpServers": {
    "depvault": {
      "command": "npx",
      "args": ["-y", "@deepvaultscan/mcp-server"]
    }
  }
}

Tools

scan_package_health

Trust Score (0-100) for a single package.

| Argument | Required | Description | | --- | --- | --- | | ecosystem | yes | One of npm, pypi, cargo, go | | packageName | yes | Exact package name | | version | no | Defaults to latest |

scan_repository

Trust Score for every dependency declared in a project's manifest.

| Argument | Required | Description | | --- | --- | --- | | directory | yes | Absolute path to the project directory. Must be within the server's current working directory — this is a sandbox boundary, not a bug. |

Supports package.json, requirements.txt, pyproject.toml, Cargo.toml, and go.mod.

Requires internet — there is no offline mode

Every tool call above makes live HTTP requests to the relevant public registry (npm, PyPI, crates.io, or proxy.golang.org) and to OSV for vulnerability data. There is no local cache or fallback here: if the network is unreachable, the call fails outright rather than returning stale or partial data. (The DepVault CLI's depvault shield sync command has a real offline verdict cache for previously-synced packages — this MCP server does not; it's a thin, always-live wrapper around the same scoring engine.)

Optional: auto-scan on install

Off by default. When you opt in, this package scans your project's actual dependencies during npm install/pnpm install/yarn install and prints anything scoring below 60/100 — a zero-effort early warning, separate from calling scan_repository yourself through an agent.

First, add it as a real devDependency rather than invoking it via ephemeral npx each time:

npm install -D @deepvaultscan/mcp-server

(npx -y @deepvaultscan/mcp-server, as used in the MCP client config above, only runs postinstall the first time it populates its local cache for a given version — every call after that skips lifecycle scripts entirely. Everything below needs a real install to actually fire on every npm install.)

Then opt in one of two ways:

Per-install, via an env var — has to be set every time:

DEPVAULT_AUTO_SCAN=1 npm install

Persistently, once — no env var needed on future installs:

npx @deepvaultscan/mcp-server --enable-auto-scan

This writes a small opt-in flag to ~/.depvault/auto-scan.json on your machine. From then on, every npm install of any project with this package as a devDependency scans automatically, until you run --disable-auto-scan. Check the current state anytime with --auto-scan-status.

[DepVault] Auto-scan enabled — scanning 10 npm dependencies...
[DepVault] 1 package(s) scored below 60/100:
  [51/100] mongoose
[DepVault] Auto-scan is persistently enabled on this machine. Disable with: npx @deepvaultscan/mcp-server --disable-auto-scan

Escape hatch for a one-off install where you don't want this (e.g. a CI job you don't want making extra network calls that run): DEPVAULT_SKIP_AUTO_SCAN=1 npm install — wins over both the persisted setting and the env var.

Optional, stricter: fail the install on a CRITICAL vulnerability

npx @deepvaultscan/mcp-server --enable-auto-scan --block-on-critical

With this on, if any scanned dependency has a known CRITICAL-severity vulnerability, the install fails (non-zero exit) instead of just printing a warning.

Read this carefully before turning it on — it is not the same guarantee as a real install-time gate. This only fires when this package's own postinstall script runs — i.e. when @deepvaultscan/mcp-server itself is being (re)installed. It cannot intercept some later, unrelated npm install <other-package> in the same project, because nothing about that command re-triggers this package's lifecycle scripts. For that — an actual gate on every install, of anything, with an auditable override — you want the DepVault CLI's depvault shield / depvault hooks install shell-wrapper instead (see the root README); the CLI is a separate, not-yet-published tool built from this repo's source, not something npx-able today. Think of --block-on-critical as "catch it the next time this package's install runs," not "catch it always."

Notes on what auto-scan does and doesn't do:

• Report-only unless --block-on-critical is on. Without it, this never blocks the install or sets a non-zero exit code, even if every dependency scores 0/100.
• Fails silent. Any unexpected error (unreachable registry, malformed manifest, unsupported ecosystem) is swallowed — this must never be why your install fails, other than the one deliberate --block-on-critical case above.
• Needs the same live internet access described above — there's no offline verdict cache here, so this is only useful when the install itself already has network access (true for most local/CI installs, not for air-gapped ones).
• Respects DEPVAULT_TELEMETRY=0 the same way normal tool calls do (see below) — it still sends the same anonymous per-machine ping unless you've disabled telemetry.

Telemetry

Sends an anonymous usage ping by default on each tool call: the tool name, the ecosystem, and a random per-machine ID generated once and cached locally — never your username, hostname, IP, or any package/project name. Used only in aggregate to gauge adoption. Disable with:

export DEPVAULT_TELEMETRY=0

Security

This server runs over stdio and trusts every caller reachable through that transport — that's fine for the intended use (an agent on your own machine spawns it as a child process), since whoever can spawn it already has equivalent access to the host. It has no auth layer of its own; if you ever run this over a network transport instead of stdio, put an auth layer in front of it first.