Skip to main content
Glama

Overview

What It Is

VulnPilot is an open-source Model Context Protocol (MCP) server that arms AI coding assistants with deep, contextual dependency analysis. It enables AI agents to query vulnerability advisories in real time, analyze whether vulnerable code paths are actually imported in your project, enrich findings with real-world threat telemetry, and output self-contained HTML security dashboards.

Why It Is

Modern AI coding assistants (such as Claude Desktop, Cursor, and VS Code Copilot) excel at writing code, suggesting libraries, and refactoring projects. However, AI agents operate blindly regarding security posture:

  • They do not know if a recommended package version contains known security vulnerabilities.

  • They cannot differentiate between a vulnerability in production code versus one isolated in test utilities.

  • They lack real-world threat intelligence to determine if a CVE is actively exploited by threat actors or merely a theoretical risk.

VulnPilot bridges this gap by giving AI assistants native MCP tools to inspect package manifests, parse source code parse-trees, evaluate active exploit databases, and prioritize remediation accurately.

How Beneficial It Is

  • Noise Reduction: Avoid blanket package upgrades by identifying whether vulnerable code is actually reachable in your project or restricted to test suites.

  • Real-World Threat Telemetry: Enriches raw CVE identifiers with FIRST EPSS probability scores (likelihood of exploitation in the next 30 days) and CISA KEV catalog indicators (known active cyberattacks and ransomware campaigns).

  • Direct vs. Transitive Detection: Automatically inspects lock files (uv.lock, poetry.lock, package-lock.json, yarn.lock, etc.) and manifests to distinguish top-level dependencies from sub-dependencies.

  • Zero Friction Setup: No external API keys, complex setup, or cloud subscriptions required. Runs locally via STDIO.

  • Polished HTML Security Dashboards: Generates interactive, portable HTML reports complete with executive summaries, sortable vulnerability tables, and color-coded risk gauges.

For Whom It Is

VulnPilot is built for:

  • Software Engineers: Seeking automated security checks while writing code alongside AI assistants.

  • Security & DevOps Teams: Requiring evidence-based vulnerability triage without false-alarm alerts.

  • AI Pair Programmers: Developers using Claude Desktop, Cursor, VS Code Copilot, Zed, Windsurf, or custom agentic workflows who want their AI assistants to write secure, audited code by default.


Related MCP server: mcp-pypi

Core Ecosystems & Intelligence Sources

Supported Ecosystems

Ecosystem

Vulnerability Lookup

Static Reachability Analysis

Scope & Direct/Transitive Detection

Package Coordinate Format

Example

PyPI

Yes (check_package)

Yes (analyze_python_reachability)

Direct & Transitive

package-name

django

npm

Yes (check_package)

Yes (analyze_javascript_reachability)

Direct & Transitive

package-name

lodash

Maven

Yes (check_package)

Yes (analyze_java_reachability)

Direct & Transitive

groupId:artifactId

org.apache.logging.log4j:log4j-core

Gradle

Yes (check_package)

Yes (analyze_java_reachability)

Direct & Transitive

groupId:artifactId

com.google.guava:guava

Threat Intelligence Telemetry

  • OSV.dev API: Real-time vulnerability advisories from PyPI, npm, Maven, and OSV databases.

  • FIRST EPSS (Exploit Prediction Scoring System): Probability metrics detailing the likelihood of a vulnerability being exploited in the wild within 30 days.

  • CISA KEV (Known Exploited Vulnerabilities): Catalog flagging vulnerabilities actively exploited in real-world cyberattacks or ransomware campaigns.


Quickstart

Prerequisites

Requirement

Minimum Version

Recommended Tool

Python

$\ge$ 3.10

Installed system Python

uv

Latest

Astral uv package manager

Installation

# Clone the repository
git clone https://github.com/arojit/vulnpilot-mcp.git
cd vulnpilot-mcp

# Sync environment and install dependencies
uv sync

Verify Installation

Optionally, run this to confirm the server starts correctly before configuring your MCP client:

uv run vulnpilot-mcp

Note: You do not need to run this manually during normal use. Your MCP client (Claude Desktop, Cursor, VS Code, etc.) launches the server process automatically via the configuration below. Simply configure the client and restart it.


MCP Client Setup

Configure VulnPilot in your preferred AI environment:

Add the server configuration to claude_desktop_config.json:

{
  "mcpServers": {
    "vulnpilot": {
      "command": "/absolute/path/to/uv",
      "args": [
        "--directory", "/absolute/path/to/vulnpilot-mcp",
        "run", "vulnpilot-mcp"
      ]
    }
  }
}

Add the server configuration to .cursor/mcp.json:

{
  "mcpServers": {
    "vulnpilot": {
      "command": "/absolute/path/to/uv",
      "args": [
        "--directory", "/absolute/path/to/vulnpilot-mcp",
        "run", "vulnpilot-mcp"
      ]
    }
  }
}

Add the server configuration to .vscode/mcp.json:

{
  "servers": {
    "vulnpilot": {
      "command": "/absolute/path/to/uv",
      "args": [
        "--directory", "/absolute/path/to/vulnpilot-mcp",
        "run", "vulnpilot-mcp"
      ]
    }
  }
}

Path Configuration Note: Replace /absolute/path/to/uv with your system path to uv (obtain via which uv) and replace /absolute/path/to/vulnpilot-mcp with the exact directory location where you cloned the repository.

Corporate Network & SSL Custom Root CAs: If your system uses corporate SSL proxies or custom root certificates, include the --system-certs argument:

"args": [
  "--directory", "/absolute/path/to/vulnpilot-mcp",
  "run", "--system-certs", "vulnpilot-mcp"
]

Recommended Audit Prompt: Use this prompt with your connected AI client to invoke all VulnPilot tools (check_package, analyze_reachability, generate_report) in a single automated workflow:

Run a full VulnPilot security audit on this project: check package vulnerabilities, analyze code reachability, and generate the HTML security report.

How It Works

VulnPilot follows a structured five-stage workflow to deliver contextual security intelligence to your AI assistant:

[ 1. Package Vulnerability Check ] ──> [ 2. Direct vs. Transitive Inspection ]
                                                      │
[ 5. HTML Report Generation ] <── [ 4. Priority Triage Engine ] <── [ 3. Reachability Analysis ]

Stage 1: Package Vulnerability Lookup (check_package)

  1. The AI assistant invokes check_package with a package coordinate and version number.

  2. VulnPilot fetches advisories from OSV.dev and normalizes vulnerability records.

  3. Extracted CVE identifiers are cross-referenced with FIRST EPSS and CISA KEV databases.

Stage 2: Direct vs. Transitive Dependency Classification

  1. VulnPilot inspects project manifests (pyproject.toml, package.json, pom.xml, build.gradle) and lock files (uv.lock, poetry.lock, package-lock.json, yarn.lock, etc.).

  2. The dependency is categorized as direct (declared explicitly) or transitive (pulled in indirectly by sub-dependencies).

Stage 3: Static Code Reachability Analysis (analyze_*_reachability)

  1. VulnPilot scans source code files using Abstract Syntax Tree (AST) parsing for Python, or structured token scanning for JavaScript, TypeScript, and Java.

  2. It detects import statements and determines whether usage exists in production source code or is restricted to test directories.

Stage 4: Triage Priority Engine

VulnPilot calculates a remediation priority score based on deterministic risk criteria:

Priority Level

Condition

Rationale

IMMEDIATE

Listed in CISA KEV catalog (known_exploited = true)

Actively exploited in cyberattacks or ransomware campaigns in the wild.

URGENT

Reachable in production (is_reachable = true) AND EPSS probability $\ge 0.5$

High probability of imminent exploit on an active code path.

HIGH

Production dependency (dependency_scope = "production") AND severity is CRITICAL

Critical vulnerability exposed directly in production code.

NORMAL

Default fallback for all other vulnerabilities

Lower overall risk, theoretical issue, or restricted to test/development files.

Stage 5: Interactive HTML Report Generation (generate_report)

  1. Results from vulnerability checks and reachability analyses are aggregated.

  2. VulnPilot renders a self-contained HTML report featuring executive statistics, interactive tables, color-coded badges, and remediation recommendations.

  3. The generated report file is saved to .vulnpilot/vulnpilot-report-{timestamp}.html.

Sample Report: View an interactive sample report generated by VulnPilot: https://arojit.github.io/vulnpilot-mcp/


Tool Reference

VulnPilot exposes native MCP Tools, Prompts, and Resources.


check_package

Queries vulnerability databases for a given package version and enriches results with EPSS probability and CISA KEV indicators.

Arguments

Argument

Type

Default

Description

package_name

string

Required

Package coordinate (e.g. django, lodash, org.apache.logging.log4j:log4j-core)

version

string

Required

Exact version string (e.g. 2.2.0, 2.14.1)

ecosystem

string

"PyPI"

Ecosystem choice: PyPI, npm, Maven, or Gradle

is_reachable

boolean

null

Optional signal indicating if vulnerable code path is imported in project

dependency_scope

string

"unknown"

Usage scope: production, development, or unknown


Reachability Analysis Tools

Static code analysis tools verify whether a package is imported in project source files and classify code locations as production vs. test.

  • analyze_python_reachability: Scans Python projects using ast parse-trees. Inspects pyproject.toml, setup.cfg, requirements.txt, and lock files (uv.lock, poetry.lock, pdm.lock, pylock.toml).

  • analyze_javascript_reachability: Scans JavaScript and TypeScript projects (.js, .ts, .jsx, .tsx, .mjs, .cjs). Inspects package.json and lock files (package-lock.json, yarn.lock, pnpm-lock.yaml).

  • analyze_java_reachability: Scans Java projects. Detects Maven (pom.xml) and Gradle (build.gradle, build.gradle.kts) dependencies.

Common Arguments

Argument

Type

Default

Description

project_path

string

Required

Absolute path to the root directory of the project being audited

package_name

string

Required

Package name (use groupId:artifactId for Maven and Gradle)

import_names

string[]

Auto-derived

Custom import module overrides (e.g. ["bs4"] for beautifulsoup4)


generate_report

Compiles scan results into a self-contained, interactive HTML security dashboard.

Arguments

Argument

Type

Default

Description

results

PackageReport[]

Required

Aggregated list of package report objects from check_package and reachability tools

project_name

string

"Project"

Display title for report header

ecosystem

string

"PyPI"

Primary ecosystem (PyPI, npm, Maven, Gradle)

output_dir

string

".vulnpilot"

Target directory for saving HTML report

The generated file is saved to .vulnpilot/vulnpilot-report-{timestamp}.html.

Sample HTML Report Output: Inspect a live sample report output: https://arojit.github.io/vulnpilot-mcp/


Example Usage


MCP Prompts

Prompts provide structured, multi-step instruction templates for AI clients:

  • security_audit: Guides the AI assistant to audit an entire list of dependencies, evaluate reachability for vulnerable findings, and construct an executive security summary.

  • triage_vulnerability: Conducts a deep-dive triage on a specific package version, checking exploit telemetry and code reachability.

  • generate_dependency_evidence: Provides terminal commands needed to produce dependency tree metadata for ecosystems lacking default lock files.


MCP Resources

Read-only reference documents for AI assistants:

Resource URI

Name

Format

Purpose

vulnpilot://supported-ecosystems

Supported Ecosystems

application/json

Schema definitions, supported package formats, and example coordinates.

vulnpilot://triage-rules

Triage Priority Rules

text/markdown

Formal rules explaining priority assignment logic (IMMEDIATE to NORMAL).

vulnpilot://dependency-evidence-guide

Dependency Evidence Guide

text/markdown

Terminal instructions for exporting dependency lock files and tree reports.


Dependency Evidence Guide

VulnPilot automatically parses existing lock files and project manifests. For projects without built-in lock files, generate dependency metadata using these commands (run from your target project root):

If using standard pip without a lockfile, export package metadata:

mkdir -p .vulnpilot
python -m pip inspect --local > .vulnpilot/pip-inspect.json

If the virtual environment is not activated:

mkdir -p .vulnpilot
.venv/bin/python -m pip inspect --local > .vulnpilot/pip-inspect.json

No command required when standard lock files exist:

  • uv.lock (uv)

  • poetry.lock (Poetry)

  • pdm.lock (PDM)

  • pylock.toml (PEP 751)

No command required when standard lock files exist:

  • package-lock.json (npm)

  • yarn.lock (Yarn)

  • pnpm-lock.yaml (pnpm)

Export the dependency tree report:

mkdir -p .vulnpilot
mvn dependency:tree -DoutputFile=.vulnpilot/maven-dependency-tree.txt

Export the runtime dependency tree:

mkdir -p .vulnpilot
./gradlew dependencies --configuration runtimeClasspath > .vulnpilot/gradle-dependencies.txt

For test dependencies:

mkdir -p .vulnpilot
./gradlew dependencies --configuration testRuntimeClasspath > .vulnpilot/gradle-test-dependencies.txt

Git Configuration Tip: Add .vulnpilot/ to your project's .gitignore file to avoid committing local scan reports and evidence dumps.


Development & Testing

Installation for Contributors

# Install all development tools and dependencies
uv sync --all-groups

Running Test Suites

# Execute pytest suite
uv run pytest

Testing with MCP Inspector

Test tools interactively in your browser using the MCP Inspector GUI:

uv run mcp dev src/vulnpilot/server.py

Project File Hierarchy

vulnpilot-mcp/
├── src/vulnpilot/
│   ├── __init__.py               # Package marker
│   ├── server.py                 # MCP server tools, prompts, and resources
│   ├── models.py                 # Pydantic data schemas
│   ├── osv_client.py             # OSV.dev API client & normalizer
│   ├── epss_client.py            # FIRST EPSS API client
│   ├── cisa_kev_client.py        # CISA KEV catalog client
│   ├── triage.py                 # Priority triage engine
│   ├── cve_utils.py              # CVE regex and utility parsers
│   ├── report_generator.py        # Interactive HTML report renderer
│   └── reachability/             # Language-specific reachability scanners
│       ├── __init__.py          # Module re-exports
│       ├── _common.py           # Shared path parsing & evidence classification
│       ├── python_reachability.py
│       ├── python_dependencies.py
│       ├── javascript_reachability.py
│       ├── javascript_dependencies.py
│       ├── java_reachability.py
│       └── java_dependencies.py
├── tests/                        # Comprehensive unit & integration tests
├── pyproject.toml                # Project build metadata & dependencies
└── README.md

Enhancements

This section documents planned and shipped improvements that increase scanning efficiency and developer ergonomics.

Batch Package Scanning with Concurrent API Calls

Status: Planned

Problem: The current check_package tool accepts a single package at a time, meaning an AI agent auditing 30 dependencies must make 30 sequential API calls - each waiting for the previous one to complete.

Enhancement: Accept a list of { package_name, version, ecosystem, is_reachable, dependency_scope } objects in a single check_package invocation, then dispatch each lookup concurrently using Python's concurrent.futures.ThreadPoolExecutor. Results are collected and returned as an ordered list, preserving per-package attribution.

Benefits:

  • Speed: Wall-clock scan time for N packages approaches the latency of a single lookup instead of N × latency.

  • Ergonomics: AI agents issue one tool call per audit instead of one per dependency.

  • Unchanged interface contract: Each individual result object retains the same schema as today.

Example batch input (proposed):

{
  "packages": [
    { "package_name": "django",   "version": "3.2.0",  "dependency_scope": "production" },
    { "package_name": "requests", "version": "2.25.0", "dependency_scope": "production" },
    { "package_name": "pytest",   "version": "7.1.0",  "dependency_scope": "development" }
  ],
  "ecosystem": "PyPI"
}

Technology Stack

Component Layer

Technology

MCP Framework

FastMCP (mcp[cli])

Data Validation

Pydantic v2

HTTP Client

httpx

Vulnerability Data

OSV.dev API

Exploit Telemetry

FIRST EPSS & CISA KEV Catalog

Build Backend

Hatchling

Package Manager

uv

Testing Engine

pytest with pytest-asyncio


License

This project is licensed under the Apache License 2.0. See the LICENSE file for details.

Available Tools

3 tools
analyze_reachabilityA
Analyze a project to determine whether a package is actually imported.

Statically scans source files for imports of the given package and
classifies each usage as production or test-only. Supports Python
(PyPI), JavaScript/TypeScript (npm), and Java (Maven/Gradle).

Args:
    project_path: Absolute path to the project root directory.
    package_name: Package name to look for. Use groupId:artifactId for Maven/Gradle.
    ecosystem: One of PyPI, npm, Maven, or Gradle. Determines which scanner to use.
    import_names: Override the import name when it differs from the package name
                  (e.g. ["bs4"] for beautifulsoup4, or a Java package prefix).
ParametersJSON Schema
NameRequiredDescriptionDefault
ecosystemNoPyPI
import_namesNo
package_nameYes
project_pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
used_inNo
ecosystemYes
test_onlyYes
limitationsNo
usage_foundYes
build_systemNo
import_namesYes
package_nameYes
reachabilityYes
dependency_typeNo
internet_facingNo
dependency_evidenceNo
vulnerable_api_usedNo
production_usage_foundYes

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries full burden. It explains the behavior (static scanning, classification by environment, multi-ecosystem support) but omits details like error handling, performance implications, or limitations (e.g., dynamic imports). This is adequate but not rich.

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 at 4 sentences plus a bullet list for Args. It is front-loaded with the main purpose. The Args section could be slightly more compact, but every line adds value. 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's 4 parameters (2 required, 1 enum) and the presence of an output schema, the description covers the behavioral and parameter context well. It does not mention return values, but the output schema already handles that. Overall, it is sufficiently complete for an agent to use 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?

Schema coverage is 0%, so the description fully compensates. It explains each parameter: project_path (absolute path), package_name (format for Maven/Gradle), ecosystem (enum with values), and import_names (override examples like 'bs4' for beautifulsoup4). This adds essential meaning beyond the schema's bare definitions.

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: 'Analyze a project to determine whether a package is actually imported.' It specifies static scanning and classification into production/test-only, and distinguishes from sibling tools like check_package and generate_report by focusing on actual import usage rather than package metadata or report generation.

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

Usage Guidelines3/5

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

The description provides context on supported ecosystems and parameter usage, but lacks explicit guidance on when to use this tool versus alternatives like check_package or generate_report. It does not state when not to use it, leaving the agent to infer from the broader scope.

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

check_packageA
Read-onlyIdempotent

Check an exact dependency version for known vulnerabilities.

Use this tool when the user asks whether a Python, npm, Maven,
or Gradle dependency version is vulnerable.

For Gradle JVM dependencies, use the Maven ecosystem and provide
the package as groupId:artifactId.

Args:
    package_name: Package name, or groupId:artifactId for Maven. Example: django, org.apache.logging.log4j:log4j-core
    version: Exact installed dependency version. Example: 2.2.0, 2.14.1
    ecosystem: One of PyPI, npm, or Maven.
ParametersJSON Schema
NameRequiredDescriptionDefault
versionYes
ecosystemNoPyPI
is_reachableNo
package_nameYes
dependency_scopeNounknown

Output Schema

ParametersJSON Schema
NameRequiredDescription
versionYes
ecosystemYes
vulnerableYes
package_nameYes
vulnerabilitiesNo
enrichment_warningsNo
vulnerability_countYes

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds scope (exact version, ecosystems) but no additional behavioral traits beyond annotations. With rich annotations, a 3 is appropriate.

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?

Every sentence serves a purpose: clear function, usage timing, special case for Gradle, and concise parameter explanations. No wasted words, front-loaded with core intent.

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?

The description covers core functionality and key parameters, but omits explanation for optional parameters (is_reachable, dependency_scope). Output schema exists, so return values are not required, but the gap on optional params reduces completeness.

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 coverage is 0%, but the description explains package_name (as name or groupId:artifactId), version (exact version), and ecosystem (one of three). However, it omits is_reachable and dependency_scope, leaving part of the schema undocumented.

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 an exact dependency version for known vulnerabilities, specifying ecosystems (Python, npm, Maven, Gradle) and providing an example for Maven. This distinguishes it from siblings like analyze_reachability and generate_report.

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 explicitly says 'Use this tool when the user asks whether a ... dependency version is vulnerable.' It gives clear context for invocation but does not exclude alternatives or mention when not to use it, though the purpose is well-defined.

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

generate_reportA
Idempotent

Generate a polished HTML security report from scan results.

Accepts aggregated results from check_package and
analyze_reachability, and produces a self-contained HTML
report with executive summary, sortable vulnerability table,
risk gauge, and actionable recommendations.

The report is saved to disk and the path is returned.

Args:
    results: List of PackageReport objects, each combining
        a PackageCheckResult with an optional
        ReachabilityResult.
    project_name: Human-readable project name for the
        report header.
    ecosystem: One of PyPI, npm, Maven, or Gradle.
    output_dir: Directory to save the report into.
        Created if it does not exist.
ParametersJSON Schema
NameRequiredDescriptionDefault
resultsYes
ecosystemNoPyPI
output_dirNo.vulnpilot
project_nameNoProject

Output Schema

ParametersJSON Schema
NameRequiredDescription
high_countNo
report_htmlYes
report_pathYes
normal_countNo
urgent_countNo
total_packagesYes
immediate_countNo
vulnerable_packagesYes
total_vulnerabilitiesYes

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds useful behavioral context: the report is saved to disk, the output directory is created if needed, and the path is returned. This goes beyond the annotations, though it doesn't clarify whether file overwriting occurs (which is relevant for idempotency claims).

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 well-structured and efficient. It opens with a clear purpose statement, follows with a context paragraph, and then lists parameters in an Args block. Every sentence adds value; no redundancy or fluff.

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 involves file I/O and complex inputs. With an output schema present, return values need not be detailed. The description covers input sources, output characteristics, and parameter behavior. It lacks clarity on file overwrite behavior and error handling, but given the annotations and schema, it is mostly complete.

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?

Schema description coverage is 0%, so the description must compensate. It does so excellently: for each parameter, it provides a meaningful explanation (e.g., 'List of PackageReport objects', 'Human-readable project name', etc.) that adds semantic richness beyond the bare schema types/enums.

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 states a specific verb ('Generate'), resource ('polished HTML security report'), and scope ('from scan results'). It details report contents (executive summary, vulnerability table, etc.) and distinguishes from sibling tools (check_package, analyze_reachability) which are data collection tools, not report generators.

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 explicitly states it accepts aggregated results from check_package and analyze_reachability, giving clear context on when to use this tool (after those). While it doesn't explicitly say when not to use, the dependency on prerequisites is clear. Alternatives are not applicable as siblings are prerequisites, not competitors.

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. 3 tool updatesv0.1.0
    • First observedanalyze_reachability
    • First observedcheck_package
    • First observedgenerate_report

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose: check_package queries vulnerability databases, analyze_reachability scans project imports, and generate_report compiles results into an HTML report. No overlapping functionality.

Naming Consistency5/5

All tool names follow the verb_noun pattern in snake_case (check_package, analyze_reachability, generate_report), ensuring predictability and clarity.

Tool Count5/5

Three tools cover the essential workflow of vulnerability checking, reachability analysis, and report generation. The count is well-scoped for a security scanning server.

Completeness4/5

The toolset covers the core lifecycle: check vulnerabilities, analyze reachability, and generate reports. A minor gap is the lack of a tool to directly retrieve detailed advisory information, but the report tool compensates.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

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/arojit/vulnpilot-mcp'

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