VulnPilot
VulnPilot is an MCP server that provides AI assistants with contextual software composition analysis, exploit intelligence, and automated security report generation. It works entirely locally with no external API keys, supporting PyPI, npm, Maven, and Gradle ecosystems.
Check Package Vulnerabilities (
check_package): Query an exact package version against OSV.dev, enriched with EPSS exploitation probability, CISA KEV indicators, severity scores, fixed versions, and prioritized triage levels (IMMEDIATE, URGENT, HIGH, NORMAL).Analyze Code Reachability (
analyze_reachability): Statically scan project source to determine if a vulnerable package is actually imported, classify usage as production or test, identify direct vs. transitive dependencies, and assign a confidence rating.Generate HTML Security Reports (
generate_report): Create a self-contained, interactive dashboard with executive summary, sortable vulnerability tables, risk gauges, and actionable remediation recommendations.Automated Security Audits: Combine all tools to run a full vulnerability check, reachability analysis, and report generation in one workflow.
Threat Intelligence Integration: Leverage real-time data from OSV.dev, EPSS, and CISA KEV, including known exploited vulnerabilities and ransomware campaign associations.
Zero-friction Setup: Local execution via MCP STDIO; works with Claude Desktop, Cursor, VS Code, and other MCP clients without API keys or cloud subscriptions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@VulnPilotCheck my project's dependencies for vulnerabilities and reachability."
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.
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 ( | Yes ( | Direct & Transitive |
|
|
npm | Yes ( | Yes ( | Direct & Transitive |
|
|
Maven | Yes ( | Yes ( | Direct & Transitive |
|
|
Gradle | Yes ( | Yes ( | Direct & Transitive |
|
|
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 |
Installation
# Clone the repository
git clone https://github.com/arojit/vulnpilot-mcp.git
cd vulnpilot-mcp
# Sync environment and install dependencies
uv syncVerify Installation
Optionally, run this to confirm the server starts correctly before configuring your MCP client:
uv run vulnpilot-mcpNote: 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/uvwith your system path touv(obtain viawhich uv) and replace/absolute/path/to/vulnpilot-mcpwith 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-certsargument:"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)
The AI assistant invokes
check_packagewith a package coordinate and version number.VulnPilot fetches advisories from OSV.dev and normalizes vulnerability records.
Extracted CVE identifiers are cross-referenced with FIRST EPSS and CISA KEV databases.
Stage 2: Direct vs. Transitive Dependency Classification
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.).The dependency is categorized as
direct(declared explicitly) ortransitive(pulled in indirectly by sub-dependencies).
Stage 3: Static Code Reachability Analysis (analyze_*_reachability)
VulnPilot scans source code files using Abstract Syntax Tree (AST) parsing for Python, or structured token scanning for JavaScript, TypeScript, and Java.
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 ( | Actively exploited in cyberattacks or ransomware campaigns in the wild. |
URGENT | Reachable in production ( | High probability of imminent exploit on an active code path. |
HIGH | Production dependency ( | 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)
Results from vulnerability checks and reachability analyses are aggregated.
VulnPilot renders a self-contained HTML report featuring executive statistics, interactive tables, color-coded badges, and remediation recommendations.
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 |
|
| Required | Package coordinate (e.g. |
|
| Required | Exact version string (e.g. |
|
|
| Ecosystem choice: |
|
|
| Optional signal indicating if vulnerable code path is imported in project |
|
|
| Usage scope: |
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 usingastparse-trees. Inspectspyproject.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). Inspectspackage.jsonand 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 |
|
| Required | Absolute path to the root directory of the project being audited |
|
| Required | Package name (use |
|
| Auto-derived | Custom import module overrides (e.g. |
generate_report
Compiles scan results into a self-contained, interactive HTML security dashboard.
Arguments
Argument | Type | Default | Description |
|
| Required | Aggregated list of package report objects from |
|
|
| Display title for report header |
|
|
| Primary ecosystem ( |
|
|
| 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 |
| Supported Ecosystems |
| Schema definitions, supported package formats, and example coordinates. |
| Triage Priority Rules |
| Formal rules explaining priority assignment logic ( |
| Dependency Evidence Guide |
| 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.jsonIf the virtual environment is not activated:
mkdir -p .vulnpilot
.venv/bin/python -m pip inspect --local > .vulnpilot/pip-inspect.jsonNo 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.txtExport the runtime dependency tree:
mkdir -p .vulnpilot
./gradlew dependencies --configuration runtimeClasspath > .vulnpilot/gradle-dependencies.txtFor test dependencies:
mkdir -p .vulnpilot
./gradlew dependencies --configuration testRuntimeClasspath > .vulnpilot/gradle-test-dependencies.txtGit Configuration Tip: Add
.vulnpilot/to your project's.gitignorefile to avoid committing local scan reports and evidence dumps.
Development & Testing
Installation for Contributors
# Install all development tools and dependencies
uv sync --all-groupsRunning Test Suites
# Execute pytest suite
uv run pytestTesting with MCP Inspector
Test tools interactively in your browser using the MCP Inspector GUI:
uv run mcp dev src/vulnpilot/server.pyProject 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.mdEnhancements
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 ( |
Data Validation | |
HTTP Client | |
Vulnerability Data | |
Exploit Telemetry | |
Build Backend | |
Package Manager | |
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 toolsanalyze_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).
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | No | PyPI | |
| import_names | No | ||
| package_name | Yes | ||
| project_path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| used_in | No | |
| ecosystem | Yes | |
| test_only | Yes | |
| limitations | No | |
| usage_found | Yes | |
| build_system | No | |
| import_names | Yes | |
| package_name | Yes | |
| reachability | Yes | |
| dependency_type | No | |
| internet_facing | No | |
| dependency_evidence | No | |
| vulnerable_api_used | No | |
| production_usage_found | Yes |
TDQS
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.
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.
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.
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.
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.
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_packageARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes | ||
| ecosystem | No | PyPI | |
| is_reachable | No | ||
| package_name | Yes | ||
| dependency_scope | No | unknown |
Output Schema
| Name | Required | Description |
|---|---|---|
| version | Yes | |
| ecosystem | Yes | |
| vulnerable | Yes | |
| package_name | Yes | |
| vulnerabilities | No | |
| enrichment_warnings | No | |
| vulnerability_count | Yes |
TDQS
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.
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.
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.
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.
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.
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_reportAIdempotent
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.
| Name | Required | Description | Default |
|---|---|---|---|
| results | Yes | ||
| ecosystem | No | PyPI | |
| output_dir | No | .vulnpilot | |
| project_name | No | Project |
Output Schema
| Name | Required | Description |
|---|---|---|
| high_count | No | |
| report_html | Yes | |
| report_path | Yes | |
| normal_count | No | |
| urgent_count | No | |
| total_packages | Yes | |
| immediate_count | No | |
| vulnerable_packages | Yes | |
| total_vulnerabilities | Yes |
TDQS
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.
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.
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.
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.
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.
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.
3 tool updates
v0.1.0- First observed
analyze_reachability - First observed
check_package - First observed
generate_report
TDQS
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.
All tool names follow the verb_noun pattern in snake_case (check_package, analyze_reachability, generate_report), ensuring predictability and clarity.
Three tools cover the essential workflow of vulnerability checking, reachability analysis, and report generation. The count is well-scoped for a security scanning server.
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
Related MCP Connectors
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
An MCP server that gives your AI access to the source code and docs of all public github repos
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
- ArcjetOAuthcom.arcjet
An MCP server for Arcjet - the runtime security platform that ships with your AI code.
Related MCP Servers
- AlicenseAqualityAmaintenanceA Model Context Protocol (MCP) server for Socket integration, allowing AI assistants to efficiently check dependency vulnerability scores and security information.11,665132MIT
- AlicenseNot gradedqualityDmaintenanceA security-focused MCP server that enables AI assistants to search PyPI packages, scan for vulnerabilities, audit dependencies, and ensure security across Python projects.3MIT
- FlicenseNot gradedqualityDmaintenanceMCP server that scans project dependencies for security vulnerabilities (CVEs) and provides fix instructions directly in VS Code via Copilot.3-
- AlicenseNot gradedqualityBmaintenanceAn MCP server that provides AI agents with real-time package health data, vulnerability reports, and dependency graphs from PyPI and OSV.dev.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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