Package Health Check in VS Code

Questions it answers

Check an npm or Python package before you depend on it, or the dependencies of a package.json you already have, and get the facts from public sources.

Ask "is lodash 4.17.15 vulnerable?", "is this npm package maintained?", "what license is this package?", "safer alternative to request" or "check my package.json for known vulnerabilities".

Package Health Check reads OSV.dev for known vulnerabilities, the npm registry and the PyPI JSON API for deprecation notices, licenses and versions, deps.dev for release history and dependents, and npm for weekly downloads.

For one package it reports the advisories that affect the version you name (or the latest), how severe each is and the version that fixes it, the license, any deprecation notice, the last release date, how many releases came out in the last year, and how many packages depend on it.

For the repository behind a package it reports the date of the last commit, whether the repository is archived, stars, forks and open issues, the OpenSSF Scorecard score with its weakest checks, and how many accounts can publish it on npm, with a verdict of healthy, watch or risky.

For a package.json it looks up every dependency at the version the file names and lists the ones with known vulnerabilities, most severe first. Version ranges are checked at their lowest version, so a lockfile gives the exact answer for what is installed.

It only needs public package names and versions. Never paste source code, tokens or private package names: a package.json is read for its dependency names and versions only, is not stored, and the rest of the file is ignored.

A recent release date is not a security guarantee, and a package with no known advisories can still be vulnerable. It does not scan source code or recommend replacements on its own: when a package is deprecated or abandoned, your assistant suggests candidates and Package Health Check checks each one.

Short questions this server answers, each with a direct answer: npm and PyPI Package Vulnerability and License Check.

What it can do

• Lists known vulnerabilities of an npm or PyPI package version with severity and the fixed version
• Shows the license, deprecation notice, last release date and release pace of a package
• Shows how many packages depend on a package and its weekly npm downloads
• Checks every dependency of a pasted package.json for known vulnerabilities
• Checks the repository behind a package: last commit, archived or not, OpenSSF Scorecard and npm maintainers
• Checks candidate replacements for a deprecated or abandoned package

Tools

• check_package, Check a package's health. Use this when the user asks whether an npm or PyPI package is vulnerable, maintained, deprecated or safe to use, or what license it has: "is lodash 4.17.15 vulnerable?", "is this npm package maintained?", "what license is this package?", "safer alternative to request". Pass the public package name, ecosystem (npm or pypi) and a version if the user gave one; otherwise the latest is checked. Returns the known vulnerabilities of that version with severity and fixed version, the license, any deprecation notice, last release date, releases in the last year, weekly downloads (npm) and dependents. It does not pick alternatives: for a deprecated or stale package, suggest candidates and check each one with this tool.
• check_package_json, Check package.json for vulnerabilities. Use this when the user asks to check their package.json, or the dependencies of a project, for known vulnerabilities: "check my package.json for known vulnerabilities". Pass the text of the package.json; only the names and versions in dependencies, devDependencies and optionalDependencies are read, nothing else in the file is used or kept, and nothing is stored. Do not ask for source code or tokens. Checks up to 150 npm dependencies at the version each names (ranges at their lowest version) and returns the vulnerable ones, most severe first, with the fixed version. Dependencies without an exact version (tags, urls, workspaces) are listed as skipped.
• check_repo_health, Check a package's repository health. Use this when the user asks whether the project behind a package is maintained, abandoned or trustworthy: "is the express repo still maintained?", "when was the last commit to left-pad?", "what is the OpenSSF Scorecard of requests?". Pass the public package name and ecosystem (npm or pypi), or repo as a GitHub owner/repo. Returns the repository, the last commit date and days since, whether it is archived, stars, forks, open issues, the OpenSSF Scorecard score with its weakest checks, the npm maintainer count, and a verdict (healthy, watch, risky or unknown) with reasons. For known vulnerabilities of a version use check_package instead.

Add Package Health Check in VS Code

VS Code reads MCP servers from mcp.json and offers their tools to Copilot Chat in Agent mode. A workspace file at .vscode/mcp.json applies to that project. For every workspace, run MCP: Open User Configuration from the Command Palette and add the same entry there. These steps were checked against the VS Code MCP servers guide on 2026-10-09.

Create or edit the file so it contains this server. VS Code uses a top-level servers object, not mcpServers. Merge it with servers you already have.

{
  "servers": {
    "packages": {
      "type": "http",
      "url": "https://packages.openkrill.app/mcp"
    }
  }
}

No command, no headers and no input variables for a key: Package Health Check answers without a login. Save the file and select Start above the entry. VS Code asks once whether you trust the server: confirm it. Run MCP: List Servers to check that Package Health Check is running. You should see check_package, check_package_json, check_repo_health.

Open the Chat view, choose Agent mode and ask: Is lodash 4.17.15 vulnerable? The Configure Tools button in the chat input lists the tools of each server, and VS Code may ask you to confirm the first call. The server is public and read-only. It sees only the arguments of each call, so do not paste secrets into the question.

Command line users can add it to the user profile in one step with code --add-mcp and the same name, type and url as JSON. The portable .mcp.json at the project root also works in VS Code, with mcpServers as its top-level key. An organization can turn MCP off through Copilot policy: if the MCP commands are missing, ask the admin.

If it does not work

A call checked on 2026-10-11

lodash 4.17.15 is a public npm release with a known advisory, so the vulnerability fields can be checked. The request below was posted to https://packages.openkrill.app/mcp as tools/call. HTTP 200. Source: the Package Health Check server, read 2026-10-11.

{
  "method": "tools/call",
  "params": {
    "name": "check_package",
    "arguments": {
      "name": "lodash",
      "ecosystem": "npm",
      "version": "4.17.15"
    }
  }
}

• status. ok
• name. lodash
• vulnerabilities. 6 returned

Repeat the call yourself if you need a newer reading. Cached answers expire. A rate limit is not a result: wait and try again. Nothing in the call is a ranking, a filing, or advice.

Using it in production

Nothing to install and nothing to run: no package, no Python or Node.js version and no environment variable. Package Health Check runs on our servers, and your client only needs the URL https://packages.openkrill.app/mcp.

Use it in other apps

• Package Health Check in ChatGPT
• Package Health Check in Claude
• Package Health Check in Cursor
• Package Health Check in Pi

Roles that use Package Health Check

• Security engineer guide
• Software developer guide

Frequently asked questions

Words on this page

• MCP (Model Context Protocol) definition
• Streamable HTTP transport definition
• Tool primitive definition
• Rate limit policy definition

Source: plugin listing for packages in this repository, and a live tools/call on 2026-10-11. As of 2026-10-11.