dependency-fitness-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | No | GitHub token to raise the rate limit for the archived-repo cross-check. Optional. |
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_package_fitnessA | Return a cross-validated fitness verdict for an npm package: is it deprecated / yanked / superseded / malicious, and if so what is the safe migration target. Unlike a plain 'is it deprecated' lookup, this reconciles the npm registry, deps.dev, OSV and GitHub into one confidence-scored answer, infers a safe replacement when one exists, and flags disagreement instead of guessing. Also detects non-existent / hallucinated package names. |
| audit_dependenciesA | Audit many npm dependencies at once and return a per-package fitness verdict plus a summary (how many are deprecated / malicious / vulnerable / behind). Accepts a list of package specs (e.g. ['react@18.2.0', 'request']) and/or the raw contents of a package.json. Ideal for a CI / pre-merge dependency gate. Capped at 50 packages per call. |
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 2 tools
The two tools have clearly distinct purposes: one checks a single package with cross-validated intelligence, the other audits multiple dependencies at once with a summary. No ambiguity between them.
Both tools follow a verb_noun pattern (check_package_fitness, audit_dependencies) but use different verbs ('check' vs 'audit') and different objects. Slightly inconsistent but still predictable.
With only 2 tools, the server is lean but covers the core functionality (single package check and batch audit). Could be expanded with more granular tools, but the count is reasonable for the narrow domain.
The server provides the main operations needed for npm dependency health checking: single-package verdict and batch audit. Lacks features like vulnerability details or update commands, but covers the essential use cases without dead ends.