Loading ToolBench
Guard your dependency bumps: an MCP server that tells your AI agent exactly which parts of YOUR code break when you upgrade a dependency, and verifies AI-written code against the API that's actually installed — by static analysis, never by running third-party code.
BumpGuard MCP demonstrates strong naming conventions, comprehensive descriptions, and well-structured schemas across all 6 tools. All tools use clear action verbs (check_, diff_, verify_, list_) that accurately reflect their behavior. Tool descriptions are substantive (ranging 150-300+ chars), explaining WHAT the tool does, WHEN to use it, and distinguishing it from related tools. Input parameters are fully typed with clear descriptions. However, output schemas are not explicitly documented in the code, they are inferred from return type annotations (all return `dict`), which prevents full validation of output structure quality. Error handling guidance is minimal, tools return raw dicts without documented error categorization or recovery instructions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite all 6 tools being READ_ONLY operations. The codebase is well-structured and the tool definitions follow production patterns, but lacks the advanced error recovery and metadata annotation features that would elevate this to 80+.
Check whether a package is installed; if not, suggest close real names. Use this before writing an import to avoid hallucinated or typo'd package names (a common source of slopsquatting risk).
Check what breaks in YOUR code when you upgrade a dependency. Call this BEFORE bumping a dependency version. It extracts the real public API of the currently-installed (or `from_version`) package and the target `to_version`, diffs them, then scans the provided `code` to report exactly which of your usages break — with line numbers, severity, and fix hints.
List the API changes between two versions of a package (no code scan). Use this to understand a library's breaking changes in the abstract — e.g. when planning a migration. For "what breaks in my code", use check_upgrade instead. Defaults the baseline to the installed version.
List the ecosystem providers BumpGuard currently supports.
List the REAL public API (functions/classes/methods + signatures) of a package. Use this to discover the correct API instead of guessing — for the installed version, or a specific `version` (fetched without installing). Optionally filter symbols by a substring of their dotted path.
Output schemas not explicitly documented. All tools return `dict` with no documented structure, field types, or examples. LLMs cannot reliably parse responses or plan downstream tool chains without knowing what fields to expect.
No tool annotations present. All 6 tools are READ_ONLY operations (marked in Risk field), but this information is not encoded as `readOnlyHint` in the tool metadata. The Risk field is a custom annotation not part of the MCP spec.
Minimal error handling guidance. Tool docstrings do not document error conditions, recovery strategies, or how to interpret failures. E.g., check_upgrade may fail if package is not found or version doesn't exist, but no guidance is provided to the LLM on how to proceed.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 74 | 2026-07-28+ | v2 |
Verify code against the ACTUALLY-INSTALLED packages to catch hallucinations. Call this after generating code to check that the imports and API calls it uses really exist in this environment. Flags: imported packages that aren't installed (with typo/slopsquat suggestions) and attributes/methods that can't be found on installed modules/classes. Static analysis only — treat 'medium' findings as "verify", not "definitely wrong".
list_languages description is minimal (one sentence, ~30 chars). Does not explain what structure is returned or why an LLM would call it. Should clarify that it lists supported ecosystems and when to call it (e.g., to discover if Java/Python/.NET support is available).
No pagination guidance documented. While list_symbols is the only tool that could return large results, there is no mention of whether results are paginated, limited, or how to handle large responses.