Bolt

Bolt is a containerized MCP server that provides security tools. It runs in a Docker container (Ubuntu 24.04) and exposes each tool directly — no meta-tools, no dynamic loading, just call the tool you need.

Why Bolt?

Bolt solves the problem of running security tools that need a Linux environment. Instead of installing tools locally, Bolt runs them in an isolated container.

What’s Inside

Bolt (bolt.config.json, port 3001) exposes tools two ways:

• 7 native plugins — subfinder, nmap, nuclei, httpx, ffuf, run-command, wordlist
• ~26 aggregated stdio MCP servers — e.g. dnsx, amass, katana, sqlmap, wpscan, gobuster, masscan, hydra, hashcat, john, impacket, and more

Each is a directly callable tool — the agent calls it in a single turn, no search/load step.

Quick Start

1. Start the Bolt container

docker run -d \
  --name bolt \
  --restart unless-stopped \
  -p 3001:3001 \
  -v bolt-data:/data \
  -e MCP_ADMIN_TOKEN=$(openssl rand -hex 32) \
  --cap-add NET_RAW \
  --cap-add NET_ADMIN \
  ghcr.io/cyberstrikeus/bolt:latest

# View the admin token (used once, to pair)
docker logs bolt | grep -i token

2. Pair it with Cyberstrike

Open the /bolt dialog in the TUI, press a to add, enter the URL http://localhost:3001, and provide the admin token. Cyberstrike pairs with the server (see Authentication) and stores the credentials — the token itself is not written to your config.

3. Use the tools

> Run nmap against 192.168.1.1 with service detection
> Use subfinder to enumerate subdomains of example.com

Configuration

Bolt servers are configured under their own top-level bolt key — not under mcp. Each entry only needs a url (Cyberstrike appends the /mcp path itself):

{
  "bolt": {
    "local": {
      "url": "http://localhost:3001",
      "enabled": true,
      "timeout": 30000
    }
  }
}

Authentication

Bolt uses Ed25519 request signing, bootstrapped by a one-time pairing with the admin token:

1. POST /pair with the admin token → a pairing code
2. Cyberstrike generates an Ed25519 keypair
3. POST /pair/exchange with the code + client public key → server public key + client ID
4. From then on, every request is signed with the client’s private key

The admin token is used only during step 1 — it is not a persistent bearer credential and is never stored in cyberstrike.json.

TUI Management

Two separate dialogs:

• /bolt — manages Bolt servers (add/pair, toggle, remove).
• /mcps — manages regular local/remote MCP servers.

In the /bolt dialog: a to add, space to toggle a server, esc to close.

Usage Examples

> Use bolt to scan 192.168.1.0/24 for open ports and services   # nmap
> Find all subdomains of example.com                            # subfinder
> Scan https://target.com with nuclei                           # nuclei
> Fuzz directories on https://target.com                        # ffuf
> Run "dig +short example.com"                                  # run-command escape hatch

Each maps to a direct tool call — no loading step.

Container Configuration

Environment variables

Docker capabilities

API Reference

curl http://localhost:3001/health

Troubleshooting

• Connection refused — check the container is up (docker ps), the port is mapped (docker port bolt), and curl http://localhost:3001/health responds.
• Re-pairing required — if the Bolt URL changes, Cyberstrike drops the stored credentials and you must pair again via /bolt.
• Tools not available — confirm the server is connected in /bolt, and use a direct-API model (e.g. anthropic/claude-sonnet-4-20250514, openai/gpt-4o).

Related Documentation

• Bolt / MCP Overview - Architecture and concepts
• Remote Servers - Remote MCP configuration
• Local Servers - Local stdio MCP setup
• Permissions - Tool permissions