FuzzingLabs/mcp-security-hub: 38 Dockerized MCP Servers for Offensive Security Tools

The gap mcp-security-hub fills between an AI assistant and a pentest toolbox

An AI assistant can write an Nmap command line. It cannot run one unless something exposes the tool over a protocol the assistant speaks. Model Context Protocol is that protocol, and mcp-security-hub is a collection of servers that implement it on top of offensive security tools. The README describes the project as "Production-ready, Dockerized MCP ... servers for offensive security tools" and states the goal plainly: "Enable AI assistants like Claude to perform security assessments, vulnerability scanning, and binary analysis." The audience is therefore narrow and specific. It is a security engineer or red teamer who already knows how to use Nmap, Nuclei or radare2 and wants to drive them conversationally, plus developers who need a scanning or secrets-detection step inside an assistant workflow. It is not aimed at people learning what a port scan is. The repository counts 38 servers and claims 300+ tools across reconnaissance, web security, binary analysis, blockchain, cloud, secrets detection, exploitation, fuzzing and OSINT. Roughly half of those directories are original wrappers with a documented tool count (nmap-mcp lists 8 tools, ffuf-mcp 9, radare2-mcp 32, sqlmap-mcp 8, trivy-mcp 7). The rest are wrappers around other people's MCP servers, such as the official Shodan MCP, the official Burp Suite MCP, pyghidra-mcp and ida-pro-mcp. That split matters more than the headline server count, and it is the first thing to check before assuming a given capability ships from this repo.

One container per tool: the architecture the README actually shows

There is no central broker or gateway in the material. The architecture is one MCP server per tool, each built as its own Docker image, each registered separately in the client configuration. The Quick Start builds everything with docker-compose build and then starts named services individually, for example docker-compose up nmap-mcp nuclei-mcp -d, followed by docker-compose ps to check health. In the Claude Desktop example, each server appears as its own key under mcpServers and is launched as a separate docker run invocation with the -i flag for stdio transport and --rm to discard the container on exit. Capabilities are granted per container rather than globally: nmap-mcp is started with --cap-add=NET_RAW because raw socket access is what Nmap needs, and the other entries in the same JSON block do not get it. Filesystem access follows the same pattern. gitleaks-mcp mounts a repository read-only with -v /path/to/repos:/app/target:ro, and radare2-mcp mounts binaries read-only at /samples. The data flow is therefore direct and unsurprising: the assistant sends a tool call over stdio, the container runs the underlying binary against the mounted path or the specified target, and the result returns as the tool response. Nothing in the README suggests the hub inspects, filters or rewrites those results. That is worth stating because it defines what the project is responsible for and what it is not.

Setup: build first, then register each server in claude_desktop_config.json

The README is explicit that the images must exist before the client config will work: "You must build the images first with docker-compose build before using them." The sequence is clone, cd mcp-security-hub, docker-compose build, then docker-compose up <server> -d for the servers you want running. Client registration happens in claude_desktop_config.json, at ~/Library/Application Support/Claude/ on macOS or %APPDATA%\Claude\ on Windows. A minimal entry looks like this: the server name as the key, "command": "docker", and args of ["run", "-i", "--rm", "nmap-mcp:latest"]. Adding NET_RAW goes in the same args array. For mounted tools, the volume flag is appended in the same place. The README also points at a .mcp.json file to copy into a project root for project-level configuration, and at an examples/ directory said to contain full templates with all MCPs and volume mount patterns. Two practical notes follow from this. First, the mount paths in the sample config are placeholders (/path/to/repos, /path/to/binaries) and must be replaced with real host paths before anything works. Second, because each server is a separate docker run, the client starts a fresh container per session rather than connecting to the long-running compose services; the compose step exists mainly to produce the images. Whether that distinction causes confusion in practice is not something the README addresses.

Where the collection is thin: wrapper servers, missing tool counts, and no pinned releases

Several entries in the server tables have a dash in the Tools column and a description that begins with "Wrapper for". shodan-mcp, nikto-mcp, zoomeye-mcp, burp-mcp, ghidra-mcp and ida-mcp all point at external repositories. For those, the value this repo adds is packaging and a consistent Docker interface, not the MCP implementation itself, and the underlying project's own maintenance schedule governs whether the integration keeps working. The README does not state a version pinning policy for those upstream dependencies, which is a real risk if an upstream MCP changes its tool schema. A second limitation is release hygiene. The repository metadata shows no recent releases, so there is no tag to pin a deployment against; the practical unit of versioning is the master branch and whatever image tag your local build produced. A third is the Docker requirement itself. Every server is a container, so an environment without Docker, or one where the analyst cannot add NET_RAW capabilities, cannot use nmap-mcp or masscan-mcp at all. There is no documented non-container path. Finally, the README does not discuss rate limits, scan authorization, or how an assistant's tool calls are logged. For a collection whose whole purpose is running intrusive tools, the absence of any guidance on scoping and audit is a gap worth naming rather than glossing over.

The alternative: calling the tools directly, or using a single upstream MCP server

The obvious alternative for most of this collection is not a competing hub. It is running the tool yourself. Nmap, Nuclei, ffuf, SQLMap, gitleaks and radare2 all have their own command-line interfaces, and a scripted pipeline around them gives you deterministic, reviewable, version-pinned behaviour without a model in the loop. The difference in approach is the interface: the hub trades a shell command for a natural language tool call, which helps when you want the assistant to chain reconnaissance steps or interpret output, and hurts when you want reproducibility, because the exact arguments are chosen by the model rather than written down in a file. A second alternative is adopting the upstream MCP servers directly, the ones this repo wraps. If you need Burp Suite or IDA Pro integration, PortSwigger and mrexodia publish their own MCP servers, and going straight to them removes one layer from the dependency chain and lets you follow their release notes rather than this repo's. The hub's advantage over that route is consistency: one docker-compose build, one config file format, one place to look for volume mount patterns across 38 tools. If you only need two or three of them, that advantage largely disappears.

Maintenance cost and what the MIT licence does and does not cover

The project is MIT licensed, which is permissive and imposes few obligations on how you redistribute or modify the code. That covers the wrapper code in this repository. It does not cover the tools inside the images. Nmap, Nuclei, SQLMap, Ghidra, IDA Pro, Burp Suite and others carry their own licences, and several of those are not permissive: IDA Pro and Burp Suite are commercial products, and Ghidra ships under Apache 2.0 with its own terms. The README does not enumerate per-tool licence terms, so anyone packaging these images into a product or a shared internal platform should check each tool's licence separately. That is a factual gap in the documentation, not legal advice. On maintenance, the cost profile is uneven. Servers with a documented tool count are maintained here, so upgrades arrive as commits to this repository. Wrapper servers depend on upstream projects, which means two upgrade paths to track and a potential schema mismatch when one side moves. The GitHub Actions workflows referenced in the badges (build.yml and security-scan.yml) indicate automated builds and Trivy scanning, and the README claims non-root containers and minimal images, so there is some supply-chain hygiene built in. What is not documented is how often images are rebuilt, whether base images are pinned, or how a breaking change in an upstream MCP would be surfaced to users.

Who should adopt it, and what to confirm before the first scan

Adopt this if Docker is already part of how your team works, if you use Claude Desktop or Claude Code with project-level .mcp.json configuration, and if the value you want is the ability to say "scan this host" or "check this repository for secrets" and have the assistant pick up the right tool. The secrets detection and binary analysis groups are the most self-contained: gitleaks-mcp with a read-only volume mount is a low-risk first integration, and radare2-mcp, binwalk-mcp, yara-mcp and capa-mcp operate on files you supply rather than on live network targets. Skip it if you need a pinned release, if your environment forbids Docker or NET_RAW, or if you only want one or two of the 38 servers, in which case the upstream project is a shorter dependency chain. Before the first scan, confirm three things in the repository: that the specific MCP directory has its own README and Dockerfile rather than pointing outward, that the image name in your claude_desktop_config.json matches what docker-compose build actually produced, and that your volume mounts point at real host paths rather than the /path/to/... placeholders in the example. Start with gitleaks-mcp against a local repository and check the tool output before pointing anything at a network target.

Editorial conclusion

Adopt mcp-security-hub if you already run Docker and want Claude or another MCP client to drive Nmap, Nuclei, ffuf or the binary analysis tools through a single claude_desktop_config.json entry per server. Do not adopt it if you cannot run Docker on the analyst workstation, if you need a stable tagged release to pin against (the material shows no recent releases), or if you expect the wrappers to add capability beyond what the upstream tools already do. Before committing, verify three things against the repository itself: that each MCP directory you care about carries its own README and Dockerfile, that the wrapper servers listed as external actually pull an image built from this repo rather than an upstream one, and that the volume mount paths in the examples match where your binaries and repositories actually live, because the sample config hardcodes /path/to/repos and /path/to/binaries.

Official sources

1. FuzzingLabs/mcp-security-hub on GitHub
2. Issues
3. License: MIT
4. Project website
5. README