What can you do with this server?

BumpGuard is an MCP server that guards your code against dependency upgrade breakage and API hallucinations using static analysis only (no third-party code is ever executed). It supports Python, .NET (NuGet), and Java (Maven). * check_upgrade: Scans your actual source code to find exactly which lines break when upgrading a package from one version to another, with line numbers, severity levels, and fix hints. * diff_versions: Lists all API changes (removed, signature-changed, or added symbols) between two versions of a package without scanning your code — useful for migration planning. * verify_snippet: Checks that the imports and API calls in a code snippet actually exist in your installed environment, catching hallucinated package names, typos, and non-existent methods/attributes. * check_import: Verifies whether a package is installed and, if not, suggests closely matching real package names to prevent slopsquatting or typo'd imports. * list_symbols: Provides the real public API (functions, classes, methods, and signatures) of a package for the installed or any specific version, with optional name filtering. * list_languages: Lists the supported ecosystem providers currently available (e.g., Python, .NET, Java).

Which integrations are available for this server?

Planned integration to parse TypeScript declaration files from npm for API verification. Reads .NET assembly metadata from NuGet to detect breaking changes and plan migrations. Extracts Python package public APIs from PyPI to check dependency upgrades and verify code against installed packages.

How do I use BumpGuard?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BumpGuard Check if upgrading pandas to 2.2 breaks my data pipeline." 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.

BumpGuard

by appcreationsca

Overview Schema Related Servers Score Discussions

Python

Local

BumpGuard

Guard your dependency bumps. BumpGuard is a Model Context Protocol (MCP) server that tells your AI coding agent exactly which lines of your code break when you upgrade a dependency — and verifies AI‑written code against the API that is actually installed, so it stops calling functions that don't exist.

It does this by static analysis only. BumpGuard never imports or executes third‑party code; it reads a package's real public API straight from its source.

Docs tell your agent what should exist. BumpGuard tells it what actually exists here.

Why this exists

The #1 frustration developers report with AI coding tools is code that's "almost right, but not quite." A huge slice of that is API drift and hallucination:

The model writes pydantic.BaseSettings or openai.ChatCompletion.create(...) — perfectly valid two versions ago, gone in the version you have installed.
You bump pandas from 1.5 to 2.2 and discover the breakage one stack trace at a time.
A changelog lists 1,800 breaking changes; you only care about the three your code actually touches.

BumpGuard closes that gap with ground truth from your environment instead of the model's memory.

Related MCP server: Asynthetic

What it does

A real example — upgrading pydantic 1 → 2 in code that uses BaseSettings:

// check_upgrade(package="pydantic", to_version="2.0.3", from_version="1.10.13", code="...")
{
  "safe_to_upgrade": false,
  "summary": { "breaking": 1, "total_api_changes": 4919, "breaking_api_changes": 2015 },
  "findings": [
    {
      "symbol": "pydantic.BaseSettings",
      "line": 2,
      "severity": "breaking",
      "message": "You use 'pydantic.BaseSettings', which no longer exists in the target version...",
      "suggestion": "Consider 'pydantic.v1.env_settings.BaseSettings'"
    }
  ]
}

Out of 2,015 breaking API changes, BumpGuard surfaced the one that affects this code — with the line number and a fix hint.

Tools

Tool	What it answers
`check_upgrade` ⭐	"If I upgrade `package` to `to_version`, what in *this code* breaks?" Diffs the installed (or `from_version`) API against the target and reports only the changes your code actually hits, with severity and fix hints.
`diff_versions`	"What changed between two versions of this library?" The raw breaking‑change list, no code scan — good for planning a migration.
`verify_snippet`	"Do the imports and API calls in this code really exist here?" Catches hallucinated/typo'd package names (slopsquatting) and attributes that aren't on the installed package.
`check_import`	"Is this package installed? If not, what's the closest real name?"
`list_symbols`	"What's the real public API of this package?" Discover functions/classes/methods + signatures instead of guessing — for the installed version or any fetched version.
`list_languages`	Which ecosystem providers are available.

Every answer is grounded in evidence (installed version, source location). Because analysis is static, "no findings" means "nothing proven to break," not a guarantee — BumpGuard is explicit about that in its output.

Install

pip install bumpguard-mcp

Requires Python 3.10+. The server speaks MCP over stdio.

Install BumpGuard into the same environment as the project you're working on, so it sees the packages you actually have installed.

Configure your MCP client

Claude Desktop / Claude Code (claude_desktop_config.json):

{
  "mcpServers": {
    "bumpguard": {
      "command": "bumpguard-mcp"
    }
  }
}

Cursor / Windsurf / VS Code (Copilot) — point your MCP config at the bumpguard-mcp command (or python -m bumpguard.server). Any MCP‑compatible client works.

Then ask your agent things like:

"Before upgrading pandas to 2.2, check whether my data pipeline breaks."
"Verify this snippet actually uses the installed OpenAI SDK."
"List the real methods on httpx.Client."

How it works

                 ┌──────────────── language‑neutral core ────────────────┐
   MCP tools  →  │  diff engine · breaking‑change classifier · analyzer  │
                 │  (matches API changes against YOUR usage)             │
                 └───────────────────────┬──────────────────────────────┘
                                         │ Provider interface
                 ┌───────────────────────┴──────────────────────────────┐
                 │  Python provider  │  .NET (NuGet)   │  Java (Maven)   │
                 │  • AST surface    │  • DLL metadata │  • jar bytecode │
                 │  • usage scanner  │  • Roslyn scan  │  • source scan  │
                 │  • wheel fetch    │  • nupkg fetch  │  • jar fetch    │
                 └──────────────────────────────────────────────────────┘

Extract a package's public API surface by parsing its source with Python's ast — for the installed version, and for the target version (downloaded as a wheel and unpacked, never installed or executed).
Diff the two surfaces into removed / signature‑changed / added symbols, and classify each as breaking, potentially breaking, or info.
Scan your code (also via ast) for usages — resolving import aliases, re‑exports, instance‑method calls, and the keyword/positional arguments each call passes.
Match usages against changes and report a precise, per‑line verdict.

Safety: BumpGuard never imports third‑party code, so there are no import side effects, no hangs from heavy packages, and no arbitrary code execution. Wheel downloads are sandboxed to a temp dir, time‑bounded, and guarded against path traversal / zip bombs.

Multi‑language by design

BumpGuard is built around a pluggable provider interface. The diff engine, breaking‑change classifier, analyzer, reporting, and MCP tools are all language‑neutral; only the surface extraction and usage scanning are ecosystem‑specific.

✅ Python (PyPI) — available now.
✅ .NET (NuGet) — available now. Reads public API from assembly metadata via reflection-only loading (no code executed); needs the .NET SDK (dotnet) on PATH. A small helper is built once on first use.
✅ Java (Maven) — available now. Reads public API directly from compiled .jar bytecode (constant pool, access flags, descriptors) in pure Python — no JDK or Maven required and no third‑party code is executed.
🔜 JS/TS (npm) — parse .d.ts declarations.

Adding an ecosystem means implementing one Provider — see docs/ADD_A_PROVIDER.md.

.NET specifics (v1)

Pass language: "dotnet". Example: "Before upgrading Azure.AI.OpenAI to 2.1.0, check whether my client code breaks (from_version 1.0.0-beta.17)."
Supported: check_upgrade, diff_versions, list_symbols, check_import.
Prefer passing from_version — the "installed" baseline is taken from the NuGet global cache, which isn't your project's pinned version.
Reliable signal: type / method / property removals and additions (e.g. the OpenAIClient → AzureOpenAIClient rename is caught as a breaking removal with a suggestion). Parameter-level diffs run only for unambiguous single-overload members; overloaded members are tracked by presence (a documented v1 limit).
Fully-qualified references are reported confidently; short names resolved via using are reported as lower-confidence "potentially breaking" to avoid false hard-breaks from namespace collisions.
verify_snippet is not supported for .NET in v1 (accurate C# hallucination detection needs semantic binding).

Java specifics (v1)

Pass language: "java" and identify packages by their Maven coordinate group:artifact (e.g. com.google.code.gson:gson). Example: "Before upgrading com.google.code.gson:gson to 2.10.1, check whether my code breaks (from_version 2.8.9)."
Supported: check_upgrade, diff_versions, list_symbols, check_import.
The public API surface is read directly from .jar bytecode (the jar is a zip of .class files; BumpGuard parses the class‑file structure with struct — reading metadata, never running it). The target jar is fetched from Maven Central (sandboxed, size‑capped, time‑bounded). No JDK/Maven needed.
Prefer passing from_version — the "installed" baseline is read from your local ~/.m2 cache, which may not match your project's pinned version.
Reliable signal: type / method / field / constructor removals and additions, and arity changes. Fully-qualified references hard-break; short names resolved via import are reported as lower-confidence "potentially breaking" to avoid false hard-breaks from namespace collisions.
Documented v1 limits: generics are erased in bytecode descriptors (so generic type-argument changes aren't seen); return-type-only changes and varargs removal are tracked conservatively; overloaded members are tracked by presence (per-overload removal isn't detected); multi-release jars use the highest version overlay. The source usage scanner is a robust heuristic, not a full parser — it can pick up a name's own declaration or import line as a reference, but these resolve to unqualified names that are capped at "potentially breaking" and can never produce a false hard-break. verify_snippet is not supported for Java in v1 (accurate hallucination detection needs semantic binding).

Known limitations (v1, Python)

BumpGuard is honest about static analysis. It may miss (false negatives) or, rarely, over‑flag (false positives):

Dynamically generated APIs (__getattr__ modules, plugin registries, boto3‑style clients). BumpGuard detects __getattr__ modules and suppresses confident "missing symbol" findings under them.
Members created at runtime that aren't visible in source.
Compiled (C/Rust) extension internals — the Python‑level surface is still read.
Deep instance‑flow tracking is limited to direct x = Class(...) patterns.
Star re‑exports (from .x import *) are not expanded.

Treat findings as high‑signal guidance, and absence of findings as "not proven unsafe," not a guarantee.

Development

git clone https://github.com/appcreationsca/bumpguard-mcp
cd bumpguard-mcp
python -m venv .venv && . .venv/Scripts/activate   # Windows
pip install -e ".[dev]"
pytest

The test suite (42 tests) runs offline using fixture packages — no network required.

Releasing

Releases are automated via GitHub Actions. To cut a release:

Bump the version in pyproject.toml and src/bumpguard/__init__.py.
Move the CHANGELOG.md "Unreleased" notes under a new version heading.
Commit, then tag and push:

git tag v0.1.0
git push origin v0.1.0

The Release workflow runs the tests, builds the wheel + sdist, and publishes to PyPI via Trusted Publishing (OIDC — no stored tokens). The CI workflow runs the test matrix (Linux + Windows, Python 3.10/3.13) on every push and PR.

License

MIT — see LICENSE.

Available Tools

6 tools

check_importA

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).

ParametersJSON Schema

Name	Required	Description	Default
`package`	Yes
`language`	No		python

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description says it checks installation and suggests names but does not specify side effects, return format, or auth needs. The behavior is partially transparent but lacks detail.

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 with front-loaded purpose. No wasted words. Highly concise and well-structured.

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?

For a simple check tool with no output schema, the description covers purpose and usage. Missing return value explanation, but overall adequate given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description mentions 'package' and 'language' only implicitly via 'Check whether a package is installed' and default language (Python) is not stated. Does not explain parameter formats or options.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks if a package is installed and suggests close names if not. This distinguishes it from siblings like 'check_upgrade' and 'diff_versions'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises to use this before writing an import to avoid hallucinated or typo'd package names, providing clear when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_upgradeA

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.

Args: package: Distribution name to upgrade (e.g. "pandas"). to_version: The version you want to move to (e.g. "2.2.0"). code: The source code that uses the package (a file or snippet). from_version: Optional baseline version; defaults to what is installed. language: Ecosystem provider id. Default "python".

Returns a report with safe_to_upgrade, a severity summary, and per-line findings. Note: analysis is static, so "no findings" means "nothing proven to break", not a guarantee.

ParametersJSON Schema

Name	Required	Default
`package`	Yes
`to_version`	Yes
`code`	Yes
`from_version`	No
`language`	No	python

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses key behavioral traits: static analysis, extraction of public API, diffing, scanning user code, and a disclaimer that 'no findings' is not a guarantee. This fully informs the agent of the tool's behavior and limitations.

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?

The description is concise and well-structured: a one-line intro, a short paragraph on usage, a bulleted list of arguments, and a returns note. Every sentence adds value, and there is no redundant or verbose text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, no output schema, static analysis), the description covers all necessary aspects: purpose, usage timing, parameter details, return format (report with fields), and limitations. It is sufficiently complete for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description clearly explains each parameter in the Args section: package, to_version, code, from_version (optional, defaults to installed), and language (default 'python'). It adds meaningful context beyond the parameter names and types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Check what breaks in YOUR code when you upgrade a dependency.' It uses a specific verb-resource combination and distinctly positions itself among siblings like check_import, diff_versions, etc., which are about different aspects of dependency management.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises 'Call this BEFORE bumping a dependency version,' providing clear when-to-use guidance. It also includes a caveat about static analysis limitations, helping set expectations. While it doesn't explicitly list alternatives, the context and sibling names imply when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

diff_versionsA

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.

ParametersJSON Schema

Name	Required	Default
`package`	Yes
`to_version`	Yes
`from_version`	No
`language`	No	python

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that no code scan occurs and defaults to the installed version, which is helpful. However, it does not mention any other behavioral traits like side effects, required permissions, or rate limits, leaving some transparency gaps.

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?

The description is extremely concise with only two sentences. The first sentence clearly states the purpose and a key constraint, and the second provides usage guidance. No extraneous words.

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?

Given the tool's moderate complexity (4 parameters, no output schema), the description covers the core functionality, usage guidance, and a behavioral note (no code scan). It could elaborate on the output format, but it is largely sufficient for an agent to decide when to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, and the description text adds minimal information about parameters beyond implying that from_version defaults. It does not explain the meaning of 'language' or the format of 'to_version'. The description adds little value over the raw schema for understanding parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('list'), identifies the resource ('API changes between two versions of a package'), and distinguishes from sibling tools like check_upgrade by adding '(no code scan)'. This clearly defines the tool's scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('understand a library's breaking changes in the abstract — e.g. when planning a migration') and when not to ('For 'what breaks in my code', use check_upgrade instead'). Also mentions the default baseline behavior, providing complete guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_languagesA

List the ecosystem providers BumpGuard currently supports.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It only states the tool lists providers, without mentioning safety, data freshness, or any potential side effects. Minimal transparency.

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?

The description is a single concise sentence with no unnecessary words. It is front-loaded and directly communicates the tool's function, earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (no parameters, no output schema), the description is adequate but lacks details about the list's format or what 'ecosystem providers' entails. Contextual completeness is moderate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description adds sufficient meaning beyond the empty schema. Baseline for 0 params is 4, and the description effectively communicates the purpose without additional param details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists ecosystem providers BumpGuard supports, using a specific verb and resource. It distinguishes from sibling tools like check_import and check_upgrade which perform different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or context. For a simple list tool, usage is somewhat implied but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_symbolsA

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.

ParametersJSON Schema

Name	Required	Default
`package`	Yes
`version`	No
`name_filter`	No
`language`	No	python

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description provides key behavioral context: it lists the real API, fetches for a specified version without installing, and allows optional filtering. It does not mention performance or side effects, but as a read-only operation, the disclosure is adequate.

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?

The description is three sentences, each adding distinct value: core purpose, usage context, and optional filtering. It is front-loaded and concise with no wasted words.

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?

Given the tool's complexity (4 parameters, no output schema, no annotations), the description covers the main purpose, usage, and two parameters. Missing the 'language' parameter explanation is a gap, but overall it provides sufficient context for an agent to use the tool effectively.

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 description coverage is 0%, so the description must compensate. It adds meaning for 'version' (fetched without installing) and 'name_filter' (substring of dotted path) but does not explain 'language'. This partial compensation results in a mid-range score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists the real public API (functions, classes, methods, signatures) of a package, emphasizing it avoids guessing. It distinguishes from sibling tools like check_import, check_upgrade, etc., which perform different actions.

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?

The description instructs to use this tool to discover the correct API instead of guessing, and notes it works for the installed version or a specific version. It does not explicitly exclude use cases or mention alternatives, but the context is clear enough for an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_snippetA

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".

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes
`language`	No		python

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the tool performs static analysis, flags missing packages with typo/slopsquat suggestions, and checks attributes/methods on installed modules. It does not mention any destructive actions or side effects, but the tool appears read-only. A small gap is the lack of mention about whether the code is executed or not, but the static analysis statement covers that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two short paragraphs. The first sentence is bold and informative. Every sentence adds value, but the second paragraph could be slightly more structured. Still, it is well-organized and front-loaded with the main purpose.

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?

Given only two parameters and no output schema, the description covers what the tool checks (imports, API calls), how it reports (flags, suggestions), and interpretation guidance. It is complete enough for an agent to use the tool effectively, though it does not specify the return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description does not explain the parameters (code and language). It implies the tool takes code but does not describe the format, expected size, or the possible values for 'language' (only mentions default as python). This leaves the agent to infer parameter usage from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Verify code against the ACTUALLY-INSTALLED packages to catch hallucinations,' clearly stating the verb (verify), resource (code against installed packages), and the problem it solves (hallucinations). It distinguishes from siblings like 'check_import' and 'check_upgrade' by focusing on verifying entire code snippets against the environment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Call this after generating code to check that the imports and API calls it uses really exist in this environment,' providing a clear when-to-use scenario. It also adds interpretation guidance: 'Static analysis only — treat 'medium' findings as 'verify', not 'definitely wrong'.' This helps the agent understand the tool's limitations.

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. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jun 8, 2026
- First observedcheck_import
- First observedcheck_upgrade
- First observeddiff_versions
- First observedlist_languages
- First observedlist_symbols
- First observedverify_snippet

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct operation: checking imports, upgrade impact, version diffs, language listing, symbol listing, and snippet verification. Descriptions explicitly differentiate overlapping use cases, e.g., diff_versions vs. check_upgrade.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_import, list_symbols, verify_snippet), making the set predictable and easy to navigate.

Tool Count5/5

Six tools cover the core concerns of dependency safety and API verification without redundancy or excessive granularity. The scope is well-matched to the server's purpose.

Completeness4/5

The tool surface covers import checking, upgrade impact, API diffing, symbol discovery, and snippet verification. Minor gaps exist (e.g., batch checks or automated fixes), but the core workflow for safe dependency bumps is complete.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
driflyte-mcp-server
com.driflyte
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Search Web Scraping Knowledge & Memory
211
Raziel A
io.github.tide-foundation
MCP server teaching AI agents to implement TideCloak: auth, E2EE, IGA, security analysis
Security Autonomous Agents
202
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2

Related MCP Servers

code-verify-mcp
Code Analysis Developer Tools Testing & QA Tools
sulthonzh
A
license
Not graded
quality
C
maintenance
An MCP server for verifying AI-generated code quality, security, and performance, addressing trust gaps in AI coding assistants.
Updated 2 days ago (2026-09-04 17:06 UTC)
MIT
Asyntheticofficial
Code Analysis Developer Tools Documentation Access
asyntheticai
A
license
A
quality
B
maintenance
An MCP server that gives AI coding agents verified migration maps: exactly what breaks between two versions of a library and how to fix it, from hand-curated maps with source citations - instead of hallucinated answers from stale training data
Updated 2 months ago (2026-07-05 13:51 UTC)
5
60
Business Source 1.1
argot
Code Analysis Developer Tools
get-tmonier
A
license
A
quality
A
maintenance
A local guardrail MCP server that checks agent-written code against a repo's own patterns — learned statistically from its git history, no LLM.
Updated 4 days ago (2026-09-02 07:55 UTC)
6
48
MIT
RegressGuard
Testing & QA Tools CI/CD & DevOps Developer Tools
Bharath-code
A
license
Not graded
quality
A
maintenance
RegressGuard is an MCP server that records a known-good baseline and lets AI coding agents detect regressions (broken API contracts, failing tests, schema changes) during their edit loop, allowing them to self-correct before committing.
Updated 2 months ago (2026-07-18 16:06 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/appcreationsca/bumpguard-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

BumpGuard

Why this exists

What it does

Tools

Install

Configure your MCP client

How it works

Multi‑language by design

.NET specifics (v1)

Java specifics (v1)

Known limitations (v1, Python)

Development

Releasing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Asyntheticofficial

Latest Blog Posts

MCP directory API