Skip to main content
Glama
RP-Digital-Innovations

Context Snipe

by RP-Digital-Innovations
OverviewSchemaRelated ServersScoreDiscussions
Rust
Local

CI License: MIT GitHub release MCP

Works with: Claude Desktop · Cursor · Windsurf · VS Code · Zed · any MCP client

$ context-snipe scan .

context-snipe — vulnerability scan
Project: ./my-api
Scanned: 412 entries (388 unique packages) from Cargo.lock, package-lock.json

FOUND  3 advisories affecting 2 of 388 package(s):

  lodash 4.17.11  [npm]
    [CRIT] CVE-2019-10744  Prototype Pollution in lodash
    [HIGH] CVE-2021-23337  Command Injection in lodash

  minimatch 3.0.4  [npm]
    [HIGH] CVE-2022-3517   minimatch ReDoS vulnerability

Source: OSV.dev — packages actually in your resolved dependency tree.

The problem

You ask Cursor or Claude: "Does my project have any security issues?"

It doesn't know your packages. It doesn't know your versions. It hallucinates an answer based on general knowledge — not your actual package-lock.json.

Your scanner (Dependabot, Snyk, whatever) floods you with 200 warnings, most of which don't apply to what you actually ship. You spend 45 minutes Googling CVEs that are irrelevant to your code.

context-snipe closes both gaps. It reads your resolved lockfiles (not your package.json — your actual installed packages), asks OSV.dev only about what you have, deduplicates the noise, ranks by real CVSS severity, and gives your AI a clean, accurate briefing it can actually reason about.

Related MCP server: CodeCortX-MCP

Install in 30 seconds

macOS / Linux — one line, picks the right binary for your platform:

curl -fsSL https://raw.githubusercontent.com/RP-Digital-Innovations/context-snipe/main/install.sh | sh

Windows (PowerShell):

irm https://raw.githubusercontent.com/RP-Digital-Innovations/context-snipe/main/install.ps1 | iex

Rust users — from crates.io:

cargo install context-snipe        # build from source
cargo binstall context-snipe       # or grab the prebuilt binary, no compile

Grab the binary for your platform from the latest release:

Platform

Asset

macOS (Apple Silicon)

context-snipe-aarch64-apple-darwin

macOS (Intel)

context-snipe-x86_64-apple-darwin

Linux x86_64

context-snipe-x86_64-linux

Linux ARM64

context-snipe-aarch64-linux

Windows x86_64

context-snipe-x86_64-pc-windows.exe

chmod +x it and move it onto your PATH.

Verify:

context-snipe --version

Add to your AI tool (60 seconds)

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "context-snipe": {
      "command": "context-snipe",
      "args": ["serve"]
    }
  }
}

Cursor

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "context-snipe": {
      "command": "context-snipe",
      "args": ["serve"]
    }
  }
}

Windsurf

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "context-snipe": {
      "command": "context-snipe",
      "args": ["serve"]
    }
  }
}

Restart your editor. Then ask your AI: "Check this project for vulnerable dependencies."

What your AI can now do

MCP Tool

What it does

scan_dependencies

Lists every resolved package in your project (name, version, ecosystem)

check_vulnerabilities

Cross-references your packages against OSV.dev — returns only advisories that affect what you actually have installed

Your AI goes from guessing to knowing. In one tool call.

Supported ecosystems

Ecosystem

Resolved lockfile (preferred)

Fallback

Rust

Cargo.lock

—

npm

pnpm-lock.yaml, yarn.lock, package-lock.json v1–v3

package.json

Python

poetry.lock, uv.lock

requirements.txt (pinned ==)

Go

go.sum

go.mod

How it compares

context-snipe

Dependabot

Snyk

socket.dev

MCP native — AI gets the results directly

✅

❌

❌

❌

Reads resolved lockfiles (not just manifests)

✅

✅

✅

✅

100% local — nothing leaves your machine

✅

❌

❌

❌

No account, no signup, no API key

✅

❌

❌

❌

Binary size

~1 MB

N/A

200 MB+

N/A

Free, open source

✅

✅

Partial

Partial

CLI usage

context-snipe scan [PATH]    # vulnerability report (defaults to current dir)
context-snipe deps [PATH]    # list the full resolved dependency tree
context-snipe serve          # start the MCP server over stdio
context-snipe --help

A note on honesty

context-snipe tells you which vulnerable packages are present in your resolved dependency tree. It does not perform call-graph reachability analysis. Presence is not proof of exploitability — the vulnerable function may not be reachable in your code. The tool says so in its own output, by design.

No tool that runs in seconds can tell you a CVE is definitely not exploitable. We won't pretend otherwise.

How it works

  • MCP engine — hand-rolled JSON-RPC 2.0 over stdio. initialize, tools/list, tools/call, ping. stdout is the protocol channel; all diagnostics go to stderr.

  • Lockfile parsers — TOML for Cargo, JSON for npm, custom parsers for pnpm/yarn, line parsers for requirements.txt and Go modules.

  • OSV client — one querybatch call filters the full tree to packages with advisories, then a focused query per hit pulls details. CVSS v3.x base scores computed from vector strings. Duplicate advisories sharing a CVE are merged.

  • TLS via rustls — pure-Rust, no OpenSSL, no system crypto dependency. Works identically on Windows, macOS, and musl Linux.

Build from source

cargo build --release
# Binary at: target/release/context-snipe

Requires stable Rust. The release profile statically links the CRT — the binary is fully self-contained.

Roadmap

  • GitHub App — post CVE diffs on pull requests (shows what a PR introduces)

  • Policy layer — configurable CI failure thresholds per severity

  • More ecosystems — Ruby (Gemfile.lock), PHP (composer.lock), Java (pom.xml)

Contributing

PRs welcome. The codebase is ~1,000 lines of Rust split across:

src/
  main.rs    — CLI entry, mode routing
  mcp.rs     — JSON-RPC / MCP server
  deps.rs    — lockfile parsers
  osv.rs     — OSV.dev client + CVSS scoring
  scan.rs    — orchestration + report formatting
  http.rs    — ureq + rustls HTTP agent

Good first issues: adding a new lockfile format, improving CVSS display, adding output formats (JSON, SARIF).

License

MIT — free forever. No telemetry. No accounts. No cloud.

Available Tools

2 tools
check_vulnerabilitiesA

Cross-reference a project's resolved dependencies against the OSV.dev vulnerability database and report which packages have known advisories (CVE/GHSA/RUSTSEC/PYSEC), with computed severity. Only reports advisories for packages actually present in the dependency tree — not generic noise. Requires network access to api.osv.dev.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoPath to the project directory. Defaults to the current working directory.
severity_minNoOptional. Only report advisories at or above this severity.

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 covers key behaviors: it is a read-only check (implied), requires network access, and only reports advisories for packages in the dependency tree. It does not mention side effects or permissions, but the read-only nature is clear.

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 two sentences, front-loaded with the core purpose, followed by a clarifying statement and a note on requirements. Every sentence adds value with no redundancy.

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 has two parameters and no output schema, the description explains the main behavior, scope, and constraint (network access). It could mention how dependencies are resolved or the output format, but the provided information is sufficient for an agent to understand the tool's function.

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?

The schema covers 100% of parameters with descriptions. The tool description does not add additional meaning beyond the schema (e.g., no details on 'path' or 'severity_min'). Baseline 3 is appropriate as the schema already documents the parameters adequately.

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 provides a specific verb ('cross-reference') and resource ('project's resolved dependencies against the OSV.dev vulnerability database'), and clearly differentiates from the sibling tool 'scan_dependencies' by focusing on vulnerability advisories rather than generic dependency scanning.

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 states when to use (to get relevant advisories for actual dependencies) and mentions a requirement (network access). However, it does not explicitly state when not to use or contrast with alternatives beyond the sibling distinction.

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

scan_dependenciesA

List a project's resolved dependencies by parsing its lockfiles/manifests (Cargo.lock, package-lock.json, package.json, requirements.txt, go.mod/go.sum). Returns each dependency's name, version, and ecosystem. Use this to give the assistant ground-truth about exactly which packages and versions a project actually uses.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoPath to the project directory. Defaults to the current working directory.

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 fully explains behavior: it parses specific files and returns dependency details. It does not disclose side effects, but the tool is likely read-only. The description is sufficiently transparent for a simple listing tool.

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 two sentences with no wasted words. It front-loads the key action and list of files, then explains utility. Every sentence adds value.

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?

The tool is simple (one parameter, no output schema). The description covers what, how, and why. It does not mention error handling or behavior when no lockfiles are found, but it's otherwise complete.

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?

There is only one parameter (path) with 100% schema coverage. The description adds context about the path being the project directory, but the schema already describes it. The description does not go into depth beyond the schema, earning a baseline 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 specifies the tool lists resolved dependencies by parsing lockfiles/manifests, naming specific files (Cargo.lock, package-lock.json, etc.) and return fields (name, version, ecosystem). It clearly distinguishes from sibling check_vulnerabilities.

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 advises using it to give the assistant ground-truth about project dependencies, indicating clear context for use. It does not explicitly exclude scenarios or mention when not to use it, but the sibling tool provides a natural alternative.

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.

  1. 2 tool updatesv0.3.0
    • First observedcheck_vulnerabilities
    • First observedscan_dependencies
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0
Disambiguation5/5

The two tools have completely distinct purposes: one scans project dependencies and the other checks them against a vulnerability database. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools follow a clear verb_noun pattern: scan_dependencies and check_vulnerabilities, making the action and target immediately clear.

Tool Count4/5

With only two tools, the server is minimal but well-scoped for its purpose. Each tool serves a necessary function, and the count is appropriate given the narrow focus.

Completeness4/5

The tool set covers the core workflow of listing dependencies and checking for known vulnerabilities. Minor gaps exist, such as lacking ability to fetch detailed advisory information or take action on findings, but the basic functionality is complete.

Maintenance

ActivityStale
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • CodeCortX-MCP

    kensave
    F
    license
    Not graded
    quality
    D
    maintenance
    A lightning-fast, language-agnostic code analysis MCP (Model Context Protocol) server built in Rust
    9
    -

  • Repo Interrogator

    taggedzi
    A
    license
    A
    quality
    A
    maintenance
    A local-first MCP server that enables AI tools to safely inspect and search code repositories, providing indexing, deterministic BM25 search, code outlining, and context bundles without code modification.
    9
    1
    MIT

  • uacos

    caotiensinh
    A
    license
    Not graded
    quality
    B
    maintenance
    Local-first code intelligence and safety layer for AI coding agents. MCP server exposes dependency graph, impact analysis, and AST-compressed repo context, backed by typed local memory, patch-scope safety gates, and git-independent transaction rollback.
    1
    MIT

Latest Blog Posts

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/RP-Digital-Innovations/context-snipe'

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