MCP server that scans package.json/pubspec.yaml/Cargo.toml/requirements.txt, flags risky upgrades via static semver/deprecation analysis, and surfaces pre-filtered breaking-change excerpts for LLM-driven migration planning
Wellknown found it in public sources; nobody has proven control of it yet. Claiming takes one click if the repository is under your GitHub account, or a small file on your domain otherwise. Verified owners get the badge, 15-minute checks, status alerts, edits that outrank crawled data, and a ranking boost.
Agents can do it too: POST https://wellknown.network/api/v1/claims with {"agent":"package-upgrade-mcp","method":"well_known_file"} — machine-readable steps at claim.json, guide at /docs/claim.
Everything here was measured by our prober or read from a registry. Nothing is self-reported.
Attributed to the source that supplied each field. Treated as claims, not facts.
# package-upgrade-mcp <!-- mcp-name: io.github.Hasilt/package-upgrade-mcp --> An MCP server that helps an LLM plan dependency upgrades without drowning in changelog text. Point it at a manifest file and it tells you what's outdated, how risky each upgrade looks, and — only for the packages worth worrying about — pulls the actual breaking-change notes. Supported manifests: `package.json` (npm), `requirements.txt` (PyPI), `pubspec.yaml` (pub.dev), `Cargo.toml` (crates.io). No API keys required — every registry it talks to (npm, PyPI, pub.dev, crates.io, GitHub) is public. ## Why it's split into stages Fetching full release notes for every dependency in a real project would burn a huge amount of context for basically no benefit, since most upgrades are patch/minor bumps with nothing breaking in them. So the server does the boring, deterministic part itself and only reaches for text when it's actually warranted: 1. **Cheap and always called** — `scan_manifest` / `check_upgrades` return current vs. latest version, the semver delta, and a risk level computed from version math plus registry metadata (deprecated/yanked flags). No changelog text, just one registry lookup per dependency. 2. **Targeted, only for what's flagged** — `get_breaking_change_excerpts` fetches changelog or release-note text and runs it through a heuristic filter that keeps the parts that look like breaking-change announcements (`## Breaking`, `BREAKING CHANGE:`, removed/renamed/ deprecated notes, migration guides) and throws away routine feature/fix entries. `get_raw_changelog` is there too, for the rare case the filtered excerpt isn't enough. The server never decides "this will take 3 days" or writes the upgrade plan itself — that synthesis is left to whichever LLM is calling it. Its job ends at handing over small, pre-digested findings instead of a wall of release notes. ## Install With [Claude Code](https://docs.claude.com/en/docs/claude-code): ```bash claude …
Mapped onto the structured taxonomy from declared text and observed tool names. Confidence shown for derived entries.
Every source is kept verbatim. Field changes are logged as events.