darknet-mcp-server: 66 dark web intelligence tools behind one MCP endpoint

The gap darknet-mcp-server is trying to close

A breach investigation today means opening HIBP in one tab, ThreatFox in another, a ransomware tracker in a third, and a Tor Browser window for leak sites. Each has its own API, auth scheme, rate limit and output shape. The README describes the result plainly: sixty-plus minutes per investigation, most of it context switching rather than analysis. The project's answer is to stop treating those sources as destinations and expose them as callable tools instead.

The intended user is not a SOC analyst clicking through a dashboard. It is someone running an MCP-capable agent (the README names Claude among its keywords) who wants to ask a question in natural language and have the agent fan out across sources. The README's worked example asks the agent to investigate "the breach exposure and threat landscape for target.com" and shows it returning HIBP breaches, ThreatFox IOCs, URLhaus hits, ransomware listings, stealer-log credentials, OTX pulses and AbuseIPDB reports in one answer. That is the pitch: correlation, not another console.

How the 66 tools are wired together

The architecture is an MCP server process, not a crawler. It speaks the Model Context Protocol over stdio, and the agent decides which of the 66 tools to call. The README describes the agent querying sources in parallel and correlating the results, which means the fan-out logic lives in the model's tool-calling loop, not in a fixed pipeline inside the server.

Two implementation details are visible in package.json. Tor access runs through the socks and socks-proxy-agent packages, so .onion fetching is a SOCKS5 proxy hop rather than a bundled Tor client; the server expects a proxy to exist. HTML parsing uses cheerio, which tells you the .onion tools scrape pages rather than consume an API, and scraping is the part of this design most likely to break when a hidden service changes its markup. The runtime badge in the README says Bun, and the dev script is bun --watch run src/index.ts, while the published artifact is compiled with tsc into dist/ and exposed as a bin entry. So you can run it from source under Bun or install the built package.

Sixteen upstream sources sit behind those tools. The README names HIBP, ThreatFox, URLhaus, MalwareBazaar, Hybrid Analysis, AbuseIPDB, GreyNoise, OTX, IntelligenceX, ransomware.live, ransomlook.io, blockchain.info, ChainAbuse, Vulners, PhishTank and stealer-log data. The server is a unification layer over other people's data, and that framing matters for how you evaluate reliability.

Installing it and running a first investigation

The package is published on npm as darknet-mcp-server and the README points at that page for the current version. Because it is an MCP server, installation and registration are two steps: get the binary, then tell your MCP client how to launch it.

If you want the published build, the package exposes a bin entry named darknet-mcp-server, so an install followed by an MCP client entry pointing at that command is the shortest path. The README's Quick Start section is the authoritative place to confirm the exact invocation for your client.

npm install -g darknet-mcp-server
darknet-mcp-server

Running it with no MCP client attached will start the server and wait; it is not a CLI that prints a report. If you would rather run from source, the repository's dev script uses Bun and watches src/index.ts for changes. The build script compiles TypeScript into dist/ using tsconfig.build.json, and only dist/ is included in the published files list.

bun install
bun run dev

Once the server is registered, the first useful test is a single-source lookup rather than a broad investigation. Ask the agent for one thing you can verify independently, such as a breach check for a domain, and confirm the answer cites a specific source. The README's example investigation is the model for what a multi-source answer should look like: named sources, per-source findings, and a conclusion that separates confirmed exposure from suspicion. If your first answer arrives without source attribution, the tool call probably failed and the model filled the gap from memory.

Where this design will let you down

The hardest limitation is structural, not a bug. Every answer is only as good as sixteen third-party sources, and several of them require paid or registered API keys. The README does not document which of the 66 tools work without credentials, what happens when a key is missing, or whether a failed source is reported to the agent or silently returns nothing. In an intelligence workflow, a silent empty result is worse than an error: it reads as "no exposure found."

Scraping .onion services is the second weak point. Cheerio parsing assumes stable HTML, and hidden services are not known for stability. A leak site that changes layout, adds a CAPTCHA or goes offline takes its tool with it, and nothing in the README describes retry, caching or fallback behaviour. Expect to treat .onion results as best-effort.

The third limitation is scope. This is not a scanner and not a feed. It does not monitor anything continuously; it answers when an agent asks. If you need alerting when a new ransomware victim appears, a scheduled job that re-queries the server is your problem to build. Nothing in the repository layout suggests a daemon mode or a scheduler.

Finally, the version number is honest. v0.1.0 shipped on 2026-06-23 and v0.1.1 the same day. That is a young codebase with a wide surface, and the README documents capability far more thoroughly than it documents failure modes.

darknet-mcp-server versus using MCP servers per source

The obvious alternative is not a competing product but a different composition: run one MCP server per data source and let the agent pick between them. That approach gives you smaller, more auditable units. A HIBP-only server is easy to review, easy to pin to a version, and its failure modes are narrow. If it breaks, you know exactly what stopped working.

The trade-off is the agent's context. Sixty-six tools in one server is already a large tool surface for a model to reason over; spreading them across sixteen servers multiplies the registration overhead and makes cross-source correlation the model's problem in a messier way. darknet-mcp-server's argument is that a single server with consistent tool naming and shared conventions produces better correlation than a pile of independent servers. That is a real design position, and it is the reason to choose this project over assembling your own.

The cost is blast radius. One dependency tree, one build, one set of credentials in one process. If you are evaluating this for a regulated environment, the per-source approach gives you a cleaner story about what data reached which system.

Maintenance, licensing and what v0.1.x implies

The last push to the repository was on 2026-09-08, and the repository is not archived. The most recent release, v0.1.1, dates from 2026-06-23, so code has moved since the last tagged release; if you need release-grade stability, pin to the npm version rather than tracking main.

The licence is MIT, stated in package.json and in the LICENSE file at the repository root. MIT permits commercial use and modification with attribution and no warranty. That last clause matters more than usual here: you are aggregating breach data, stealer logs and blockchain intelligence, and the upstream sources have their own terms. HIBP, IntelligenceX and Hybrid Analysis all have their own access rules, and the MIT licence on this server says nothing about whether your use of the data behind it is permitted. That is a question for your own counsel, not for the repository.

Upgrade cost is currently low in the sense that there is little to break: two releases, both from the same day. It is high in the sense that a 0.x project with 66 tools can change tool names or output shapes between minor versions. There is a CHANGELOG.md at the root, which is where to look before bumping.

Editorial conclusion

Adopt it if you already run an MCP-capable agent and want breach, ransomware and IOC lookups reachable from the same conversation, and you are willing to read src/ because the README does not document rollback, key rotation or failure behaviour. Do not adopt it as your only intelligence path: the README states the agent queries upstream sources, so every answer inherits their coverage gaps and rate limits. Before wiring it into anything that touches production credentials, verify which of the 66 tools need API keys, what the SOCKS5 proxy defaults are, and whether your MCP client surfaces tool errors or silently returns empty results.

Frequently asked questions

Official sources

1. badchars/darknet-mcp-server on GitHub
2. License: MIT
3. Project website
4. README
5. Releases