F
licenseNot graded
qualityC
maintenanceProvides Claude with live access to multiple vulnerability databases (NVD, OSV, GitHub Advisories, Snyk) for querying CVEs, package vulnerabilities, and remediation guidance.
-
fresh-deps-mcp
by hyunaeee
Provides live npm registry data for package versions, deprecation notices, and known vulnerabilities, and audits package.json dependencies to identify outdated or vulnerable npm packages.
Provides live PyPI package version, deprecation, and vulnerability information, and audits requirements*.txt and pyproject.toml dependencies to identify outdated or vulnerable Python packages.
Click on "Deploy 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., "@fresh-deps-mcpcheck my package.json for vulnerable or outdated dependencies"
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.
fresh-deps-mcp
Stop Claude from installing outdated, deprecated or vulnerable packages.
Claude's knowledge of package versions is frozen at its training cutoff. It confidently writes
npm install react@17, reaches for long-deprecated libraries like request, and pins versions with
known CVEs. fresh-deps-mcp gives it live answers from the registries and the
OSV vulnerability database.
Zero config: no API key, no account. One line to install.
Four ecosystems: npm, PyPI, crates.io, Go modules.
Small: two tools, so it uses few context tokens.
Install
Claude Code
claude mcp add fresh-deps -- npx -y fresh-deps-mcpClaude Desktop (claude_desktop_config.json)
{
"mcpServers": {
"fresh-deps": { "command": "npx", "args": ["-y", "fresh-deps-mcp"] }
}
}Related MCP server: agent-versions
Tools
latest_version
Current latest stable version of one or more packages, with deprecation notices and known vulns.
Live npm registry data:
- react: **19.3.1** (released 2026-10-14)
- request: **2.88.2** (released 2020-02-11)
⚠ DEPRECATED: request has been deprecated, see https://github.com/request/request/issues/3142
⚠ latest version has 1 known vuln(s): GHSA-p8p7-x288-28g6check_deps
Audits package.json, requirements*.txt, pyproject.toml, Cargo.toml or go.mod, from a path
or from inline content. Results are sorted by urgency, and each one shows the minimum safe version.
3 dependencies checked: 2 vulnerable, 0 deprecated, 0 major version behind, 1 minor/patch behind or unpinned, 0 up to date.
- **django** ==3.2.0 → latest 6.1.2 [major]
🔴 GHSA-2gwj-7jmv-h26r (CRITICAL): SQL Injection in Django — fixed in 3.2.13
…and 65 more
✅ upgrade to >= 5.2.17 to fix all known vulns (latest: 6.1.2)Development
npm install
npm run build
npm run smoke # spawns the server and calls every tool against live registriesBehind a corporate proxy, run with NODE_USE_ENV_PROXY=1 so Node's fetch uses HTTPS_PROXY.
Roadmap
Lock file support (
package-lock.json,poetry.lock,uv.lock,Cargo.lock) to check exact installed versionschangelog_between: breaking changes between two versions, from GitHub Releasesverify_import: check that an API actually exists in a given versionMaven, NuGet, RubyGems, Packagist
One-click Claude Desktop extension (
.mcpb) and MCP Registry listing
License
MIT
Available Tools
2 toolscheck_depsCheck dependency manifestA
Audit a dependency manifest (package.json, requirements*.txt, pyproject.toml, Cargo.toml, go.mod) against live registries and the OSV vulnerability database. Reports outdated, deprecated and vulnerable dependencies with the version to upgrade to. Call this when starting work on a project, before upgrading dependencies, or after editing a manifest.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to the manifest file on disk | |
| content | No | Manifest contents, if not reading from disk | |
| filename | No | Manifest filename used to pick the parser when passing content, e.g. "package.json" | |
| include_dev | No | Include dev dependencies |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does meaningful work: it discloses that the tool reaches 'live registries and the OSV vulnerability database' (i.e., network dependence) and that the operation is an audit/report rather than a mutation. It stops short of stating whether it ever writes to the manifest, what permissions/tokens registry access may require, or how it behaves on a missing or unparseable manifest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: what it audits and against what, what it returns, and when to call it. No filler and the capability statement is front-loaded ahead of the usage triggers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by summarizing the report contents and including the upgrade version. No annotations means the description carries the behavioral burden, and while it signals the network/registry dependency, it leaves the read-only guarantee and error/fallback behavior unstated for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so path, content, filename, and include_dev are already documented in the schema. The description reinforces the filename/format mapping through its list of manifest files but adds no precedence rule for path vs. content or other semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
A specific verb ('Audit') plus resource ('dependency manifest'), with the supported manifest formats enumerated and the outputs named (outdated, deprecated, vulnerable, upgrade target). It implicitly differs from 'latest_version' (whole-manifest audit vs. single-package version lookup) but never names that sibling, so differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives three concrete invocation triggers: at project start, before upgrading dependencies, and after editing a manifest. There is no explicit when-not guidance and the sibling 'latest_version' is never referenced as the alternative for single-package lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
latest_versionLatest package versionA
Look up the CURRENT latest stable version of packages from the live registry (npm, PyPI, crates.io, Go proxy), plus deprecation notices and known vulnerabilities. Your training data is out of date: ALWAYS call this before writing an install command, adding a dependency, or pinning a version, instead of guessing from memory.
| Name | Required | Description | Default |
|---|---|---|---|
| packages | Yes | Package names, e.g. ["react", "@types/node"] | |
| ecosystem | Yes |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations at all, so the description carries the full burden. It usefully discloses data provenance (live registry, "your training data is out of date") and the extra payloads returned, but says nothing about rate limits, behavior on unknown/deprecated packages, or that the operation is a non-mutating read — all of which an agent would want when batching up to 50 packages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both load-bearing: the first establishes what is fetched and from where, the second front-loads the imperative directive the agent needs before acting. No filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description helpfully previews the return shape (latest stable version, deprecation notices, vulnerabilities) and grounds it in live-registry freshness. It is nearly complete for a 2-param, read-only lookup; only batch-size and unknown-package behavior are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (the `ecosystem` enum has no schema description), so the description must compensate — and it partly does by mapping "crates.io" and "Go proxy" onto the enum values. But it never mentions the 50-package cap, batch semantics, or what a package spec string may include, so the compensating detail is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ("look up the CURRENT latest stable version of packages") with the ecosystems named explicitly (npm, PyPI, crates.io, Go proxy) and secondary payloads listed (deprecation notices, vulnerabilities). Clear enough to know exactly what it returns, but it never mentions the sibling `check_deps`, so the boundary between the two tools is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong, explicit triggers: "ALWAYS call this before writing an install command, adding a dependency, or pinning a version, instead of guessing from memory" — that is a genuine when-to-use rule with an anti-pattern called out. It lacks a named alternative (e.g. "use check_deps for auditing an existing manifest"), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
check_deps - First observed
latest_version
TDQS
A4/5.0
Scored across 2 tools
Disambiguation5/5
latest_version targets a single package's current version and advisories, while check_deps audits an entire manifest for outdated, deprecated, and vulnerable dependencies. The input scopes and intended workflows are clearly distinct, so an agent should not confuse them.
Naming Consistency4/5
Both names use snake_case and are concise, but latest_version is a noun phrase while check_deps follows a verb_noun pattern. This is a minor deviation in an otherwise readable set.
Tool Count4/5
Only two tools are provided, which is below the typical 3-15 range, but they map cleanly to the server's two core workflows: single-package lookup and manifest auditing. The count is slightly thin but reasonable for this narrow purpose.
Completeness4/5
The surface covers the core dependency-freshness needs: checking a package's latest stable version plus advisories, and auditing a manifest for outdated, deprecated, and vulnerable dependencies with upgrade targets. Minor gaps exist, such as no direct scan of an installed environment or arbitrary bulk package list, but agents can work around these via manifests and repeated lookups.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Live npm, PyPI and crates.io package facts, READMEs and vulnerability checks for coding agents.
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceEnables AI coding agents to fetch the real latest versions of packages from npm, PyPI, crates.io and the Go module proxy, then check manifests or whole projects for outdated dependencies and rewrite them in place. It also reports the current releases and underlying dependency stacks of AI coding tools like Claude Code, Codex and Gemini CLI.1MIT
- FlicenseNot gradedqualityAmaintenanceEnables Claude Code and other MCP clients to retrieve context-aware documentation, type signatures, and code examples for any npm package, along with cross-version migration guides, error diagnosis, package comparison, and dependency scanning. Results are formatted to match query intent and drawing on real package types, changelogs, and GitHub docs.-
- AlicenseNot gradedqualityAmaintenanceEnables Claude Code and other compatible clients to retrieve real-time, context-aware documentation, TypeScript types, examples, migration guides, error diagnoses, package comparisons, and dependency scans for any npm package.MIT