How do I use Voraxx MCP Server?

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., "@Voraxx MCP Server Look up CVE-2024-3094" 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.

Voraxx MCP Server

by bharat3645

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Voraxx MCP Server

A minimal, dependency-free Model Context Protocol (MCP) server that gives AI agents three real, read-only security-orchestration tools:

Tool	What it does	Requires a key?
`cve_lookup`	Look up a CVE by ID against OSV.dev's vulnerability database (summary, CVSS, affected packages, references)	No
`shodan_host_lookup`	Recon an IP (open ports, hostnames, CPEs, known CVEs) via Shodan's free InternetDB endpoint, or the full Shodan Host API if you set `SHODAN_API_KEY`	No (optional for the full API)
`nuclei_scan`	Run a scan against a target using your own locally-installed nuclei binary, and summarize the JSONL findings	No (nuclei itself is separate, free, open-source)

Why this exists

By mid-2026, wrapping recon/vuln-intel tools (Nuclei, Shodan, Nmap, CVE databases) behind MCP servers so LLM agents can call them directly — instead of shelling out ad hoc — has become a standard pattern in AI-assisted security tooling. This is a small, honest implementation of that pattern: a companion, standalone utility to the Voraxx AI pentesting agent, usable on its own with any MCP-compatible client (Claude Desktop, Claude Code, etc.).

It is deliberately minimal. It does not bundle exploit code, attack payloads, or scan templates of its own — every tool either queries a public, read-only data source, or shells out to a well-known external scanner (nuclei) that you install and control yourself.

Related MCP server: cve-mcp

Install

No third-party dependencies are required to run the server — it's pure Python 3.9+ standard library.

git clone https://github.com/bharat3645/voraxx-mcp-server.git
cd voraxx-mcp-server
python3 -m voraxx_mcp   # starts the MCP server on stdio

If you'd rather install it as a package (adds the voraxx-mcp-server console script):

pip install -e .
voraxx-mcp-server

Use it from an MCP client

Point your MCP client's config at this server over stdio. Example (Claude Desktop / Claude Code style config, see examples/mcp_client_config.json):

{
  "mcpServers": {
    "voraxx-security": {
      "command": "python3",
      "args": ["-m", "voraxx_mcp"],
      "cwd": "/absolute/path/to/voraxx-mcp-server",
      "env": { "SHODAN_API_KEY": "" }
    }
  }
}

Once connected, the client will see three tools — cve_lookup, shodan_host_lookup, nuclei_scan — with full JSON Schema for their arguments (tools/list), and can invoke them (tools/call) like any other MCP tool.

Environment variables

Variable	Purpose	Default
`SHODAN_API_KEY`	If set, `shodan_host_lookup` uses the full Shodan Host API instead of the free InternetDB endpoint	unset (uses free InternetDB)
`VORAXX_MCP_HTTP_TIMEOUT`	Timeout (seconds) for outbound HTTP lookups	`10`
`VORAXX_MCP_OSV_BASE_URL`	Override the OSV.dev base URL (mainly for testing)	`https://api.osv.dev`
`VORAXX_MCP_SHODAN_INTERNETDB_URL`	Override the InternetDB base URL (mainly for testing)	`https://internetdb.shodan.io`
`VORAXX_MCP_SHODAN_API_URL`	Override the Shodan Host API base URL (mainly for testing)	`https://api.shodan.io`

Safety

Only scan or query targets and hosts you own or are explicitly authorized to test. nuclei_scan runs a real scanner against a real target you provide — this project supplies no default target and no bundled templates.
nuclei_scan shells out to your local nuclei binary using an argument list (never a shell string), so there's no shell-injection surface from the target value.
Nothing here writes findings anywhere but back to the calling MCP client — no telemetry, no external reporting, no persistence.
If nuclei isn't installed, the tool says so plainly and explains how to install it, rather than failing silently or fabricating output.

Architecture

voraxx_mcp/server.py implements the minimal JSON-RPC 2.0 / stdio subset of MCP (initialize, notifications/initialized, ping, tools/list, tools/call) in about 180 lines of dependency-free Python — no mcp SDK install required. voraxx_mcp/tools.py holds the three tool implementations, and voraxx_mcp/app.py wires them together with their JSON Schemas.

This is intentionally a small, auditable core rather than a dependency on a larger SDK, so the whole request/response lifecycle is easy to read end to end in one sitting.

Testing

Two test suites, both stdlib-only (no pytest required, though it works fine too):

python3 -m unittest discover -s tests -v

tests/test_protocol.py — spawns the server as a real subprocess and speaks actual newline-delimited JSON-RPC to it over stdin/stdout (the same transport a real MCP client uses), covering the full initialize → tools/list → tools/call lifecycle, error handling, and malformed input.
tests/test_tools_offline.py — exercises the tool logic against a local stub HTTP server seeded with real response fixtures captured from OSV.dev and Shodan InternetDB, plus a fake nuclei binary on PATH for the scan-parsing path — so the full request → parse → format flow is verified without needing live internet access or an installed scanner.

All 19 tests pass in this repo's CI-free, offline sandbox verification; see commit history for the verification run.

Limitations (honest, as of v0.1.0)

No caching, rate-limiting, or retry/backoff on outbound HTTP calls yet.
nuclei_scan summarizes JSONL output; it doesn't expose every nuclei CLI flag.
No authentication/multi-tenancy layer — this is a single-user, local stdio server, as most MCP servers are.
Only three tools. More (e.g. Subfinder, httpx, an authenticated NVD lookup) could be added following the same pattern in voraxx_mcp/tools.py.

License

MIT — see LICENSE.

Available Tools

3 tools

cve_lookupA

Look up a CVE by ID (e.g. CVE-2021-44228) against the free, keyless OSV.dev vulnerability database. Returns summary, CVSS, affected packages, and references. Read-only; no API key required.

ParametersJSON Schema

Name	Required	Description	Default
`cve_id`	Yes	CVE identifier, e.g. 'CVE-2021-44228'

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so description carries full burden; it discloses read-only nature, no API key needed, and outlines return content (summary, CVSS, affected packages, references).

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?

Description is concise and front-loaded with key information, though the behavioral notes could be separated for even clearer structure.

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?

For a tool with one parameter and no output schema, the description fully covers purpose, return content, and behavioral traits, making it complete for an agent to understand and invoke correctly.

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 100%, and parameter description is clear; the description reiterates the same example but adds context about the database, providing marginal value beyond schema.

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?

Description clearly states it looks up a CVE by ID against the OSV.dev database, distinguishing it from sibling tools nuclei_scan and shodan_host_lookup which serve different purposes.

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?

Description implies usage context (read-only, no API key required) but does not explicitly state when not to use or contrast with potential alternatives.

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

nuclei_scanA

Run a scan against a target using nuclei (ProjectDiscovery), if nuclei is installed locally on this machine. Orchestrates your own nuclei binary and templates only -- this tool does not bundle or download any scan templates itself. Only scan systems you are authorized to test.

ParametersJSON Schema

Name	Required	Description
`target`	Yes	URL or host to scan, e.g. 'https://example.com'
`timeout`	No	Subprocess timeout in seconds (default 300)
`templates`	No	Optional nuclei -tags filter, e.g. 'cves' or 'exposed-panels'
`rate_limit`	No	Max requests/second passed to nuclei -rate-limit (default 10)

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, description carries full burden. It discloses that it uses local binary and templates and should only target authorized systems. Missing details on output format, error handling, and performance implications.

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?

Three concise sentences: purpose, constraint, ethical note. Front-loaded with key action and no extraneous text.

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

Completeness2/5

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

Lacks description of return values (no output schema) and side effects. For a subprocess-based tool, the agent would benefit from knowing output format and potential failure modes.

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?

Input schema covers all parameters with descriptions. The description adds no extra meaning beyond the schema, meeting the baseline for 100% schema coverage.

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 runs a scan with nuclei, specifying the target and the tool. It distinguishes from sibling lookup tools (cve_lookup, shodan_host_lookup) by indicating this performs scanning, not lookups.

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?

Provides clear context: requires local nuclei installation, uses existing templates, and ethical authorization. Does not explicitly state when not to use (e.g., missing nuclei), but the condition is implied by 'if installed'.

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

shodan_host_lookupA

Look up recon data (open ports, hostnames, CPEs, known CVEs) for an IP address. Uses Shodan's free InternetDB endpoint by default (no API key needed); if the SHODAN_API_KEY environment variable is set, uses the full Shodan Host API instead. Read-only -- reflects Shodan's last scan, not a live probe.

ParametersJSON Schema

Name	Required	Description	Default
`ip`	Yes	IPv4 or IPv6 address, e.g. '1.1.1.1'

TDQS

A4.4/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 read-only nature, dependency on environment variable, and that data is from Shodan's last scan. However, it omits details like error handling or rate limits, which would further enhance 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?

Two sentences convey purpose, behavior, and API modes with no redundancy. The most critical information is front-loaded, making it efficient for an agent to parse.

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 tool with one parameter and no output schema, the description covers purpose, data types, and behavior modes. It lacks details on return format or empty-case handling, but given the low complexity, it is sufficiently complete.

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?

Schema coverage is 100% for the ip parameter, which already describes IPv4/IPv6. The description adds an example ('1.1.1.1') and clarifies format, providing marginal extra value beyond the schema.

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 verb ('look up'), resource ('IP address'), and the specific data types ('open ports, hostnames, CPEs, known CVEs'). It distinguishes from sibling tools (cve_lookup, nuclei_scan) by specifying the Shodan source and that it's not a live probe.

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 provides clear context: default behavior (InternetDB, no API key) vs. full API when SHODAN_API_KEY is set, and that it's read-only reflecting last scan. It indirectly guides usage for recon vs. live scanning, though lacks explicit comparisons to siblings.

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 updatesv0.1.0Jul 10, 2026
- First observedcve_lookup
- First observednuclei_scan
- First observedshodan_host_lookup

Install Server

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

TDQS

A4.2/5.0

Scored 2026-07-10 06:40 across 3 tools

Disambiguation5/5

Each tool targets a distinct operation: CVE lookup for vulnerability details, nuclei for active scanning, and Shodan for passive reconnaissance. No overlap in purpose.

Naming Consistency5/5

All tool names follow the pattern '{source}_{action}' with consistent lowercase and underscores. Verbs 'lookup' and 'scan' are appropriate and distinguishable.

Tool Count5/5

Three tools is a focused, well-scoped set for a security reconnaissance server. Each tool provides essential functionality without bloat.

Completeness4/5

The set covers vulnerability lookup, active scanning, and passive recon, covering key security workflows. A minor gap might be a tool for detailed port scanning, but the current set is sufficient for most common tasks.

Maintenance

ActivityMaintained

ResponsivenessNo issues

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

MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
mcp-server
com.pentest-tools
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Penetration Testing Security
23
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2

Related MCP Servers

wrg-mcp-server
Security Penetration Testing Code Analysis
WRG-11
A
license
Not graded
quality
A
maintenance
An MCP server that exposes a 60+ tool security and threat-intel stack to AI agents, enabling secret scanning, Sigma rule generation, ransomware lookup, OSINT, and deep research.
Updated 3 months ago (2026-06-10 18:22 UTC)
1
MIT
cve-mcp
Security Research & Data
badchars
A
license
A
quality
B
maintenance
Unifies NVD, EPSS, CISA KEV, GitHub Advisory, and OSV into a single MCP server, enabling AI agents to query vulnerability intelligence conversationally with 23 tools for incident response, prioritization, dependency audits, and threat monitoring.
Updated 6 days ago (2026-09-03 01:24 UTC)
41
351
24
MIT
cyber-mcp-server
Penetration Testing Security
warnii
F
license
Not graded
quality
C
maintenance
A production-style MCP server providing AI models with cybersecurity tools including port scanning, WHOIS, DNS, threat intelligence, CVE lookup, and more.
Updated a month ago (2026-07-28 21:37 UTC)
-
recon-mcp
Penetration Testing Networking & Infrastructure
nan786521
A
license
Not graded
quality
B
maintenance
MCP server providing safe, structured network and security reconnaissance tools for AI agents, with graded JSON results.
Updated 3 months ago (2026-06-22 08:11 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/bharat3645/voraxx-mcp-server'

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