data-breach-detector
The data-breach-detector server provides read-only breach intelligence aggregated from public disclosure feeds, delivering only metadata about breaches and never exposing leaked records. Key capabilities include:
Breach News: Retrieve recent breach and ransomware disclosures (entity, date, scale, exposed data types, threat level) from sources like HaveIBeenPwned and ransomwatch, filterable by sector and time window.
Exposure Check: Verify if a domain, company, or brand appears in breach data, returning yes/no, mention count, worst threat level, total accounts exposed, and data types.
Threat Assessment: Classify security text (advisories, alerts, posts) locally into threat level, categories, financial-target flags, confidence, and recommended action.
Feed Health: Inspect aggregated feed sources, cached disclosure counts, cache age, staleness, and fetch errors.
Historical Analysis (documented in README, not yet in schema): Query breach history back to 2007, generate organization-specific timelines, and view aggregated stats by year, source, data type, threat level, or ransomware actor.
What it does NOT do:
Never returns raw leaked data, credentials, or PII (redaction is applied).
Does not perform arbitrary fetching, crawling, or access .onion sites.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@data-breach-detector Check if example.com has been breached"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
data-breach-detector
A read-only breach-intelligence MCP server. It answers "has this organization ever been breached, what's the recent breach news, what does two decades of breach history look like, how severe is this threat text" from public disclosure feeds — and reports intelligence, not contents: the existence, timing, scale, category and exposed data-types of a breach, never the leaked records themselves.
Built for defenders and for agents that work on their behalf.
Why this instead of the alternatives
Most breach tooling sits in one of three camps, and each has a structural gap:
Consumer checkers (HaveIBeenPwned's site) answer one question — "is my email in a breach" — one account at a time, one source at a time.
Leak-data brokers (DeHashed, IntelX, LeakCheck and the like) sell access to the leaked records themselves. Wiring one into an AI agent hands the agent stolen credentials.
Enterprise intel platforms (SpyCloud, Recorded Future, Flashpoint) do the join properly — behind five-figure contracts and closed APIs.
This server takes a fourth position:
Four primary sources, one queryable surface. The verified breach directory (HIBP), a live ransomware leak-site tracker (RansomLook), a ~16k-victim leak-site archive back to 2020 (ransomwatch), and SEC 8-K Item 1.05 filings — companies' own legally mandated "material cybersecurity incident" disclosures. Regulator-grade and criminal-infrastructure-grade evidence in the same index. No key, no contract.
History is first-class.
breach_history,breach_timelineandbreach_statstreat 2007→today as the product, not a cache: every breach of 2013, an organization's full incident chronology, repeat-victim flagging, per-year and per-actor aggregates.The ethical boundary is in the code, not the terms of service. No fetch/crawl/proxy primitives, no
.onionaccess, and every feed-authored string is sanitized where the record is built, before any field is assembled from it: emails, hashes, IPs, crypto addresses and credential-shaped tokens are redacted, and the invisible channels used to hide instructions from a human reader (Unicode Tags, zero-widths, bidi overrides, variation selectors, terminal control codes) are stripped. That matters because leak-site titles are written by ransomware crews and read by agents: the same field is both intelligence and an injection surface. Redacting only the two fields a human looks at is not enough, because ids, actor names and statistic bucket keys are built from the same strings.Honesty is instrumented.
feed_sourcesreports each feed's newest item, a staleness flag and the last fetch error — a dead upstream is a served fact, not a silent hole. (The ransomwatch project itself froze in June 2025; this server says so instead of pretending.)MCP-native, free, MIT, self-hostable. One
pip install, stdio or streamable-HTTP.
Related MCP server: Genius Sports RSS Monitor MCP
What it does not do
No arbitrary URL fetch, no crawl, no proxy — no general scraping primitives.
No
.onionmarketplace access, no transactions.Never returns the raw text of a dump, paste or leak. Feed-authored strings are redacted and stripped of hidden-instruction characters at the point each record is constructed, so ids, actor names, entity names, dates, source URLs and aggregation keys are built from sanitized values rather than raw ones.
Sources (public, no key)
HaveIBeenPwned
/api/v3/breaches— the verified breach directory back to 2007: domain, breach date, pwn count, exposed data categories.RansomLook (
ransomlook.io) — live ransomware leak-site tracker.ransomwatch (
joshhighet/ransomwatch) — frozen archive of ~16k leak-site posts, Jan 2020 → Jun 2025, retained as history.SEC EDGAR — 8-K filings carrying Item 1.05 Material Cybersecurity Incidents (mandatory first-party disclosure since Dec 2023).
Tools
tool | what it returns |
| recent disclosures — entity, date, scale, exposed data types, severity |
| does a domain/company appear anywhere in breach data — yes/no + metadata |
| search the full archive back to 2007 |
| one organization's incident-by-incident chronology + repeat-victim assessment |
| aggregates per year / source / data type / threat level / ransomware actor |
| classify a piece of security text — level, categories, action (no network) |
| feeds, per-source freshness, staleness flags, last fetch errors |
Every list tool reports count, limit, offset and returned, and
breach_stats reports buckets_total, so a truncated answer is visible as
truncated and the tail is reachable by paging rather than lost.
Run
pip install data-breach-detector
data-breach-detector # stdio (for MCP clients)
data-breach-detector --http # streamable-HTTP on 127.0.0.1:8790/mcpOr point an MCP client at the config:
{ "mcpServers": { "data_breach_detector": {
"command": "data-breach-detector"
} } }Hosted remote: https://breach.seiche.info/mcp
License
MIT. The breach data belongs to its sources (HaveIBeenPwned, RansomLook, ransomwatch, SEC EDGAR); this tool only aggregates their public disclosure metadata, with attribution.
Available Tools
7 toolsassess_threatARead-onlyIdempotentInspect
Classify a piece of security text you supply — an advisory, alert or forum post — into a threat level, matched categories, financial-target flags, a confidence score and a recommended action. Pure local analysis: it collects nothing, stores nothing and reaches no network; the text never leaves the server. Use it to triage findings surfaced by breach_news or from your own monitoring.
Inputs: text (required).
breach_historyARead-onlyIdempotentInspect
Search the FULL historical breach archive — every incident this server knows about, back to 2007: HaveIBeenPwned's verified breach directory, the 2020-2025 ransomwatch leak-site archive (~16k victims), the RansomLook live tracker and SEC 8-K Item 1.05 filings. Filter by keyword, year range, sector, exposed data type or minimum scale; order by date or size. Returns disclosure metadata only, never breach contents. Use this for questions like 'what were the biggest breaches of 2013' or 'which airlines have ever been hit by ransomware'.
Inputs: limit, order, query, offset, +5 more.
breach_newsARead-onlyIdempotentInspect
Read recent breach and ransomware DISCLOSURES from public threat-intel feeds (HaveIBeenPwned, the RansomLook live leak-site tracker and SEC 8-K Item 1.05 filings), newest first. Every row is metadata only — entity, date, scale, exposed data TYPES, threat level and source — never the leaked data, and a redaction pass strips anything credential-shaped before it is returned. Use sector to narrow to an industry keyword; for one specific organization use check_exposure; for all-time history use breach_history.
Inputs: limit, offset, sector, source, +1 more.
breach_statsARead-onlyIdempotentInspect
Aggregate the full breach archive into analyst-grade statistics: incidents and accounts exposed per year, per source, per exposed data type, per threat level, or per ransomware actor — plus the five largest incidents ever recorded. Use it to answer 'how has breach volume trended since 2015', 'which ransomware groups have the most victims' or 'how often are passwords part of a breach'. Aggregate counts only; no leaked records.
Inputs: limit, sector, group_by.
breach_timelineARead-onlyIdempotentInspect
Build the incident-by-incident CHRONOLOGY of one organization across every source and all history, with judgment on top: first and latest incident, incidents per year, whether the organization is a repeat victim, worst threat level and total accounts ever exposed. Those summary fields cover EVERY incident on record. The timeline list carries a window of them, oldest first within the window, defaulting to the most recent limit incidents and paging backwards with offset, so an organization with a long history shows its current state first rather than only its ancient one. Repeat victimhood is a forward-looking risk signal: organizations named more than once have demonstrably not closed the gap. Metadata only; never the leaked data. For a yes/no presence check use check_exposure.
Inputs: entity (required), limit, offset.
check_exposureARead-onlyIdempotentInspect
Answer whether a domain, company or brand appears in public breach or ransomware DISCLOSURES across ALL history (2007 → today): yes/no with mention count, worst threat level, total accounts exposed across matches, the exposed data TYPES, and the matching disclosure metadata — never the exposed records themselves. This is a triage signal built from disclosure feeds, not proof of compromise; confirm through authorized channels before acting. For the incident-by-incident chronology of one entity, use breach_timeline; for a recent-news sweep, use breach_news. mentions, the aggregates and the data types always cover every match; matches carries one page of them, sized by limit and walked with offset.
Inputs: query (required), limit, offset, since_days.
feed_sourcesARead-onlyIdempotentInspect
List the public disclosure feeds this server aggregates, how many disclosures are cached per source, each source's newest item and an honest staleness flag, plus cache ages. Takes no arguments. Also states the scope plainly: public feeds only — no .onion access, no arbitrary fetching or crawling, no credential or PII output. Check this first if another tool's answer looks thin: a stale live feed is a finding, not background noise.
Inputs: no named parameters.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 7 tools
There is real conceptual overlap between the historical data tools (breach_news, breach_history, check_exposure, breach_timeline all draw on the same disclosure feeds), but the descriptions explicitly route between them (e.g. 'for one specific organization use check_exposure; for all-time history use breach_history'). assess_threat, feed_sources and breach_stats are clearly distinct. An agent could still occasionally pick breach_history when breach_timeline was intended, but boundaries are well signposted.
A clear convention holds: a breach_* family for the archive/feed tools (breach_news, breach_history, breach_timeline, breach_stats) and verb_noun pairs for actions (assess_threat, check_exposure, feed_sources). All snake_case, no mixed casing. Minor deviation in that not every tool follows one single pattern.
Seven tools is a tight, well-scoped set for a breach-intelligence domain: discovery, history, entity triage, timeline, aggregates, threat classification and feed health. Each tool earns its place with no obvious redundancy or filler.
The surface covers the full analyst lifecycle: discovery (breach_news/history), triage (check_exposure/assess_threat), chronology (breach_timeline), aggregates (breach_stats) and self-diagnostics (feed_sources). Minor gaps exist — no per-disclosure detail lookup by id and no report/export tool — but core workflows are closed.
Maintenance
Related MCP Connectors
Free, read-only public-source threat intel over MCP. No account or API key.
Cybersecurity MCP server for URL scanning, threat intelligence, and domain reputation.
Breach intelligence API: email search, domain monitoring, passwords and stealer logs.
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Related MCP Servers
- AlicenseAqualityCmaintenanceA Model Context Protocol (MCP) server that provides integration with the Have I Been Pwned API to check if your accounts or passwords have been compromised in data breaches.42MIT
- FlicenseNot gradedqualityCmaintenanceRead-only MCP server for monitoring public RSS and Atom feeds from competitor and industry websites, enabling competitive intelligence workflows through feed fetching, searching, and thematic summarization.-
- AlicenseAqualityCmaintenanceVerifies factual claims against live sources and returns a verdict, confidence score, and citations for any agent to use before stating uncertain facts.261MIT
- AlicenseNot gradedqualityBmaintenanceA threat intelligence MCP server for Claude Code that enables lookup of IOCs, threat feeds, breached credentials, CVEs, and dark web data.2MIT