data-breach-detector MCP server
online · 100% uptimeRead-only breach intel, full history 2007-today: reports THAT an org was breached, never the data.
0 stars14 downloads/wk
Reviews
Write oneNobody has reviewed data-breach-detector yet.
If you have run it, two minutes of your experience saves the next person an afternoon.
data-breach-detector tools (7)
write = sends, deletes, buys or postsassess_threatFreeClassify 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.
breach_historyFreeSearch 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'.
breach_newsFreeRead 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.
breach_statsFreeAggregate 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.
breach_timelineFreeBuild 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.
check_exposureFreeAnswer 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.
feed_sourcesFreeList 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.
Public scan report
scanner v0.1.10 · 2026-11-03 · same rubric, same numbers if you re-run it
- Code scan8 source files scanned25/25
- Live reliabilityremote reachable in 1487ms20/20
- Tool poisoning7 tool descriptions checked15/15
- Auth qualityopen endpoint, read-only tools10/15
- Maintenancelast push 73 days ago12/15
- Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10
How data-breach-detector compares
Against every graded MCP server, from our own scans and uptime checks. Updated after each scan run.
- Safety score
- 90/100
- higher than 83% of 48,255 servers
- Tools
- 7
- the typical server has 7
- Tools that change things
- 0%
- typical: 0%. Fewer write tools means less an agent can break
- Uptime
- 100%
- of our recent checks; the typical remote server answers 100%
- Response time
- 338 ms
- faster than 43% of 30,031 servers
- Downloads a week
- 14
- more than 4% of 12,191 servers with a package
What its tools let an agent do: 7 read
Install data-breach-detector in Claude Code, Cursor or VS Code
claude mcp add --transport http data-breach-detector https://breach.seiche.info/mcp
What the publisher says
From the data-breach-detector repository's README, as published. We do not edit it. Read it on GitHub
<!-- mcp-name: io.github.beepboop2025/data-breach-detector -->
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:
email in a breach" — one account at a time, one source at a time.
- Consumer checkers (HaveIBeenPwned's site) answer one question — "is my
to the leaked records themselves. Wiring one into an AI agent hands the agent stolen credentials.
- Leak-data brokers (DeHashed, IntelX, LeakCheck and the like) sell access
the join properly — behind five-figure contracts and closed APIs.
- Enterprise intel platforms (SpyCloud, Recorded Future, Flashpoint) do
This server takes a fourth position:
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.
- Four primary sources, one queryable surface. The verified breach
breach_stats treat 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.
- History is first-class. breachhistory, breachtimeline and
fetch/crawl/proxy primitives, no .onion access, 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.
- The ethical boundary is in the code, not the terms of service. No
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.)
- Honesty is instrumented. feed_sources reports each feed's newest
streamable-HTTP.
- MCP-native, free, MIT, self-hostable. One pip install, stdio or
What it does not do
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.
- No arbitrary URL fetch, no crawl, no proxy — no general scraping primitives.
- No .onion marketplace access, no transactions.
- Never returns the raw text of a dump, paste or leak. Feed-authored strings are
Sources (public, no key)
Shortened. The full README is on GitHub.
Nothing above is checked by us. What we check is on the safety report.
data-breach-detector: common questions
- Is data-breach-detector MCP server safe?
- Yes, by our scan: it is graded A (90/100). Read the data-breach-detector safety report
- How do I install data-breach-detector?
- It runs remotely at breach.seiche.info. Add it to Claude Code, Cursor, VS Code or Claude Desktop with the snippets above, or call it through the mcp.market gateway without installing anything.
- Does data-breach-detector need an API key?
- Not as far as the registry entry and our scan can tell: no credentials are declared or required.
- Is data-breach-detector maintained?
- The last commit was 74 days ago (2026-08-22). The latest release is v0.3.2.
- Is data-breach-detector up?
- 100% of our last 28 checks got an answer. We check remote servers about four times a day.
- How does data-breach-detector compare with other MCP servers?
- safety score 90/100 (higher than 83% of 48,255 servers); tools 7 (the typical server has 7); tools that change things 0% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.