check_upgradeLABSCO SUMMARY
Ground truth from your environment, not the model's memory.
The value is the filter: a changelog listing thousands of breaking changes is useless, a list of the three that touch your code is actionable. Equally useful is the second job — checking that the API an assistant just wrote exists in the version you have installed, rather than the version it remembers. The author states the limit clearly and repeats it in the tool output: "no findings" means nothing was proven to break, not that nothing will. Dynamically generated APIs, runtime-created members and star re-exports are named as blind spots.
What it is
An MCP server that reads a package's real public API straight from its source and matches it against your code. It never imports or executes third-party code: the API surface is extracted by parsing, and the target version is downloaded as a wheel and unpacked rather than installed. Python is supported now, along with .NET via NuGet assembly metadata and Java by reading .jar bytecode in pure Python.
What you get
check_upgrade— the headline: diff the installed (or a namedfrom_version) API against the target and report only the changes your code actually hits, with line numbers, severity and fix hints. In the worked example, one of 2,015 breaking API changes in apydanticupgrade was the one that touched the code, with a suggested replacementdiff_versions— the raw breaking-change list between two versions with no code scan, for planning a migrationverify_snippet— checks whether the imports and API calls in a piece of code really exist here, catching hallucinated or typo'd package names and attributes that are not on the installed packagecheck_import— is this package installed, and if not, what is the closest real namelist_symbols— the real public API of a package, functions and classes and signatures, for the installed version or any fetched onelist_languages— which ecosystem providers are available- Findings grounded in evidence: the installed version and source location come back with each one
Requirements
No account and no key. pip install bumpguard-mcp, Python 3.10 or newer, stdio transport, and clients configured to run the bumpguard-mcp command. Install it into the same environment as the project you are working on, so it sees the packages you actually have. The .NET provider additionally needs the .NET SDK (dotnet) on PATH; the Java provider needs neither a JDK nor Maven, since jars are parsed directly. For both, prefer passing from_version explicitly — the "installed" baseline comes from the NuGet global cache or your local ~/.m2, which may not match your project's pinned version. verify_snippet is Python-only in v1. MIT licensed.
Setup effort
One command — pip install bumpguard-mcp
USE CASES
Deciding whether a dependency bump is safe
Point it at the package, the target version and your code, and get back only the changes that hit your lines, with severity and a fix hint on each.
Catching an API the model invented
Verify a written snippet against the installed package before running it, so a method that no longer exists is caught at review time.
Planning a migration before touching code
Pull the raw breaking-change list between the two versions with no code scan, to scope the work first.
Writing against an unfamiliar library
List the real public API and signatures of the version you have installed instead of guessing from documentation for a different release.
6 tools
Listed in project docs. Your client may show a different list.
diff_versionsverify_snippetcheck_importlist_symbolslist_languagesBEFORE YOU INSTALL
What to know first
Tools you get
6 tools named in the project's documentation.
Requires
bumpguard-mcp on PATH
Where it runs
All 5 documented clients run the server on your machine.
INSTALLATION
Connect your client
Server setup
pip install bumpguard-mcpMCP Clients
Claude Desktop, Claude Code, Cursor, Windsurf
{
"mcpServers": {
"bumpguard": {
"command": "bumpguard-mcp"
}
}
}VS Code
{
"servers": {
"bumpguard": {
"command": "bumpguard-mcp"
}
}
}