Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dependency-fitness-mcp Is 'node-fetch' deprecated and what should I use instead?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Is this npm package safe to depend on — and if not, what do I move to?
An MCP server that gives a coding agent a cross-validated fitness verdict for an npm package before it writes or upgrades a dependency:
{
"deprecated": true,
"yanked": false,
"malicious": false,
"superseded_by": { "latest": "14.0.0", "majors_behind": 13, "breaking_boundary": true },
"safe_migration_target": {
"package": "uuid",
"version": "14.0.0",
"rationale": "Maintainer's deprecation notice recommends 'uuid' (verified present and not deprecated).",
"confidence": "high"
},
"confidence": "high",
"last_verified": "2026-06-05T18:10:31Z"
}It reconciles four free, sanctioned sources — the npm registry, Google's deps.dev, OSV.dev, and GitHub — into one confidence-scored answer, and infers a safe migration target when a package is deprecated or superseded.
"Is it deprecated?" is already free — deps.dev serves that flag, and several free MCP servers already answer "what's the latest version?". This tool does the part nobody serves as data:
Migration-target inference. When a package is deprecated, it parses the maintainer's own deprecation notice for a named successor, then verifies that successor actually exists and isn't itself deprecated before recommending it.
Cross-validation, not a guess. It reconciles deprecation across the npm registry and deps.dev, catches "deceptive deprecation" (registry says active but the GitHub repo is archived), and flags disagreement with a confidence level instead of inventing an answer.
It refuses to guess. If a package is deprecated but no successor can be established, it says exactly that (low confidence) rather than recommending a plausible-but-wrong replacement. A wrong "use X instead" ships broken code.
Anti-slopsquatting. A non-existent / hallucinated package name returns a clear "not found" verdict (with an OSV malicious-record check), so an agent won't silently install a hallucinated dependency.
This is intentionally a narrow tool: the deprecation / yank / supersede / migration middle, where the free incumbents sit on either side but leave the seam open.
Related MCP server: npm-mcp
check_package_fitnessSingle-package verdict. Input: package (e.g. request, @babel/core), optional
version (exact, semver range, or dist-tag — omit for latest). Output: the full
Verdict (structured) plus a human-readable summary.
audit_dependenciesBatch verdict for a CI / pre-merge gate. Input: packages (e.g.
["react@18.2.0", "request"]) and/or the raw contents of a package.json. Output:
a per-package verdict array plus a summary (how many deprecated / malicious /
vulnerable / behind). Capped at 50 packages per call.
Requires Node ≥ 18. Run via npx (no install) or install globally.
Claude Code:
claude mcp add dependency-fitness -- npx -y dependency-fitness-mcpClaude Desktop / Cursor / any MCP client (mcp.json / claude_desktop_config.json):
{
"mcpServers": {
"dependency-fitness": { "command": "npx", "args": ["-y", "dependency-fitness-mcp"] }
}
}Optional env: GITHUB_TOKEN raises the GitHub rate limit (used only for the
archived-repo cross-check); everything else needs no key.
npm install
npm run build # tsc -> dist/
npm test # vitest (offline, deterministic synthesis tests)
npm run smoke # live: hits the real registries, prints verdicts
npm run dev # run the server from source over stdio ┌─ npm registry ── per-version `deprecated` string, dist-tags, repo URL (authoritative)
query ──┼─ deps.dev ────── isDeprecated / deprecatedReason / advisoryKeys (corroborator)
├─ OSV.dev ─────── advisories + MAL-* malicious markers + "fixed in" (corroborator)
└─ GitHub ──────── archived flag + last-push recency (deceptive-deprecation check)
│
▼
cross-validate deprecation ─→ infer + verify migration target ─→ confidence + warnings ─→ Verdictnpm is the source of truth; the others corroborate. A corroborator being
unreachable lowers confidence and adds a warning — it never fabricates a
signal.
v0.1 — thin, working, npm-only. This is a fast public validation of whether a
narrow "agent-data endpoint via MCP directory" can find its users organically.
Roadmap and the explicit kill criterion live in
KILL_CRITERION.md. Next layers (documented, not yet
built): PyPI, and de-facto-successor inference by mining what high-trust
packages actually depend on now.
MIT © Christo Wilken / 9592 Solutions UG. Built in public.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| packages | No | Package specs, e.g. ['lodash@^4', '@babel/core', 'request@2.88.2']. | |
| package_json | No | Raw package.json contents; all dependency sections are extracted. |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| summary | Yes | |
| truncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cap of 50 packages and output structure (verdict + summary). No annotations provided, so description carries burden; lacks details on whether it mutates anything or if it's read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences covering purpose, inputs, use case, and limit. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description covers all necessary context: purpose, inputs, usage, and constraints. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds concrete examples for packages and explains that package_json extracts all dependency sections, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly describes auditing many npm dependencies and returning per-package verdicts plus summary. Distinct from sibling check_package_fitness by focusing on bulk audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it's ideal for CI/pre-merge dependency gates and mentions 50-package cap. Could explicitly contrast with sibling but context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | npm package name, e.g. 'request' or '@babel/core' | |
| version | No | Exact version, semver range, or dist-tag. Omit to check the current 'latest'. |
| Name | Required | Description |
|---|---|---|
| exists | Yes | |
| yanked | Yes | |
| package | Yes | |
| signals | Yes | |
| warnings | Yes | |
| agreement | Yes | |
| ecosystem | Yes | |
| malicious | Yes | |
| advisories | Yes | |
| confidence | Yes | |
| deprecated | Yes | |
| last_verified | Yes | |
| superseded_by | Yes | |
| queried_version | Yes | |
| resolved_version | Yes | |
| deprecated_reason | Yes | |
| sources_consulted | Yes | |
| safe_migration_target | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses source reconciliation, confidence scoring, safe replacement inference, and detection of hallucinated package names. It could be more explicit about error handling or whether the operation is read-only, but the description is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and efficiently lists distinguishing features without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers what the agent needs: a fitness verdict, confidence score, safe replacement, disagreement flag, and detection of non-existent packages. The output schema handles return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds context beyond the schema by explaining version as semver range or dist-tag and noting that omitting version checks the latest. This enriches the agent's understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a cross-validated fitness verdict for an npm package, specifying the resource and action. It distinguishes itself from a plain 'is it deprecated' lookup by mentioning reconciliation from multiple sources and detection of non-existent packages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use cases by contrasting with a simpler lookup and mentioning inference of safe replacements. However, it does not explicitly compare with the sibling tool 'audit_dependencies' or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1audit_dependenciescheck_package_fitnessScored 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The MCP server that vets MCP servers: identity, risk grade and per-tool risk before you install.
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Independent trust scores, tool surfaces and change history for MCP servers.
Conformance checker for MCP servers. Free, no key, verdicts recomputable and re-measured daily.