Package Health Check in Pi
Vulnerabilities and upkeep. The MCP server is https://packages.openkrill.app/mcp. No key. The steps below are only for Pi. A call to check_package was checked against that server on 2026-10-01.
What this server 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 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, ChatGPT suggests candidates and checks each one.
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 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.
Add Package Health Check in Pi
Pi does not speak MCP on its own. The pi-mcp-adapter extension (these steps match version 2.34.0) loads remote servers and keeps their schemas out of the prompt until you ask. Install it once, then restart Pi:
pi install npm:pi-mcp-adapterAdd the server to a shared MCP file. Use .mcp.json in the project if only that project needs Package Health Check, or ~/.config/mcp/mcp.json if you want it in every project. Pi also reads ~/.agents/mcp.json. A Pi-only override lives in ~/.pi/agent/mcp.json or .pi/mcp.json and wins over the shared file.
{
"mcpServers": {
"packages": {
"url": "https://packages.openkrill.app/mcp"
}
}
}The url is enough. Do not set command: that field is for a local process. No API key header. After restart, run /mcp and confirm the server is listed. The first call connects lazily. Ask: Is lodash 4.17.15 vulnerable? The adapter should offer check_package, check_package_json.
Leave directTools off unless you want those schemas in every turn. With a handful of tools the cost is small. The default proxy is the better fit: search for the tool, then call it. /mcp disable packages writes a project override in .pi/mcp.json without editing the shared file. Run /reload after that change.
Pi will not find this server by scanning Cursor or Claude config unless you run /mcp setup and import it. Putting the url in .mcp.json is the direct path and the one this page tests against. The server is the same public endpoint the other clients use, with the same limits and the same privacy rules.
A call checked on 2026-10-01
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-01.
{
"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.