Skip to main content
Glama
Sign In
BumpGuard

BumpGuard

by appcreationsca
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

verify_snippet

Verify code against installed packages to catch hallucinations. Checks that imports and API calls exist, flagging missing packages and invalid attributes.

Instructions

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

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>"
    },
    "name": "verify_snippet"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYes
languageNopython

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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.

Deploy Server

Other Tools