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 providing a GitHub token. | |
| GITHUB_TOKEN | No | Optional GitHub token (fine-grained, public repositories read-only) that raises GitHub API rate limit from 60 to 5,000 requests/hour. The token is sent only to api.github.com. | |
| 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 API responses are reused, in hours. | 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
The three tools have clearly distinct scopes: single-package/repository scoring, manifest-wide dependency scanning, and multi-package comparison. There is little risk of misselection because each maps to a different user intent.
All tool names follow a consistent snake_case verb_noun pattern: check_package, scan_manifest, compare_packages. The verbs accurately communicate the action and no naming conventions are mixed.
Three tools are well-matched to this focused package-health domain: one for individual checks, one for manifest audits, and one for comparisons. Each tool earns its place without redundancy.
The surface covers the core lifecycle of package-health assessment: checking a single package or repository, auditing a manifest or lock file, and comparing alternatives. Minor gaps exist around richer reporting or detailed per-metric drill-down, but agents can work around them.