pkg-health-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GH_TOKEN | No | Accepted as an alternative to GITHUB_TOKEN for GitHub API calls. | |
| GITHUB_TOKEN | No | Optional GitHub token for GitHub API calls. Raises GitHub's rate limit. GH_TOKEN is accepted as well. | |
| PKG_HEALTH_CACHE_DIR | No | Cache location. Set to off to disable the disk cache. | ~/.cache/pkg-health-mcp |
| PKG_HEALTH_CACHE_TTL_HOURS | No | How long cached responses are reused. | 12 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_packageA | Score how well an npm or PyPI package, or any GitHub repository, is maintained (0-100, graded A-F). Looks at release and commit recency, number of active committers, time to first maintainer response, issue close time, download trend, OpenSSF Scorecard and license. Use before adding a new dependency, when asked whether a library or project is abandoned, or to vet a GitHub project that is not published to a registry. |
| scan_manifestA | Score every dependency in a manifest or lock file and list the riskiest first. Supports package.json, requirements.txt, pyproject.toml, and the lock files package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock and uv.lock (which include transitive dependencies). GitHub-hosted dependencies are scored as repositories. Prefer |
| compare_packagesA | Compare 2-5 alternative packages from the same registry (e.g. 'moment' vs 'dayjs' vs 'date-fns'), or GitHub repositories, and rank them by maintenance health. Use when choosing between libraries. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool operates at a clearly different granularity: check_package scores a single package/repo, scan_manifest scores an entire manifest or lock file, and compare_packages ranks 2-5 alternatives from the same registry. The descriptions make these boundaries explicit, so an agent can select correctly without guessing.
All three tools follow a strict verb_noun snake_case pattern (check_package, scan_manifest, compare_packages). The verbs are also semantically distinct, reinforcing the naming.
Three tools is well within the appropriate range and each maps to a distinct user intent: vet one dependency, audit a whole project, or choose between alternatives. No tool feels redundant or padding.
The surface covers the core lifecycle of package health assessment: single package scoring, bulk manifest auditing, and comparative evaluation. Minor gaps exist, such as retrieving a detailed score breakdown or history for already-scanned dependencies, but these are workarounds an agent can handle via check_package on individual names.