Raven Nest MCP

A pentesting toolkit that runs as an MCP server, giving AI assistants structured access to industry-standard security tools through a safety-hardened interface.

Authorized use only. Raven Nest is an offensive-security tool intended solely for testing systems you own or have explicit written permission to assess. Unauthorized scanning, enumeration, or exploitation may be illegal. You are solely responsible for obtaining authorization and complying with all applicable laws. The software is provided "as is", without warranty of any kind - see LICENSE.

Demo

Real MCP traffic to the tools - no LLM in the loop, fully deterministic. Targets are the authorized public test hosts example.com / scanme.nmap.org.

Scan → structured finding → report

Recon flow - connectivity, ports, web stack

Metasploit module discovery - requires an MSF-enabled build; the default container image excludes Metasploit

What It Does

Raven Nest wraps 22 security tools plus Metasploit Framework behind an MCP interface with input validation, output quality assessment, session-aware context budgeting, and configurable safety limits. It handles tool execution, restart-safe background scans (completed results survive a server restart; interrupted ones surface as failed), vulnerability finding persistence, target discovery tracking, scan diffing, and multi-format report generation (Markdown, JSON, SARIF, HTML). Findings, reports, and scans are also exposed as MCP resources for browsing. 46 MCP endpoints total.

Supported Tools

How It Fits Together

Raven Nest is an MCP server - it doesn't do anything on its own. An MCP host launches it over stdio and drives the tools. Pick whichever host suits you:

• Any MCP host (recommended) - point Claude Desktop, Cursor, or any MCP client at the Docker image below; the host spawns the server for you.
• Companion REPL - raven-nest-client is a TypeScript terminal client (tab-completion, scan/finding/report commands, engagement scoping) for driving Raven Nest by hand. It can launch either a local raven-server build or the Docker image.

The server is the same stdio binary in both cases.

Quick Start

Run with Docker (recommended)

The published image bundles raven-server and all 22 wrapped tools on a Kali base, so you don't have to install them yourself. Point your MCP client at it (stdio):

{
  "mcpServers": {
    "raven-nest": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "ghcr.io/tidynest/raven-nest-mcp:latest"]
    }
  }
}

masscan and nmap -O need raw sockets - append --cap-add=NET_RAW and --cap-add=NET_ADMIN to args if you use them (the container runs as a dedicated non-root user; the runtime grants those capabilities to the container process directly, so they keep working without root). The server is also listed on the MCP Registry as io.github.tidynest/raven-nest-mcp.

Prerequisites

• Rust 1.93+ (2024 edition)
• One or more external tools installed (nmap, nuclei, nikto, etc.)

Build

cargo build --release

Configure your MCP client

Create .mcp.json in your project root (or configure your MCP client directly):

{
  "mcpServers": {
    "raven-nest": {
      "command": "/path/to/raven-server",
      "args": []
    }
  }
}

The server communicates over stdio and requires no network ports.

Configuration

Raven Nest loads configuration from TOML, resolved in order:

1. RAVEN_CONFIG environment variable (path to file)
2. config/default.toml next to the binary
3. config/default.toml in the working directory
4. Built-in defaults

Key configuration sections:

[safety]
allowed_tools = ["nmap", "nuclei", "nikto", "whatweb", "masscan", ". . ."] 
context_budget = 65536          # Model context window in chars (0 = disabled)
expected_tool_calls = 10        # Anticipated calls per session
sudo_tools = ["masscan", "nmap"] # Tools invoked via passwordless sudo
# auto_save_findings = false     # opt-in: auto-extract findings from scanners

[execution]
default_timeout_secs = 600
max_concurrent_scans = 3
output_dir = "/tmp/raven-nest"

# [scope]                        # engagement authorization allowlist (deny-wins)
# enabled = true
# allowed_domains = ["example.com"]

# [network]
# http_proxy = "http://127.0.0.1:8080"

# [metasploit]
# enabled = true
# host = "127.0.0.1"
# port = 55553
# password = "changeme"

# [netexec]                      # gated, read-only credentialed enumeration
# enabled = true

See docs/USAGE.md for the full parameter reference and per-tool configuration options.

Safety Architecture

Every tool call passes through six layers:

1. Allowlist -- only explicitly permitted tools can execute
2. Input validation -- targets must be valid IPs, hostnames, CIDRs, or URLs; shell metacharacters are rejected
3. Preset arguments -- users pick scan types, never raw CLI flags
4. Execution containment -- configurable timeouts with kill_on_drop
5. Output sanitisation -- ANSI stripping, truncation at configurable limits (UTF-8 safe)
6. Quality assessment -- detects empty results, rate-limiting, and WAF blocks

Additional hardening:

• Config validation at startup -- safety limits (sqlmap level/risk, hydra tasks, masscan rate) are range-checked; the server refuses to start with out-of-range values or default MSF credentials
• Wordlist path validation -- hydra, john, feroxbuster, and ffuf only accept wordlists under /usr/share/, /usr/lib/, or the configured output_dir; path traversal (..) is rejected
• Positional-argument guards -- free-text values passed to tools as positional arguments are charset-checked so they can't be re-parsed as flags: hydra service (lowercase/digits/hyphens) and form_params (no leading -, no control chars), sqlmap technique (subset of BEUSTQ), ffuf filter_size (digits/commas). Targets get the same treatment (-oN/tmp/evil is rejected as flag-like)
• Port spec validation -- nmap and masscan port parameters accept only digits, commas, and hyphens
• File permissions -- cookie files and scan spill files are created with 0o600 (owner-only)
• Markdown escaping -- report generation escapes user-supplied finding fields to prevent markdown injection
• Finding ID validation -- finding get/delete operations require valid UUID format, preventing path traversal
• Engagement scope -- an optional authorization allowlist ([scope]): when enabled, every target must match an allowed CIDR/domain and must not match a denied one (deny wins); loopback is allowed unless disabled. http_request re-validates each redirect hop against the scope, so a redirect cannot escape it. Off by default
• Audit logging -- every tool execution is appended to {output_dir}/audit.log with the tool, target, and redacted arguments
• Proactive cooldown -- an optional min_exec_gap_ms spaces out consecutive tool launches so back-to-back aggressive tools don't trip a target's WAF or rate-limiter, and per_target_min_gap_ms does the same per host while independent targets proceed in parallel; complements the reactive WAF/rate-limit detection. Both off by default

Metasploit integration adds a 5-layer safety model: disabled by default, per-tool allowlisting, path-boundary module blocklist, exploit confirmation gate (double-call to execute), and session command filtering. Passwords are redacted from error messages, and TLS certificate bypass is restricted to localhost connections. See docs/METASPLOIT.md.

Tools requiring root (masscan, nmap OS detection) can be run via passwordless sudo without elevating the entire server. See sudo_tools in the configuration docs.

Context Budget