darknet-mcp-server: 66 MCP Tools That Put Breach, Ransomware and .onion Lookups Behind One Agent Interface
66-tool MCP server for dark web intelligence — breach data, ransomware tracking, Tor .onion access, malware analysis, blockchain intel, exploit search, stealer logs
At a glance
- What is it?
- A TypeScript MCP server that wraps HIBP, ThreatFox, ransomware trackers, Tor .onion fetching, blockchain lookups and stealer log search into 66 tools an AI agent can call in one conversation. It is a correlation layer, not a new intelligence source, and the README is honest about being a first release.
- Who is it for?
- Adopt darknet-mcp-server if you already run an MCP-capable agent and you want breach, IOC, ransomware and .onion lookups to land in one context window instead of sixteen browser tabs; the 2026-09-08 push and the npm v0.1.1 release mean the code is current, but it is still a 0.x line.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap darknet-mcp-server is trying to close
The README opens with a workflow diagram rather than a feature list, and that choice is the point. It walks through a conventional investigation: check breach exposure in HIBP, search leaked credentials in IntelligenceX, track ransomware groups across ransomware.live and ransomlook.io, open .onion services in Tor Browser, analyze samples in Hybrid Analysis and MalwareBazaar, check IP reputation in AbuseIPDB and GreyNoise, trace cryptocurrency, search Vulners for exploits, check PhishTank, then copy everything into a report. The README puts that at 60+ minutes per investigation, most of it context switching. That number is the author's estimate, not a measurement, but the shape of the problem is real: the intelligence exists, the friction is in the plumbing. The target user is not a malware reverse engineer or a threat hunter with a mature platform. It is someone running an AI agent who wants the agent to answer a question like "what is the breach exposure and threat landscape for target.com" without a human manually stitching eight APIs together. The README's example answer mixes HIBP breach counts, ThreatFox IOCs, URLhaus hits, ransomware listings, stealer log credentials, OTX pulses and AbuseIPDB reports into one paragraph. Whether the agent produces that reliably is a separate question from whether the tools exist to attempt it.
How the 66 tools are actually wired
The architecture is a fan-out, not a pipeline. According to the README, the agent calls tools over the Model Context Protocol and the server queries its 16 data sources in parallel, then hands the results back for the model to correlate. There is no local index, no enrichment database, no scoring engine described in the README. Each tool is a thin wrapper over a remote API, and the intelligence value comes from the model holding several results in one context and noticing that a hash from ThreatFox also appears in a Hybrid Analysis detonation, or that a domain in URLhaus shares an IP with an AbuseIPDB report. That design has a direct consequence: the server cannot tell you anything the upstream sources do not already know, and correlation quality depends entirely on the model's reasoning over whatever the APIs returned. The .onion tools are the exception in mechanism if not in spirit. The README states the agent fetches, scrapes and searches hidden services through a SOCKS5 proxy rather than through a browser, which means Tor routing is a runtime dependency you supply, not something the package bundles. The README does not document retry behavior, timeouts or partial-failure handling when one of the 16 sources is down, and that silence matters more in a parallel fan-out than it would in a sequential one.
Installing it and pointing an agent at it
The package is published on npm as darknet-mcp-server, and the README's Quick Start section is the entry point. The runtime badge on the repository says Bun, so the expected execution path is a Bun process rather than plain Node, and that is worth checking against your own deployment before you commit. Configuration follows the standard MCP pattern: you register the server with your agent client and supply credentials for the sources you intend to use. Because the README names HIBP and IntelligenceX as paid APIs in its own comparison table, expect at least some tools to return errors or nothing until keys are set. The .onion tooling needs a SOCKS5 proxy reachable from the host running the server; if your agent runs in a container or a managed environment, that egress path is the first thing to validate, because a blocked proxy turns a whole category of tools into dead weight rather than a partial result. The README does not document rollback, and it does not publish a per-tool table of which environment variables each of the 66 tools reads, so the practical setup step is to read the tools reference and map each source you care about to its key before starting the agent. Version pinning is straightforward: v0.1.1 is the current npm release, published 2026-06-23, and v0.1.0 was the initial release the same day.
Where the design creates real problems
The first limitation is legal and operational, not technical. The README describes searching stealer logs for compromised employee credentials, which is a defensive use, but the same tool surface reaches breach databases, leaked credential collections and hidden services. Running this against your own domain is one thing; pointing it at a third party's employees is another, and nothing in the server enforces a scope boundary. That is a policy problem the package cannot solve and does not claim to. The second is that a 66-tool server is a large surface for an agent to choose from. Tool selection is a known weak point in agent systems, and a model that picks the wrong source for a question will produce a confident answer built on irrelevant data. The README does not describe any tool-routing hints, categories or descriptions beyond the reference table. The third is reproducibility. Because every answer is assembled at query time from live APIs, the same prompt on two days can produce different results as sources update, rate limits bite or endpoints change. If you need an auditable record of what was checked and when, this server does not provide it; you would be logging the agent's transcript, not a structured query record. Finally, the README's own example output is illustrative prose, not a captured session, so treat its specificity ("47 employee credentials", "2.1M records") as a demonstration of format rather than a claim about accuracy.
What the alternative looks like in practice
The obvious alternative is OpenCTI or MISP with their own connectors and API. The difference is architectural, not just feature-level. MISP and OpenCTI are stores: you feed them IOCs, they normalize, deduplicate, tag and retain them, and you query a database that persists across investigations. darknet-mcp-server is a query broker: nothing is retained, every call goes out to the source, and the value is the agent's ability to fan out and summarize in one turn. If your problem is "I want an agent to answer a question right now without opening eight tabs", the broker wins on setup time and on conversational ergonomics. If your problem is "I want a durable, deduplicated, attributable corpus of threat data my whole team can query", the broker is the wrong shape entirely, because it has no corpus. A second alternative is writing your own MCP wrappers around the two or three sources you actually use. That is more work up front and less coverage, but it gives you control over retries, caching and output shaping, none of which the README documents here. The honest framing is that darknet-mcp-server competes with your browser tabs and your glue scripts, not with a threat intelligence platform.
Maintenance, release cadence and the MIT licence
The repository is not archived and the last push was on 2026-09-08, so the code is being touched. The release history is thin: v0.1.0 and v0.1.1 both landed on 2026-06-23, and there is no tagged release after that despite the later commits. That pattern, active commits with a stalled version number, is common in early-stage projects and it means the npm artifact you install may lag the repository. If you depend on a fix, check whether it is in the published version or only on main. The licence is MIT, which is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice are preserved. MIT gives you no patent grant and no warranty, so if you are shipping this inside a product, the usual caveat applies and your legal team should read the actual LICENSE file rather than this summary. The upgrade cost is currently low because the version line is 0.x and there is little to migrate between, but that also means breaking changes can arrive without a major version bump. Pin to a specific version in your agent configuration rather than tracking latest.
Who this fits and what to check before you install
The fit is narrow and specific. You need an MCP-capable agent already in place, you need outbound access to a long list of third-party APIs, and you need a SOCKS5 proxy for the .onion tools. You accept that answers are assembled live and are not reproducible on demand. In exchange you get a single conversational entry point to breach exposure, IOC lookups, ransomware tracking, exploit search, blockchain tracing and stealer log search, which is genuinely more convenient than the sixteen-tab workflow the README describes. The misfit is anyone who needs a system of record, anyone whose agent runs in a network-isolated environment, and anyone unwilling to hold API keys for paid sources. The concrete first step is not installation. It is reading the tools reference and the data sources list, writing down which of the 16 sources you already have credentials for, and counting how many of the 66 tools that leaves you. If the answer is fewer than a handful, the correlation story the README sells does not apply to you yet, and the value proposition collapses to a smaller wrapper you could write yourself in an afternoon.
Editorial conclusion
Adopt darknet-mcp-server if you already run an MCP-capable agent and you want breach, IOC, ransomware and .onion lookups to land in one context window instead of sixteen browser tabs; the 2026-09-08 push and the npm v0.1.1 release mean the code is current, but it is still a 0.x line. Do not adopt it if you need an auditable, deterministic pipeline, because the README documents no caching layer and no offline mode, and every query depends on a third-party API being reachable from the agent host. Before wiring it into anything, confirm which of the 16 sources require paid API keys (HIBP and IntelligenceX are named as paid in the README's own workflow comparison), verify that your agent runtime can supply the Tor SOCKS5 proxy the .onion tools expect, and read the tool list to check that the specific sources you care about are among the 66 rather than assumed.
Community notes