# data-breach-detector (remote · breach.seiche.info)

Read-only breach intel, full history 2007-today: reports THAT an org was breached, never the data.

- Trust score: 68/100 (medium)
- Change this week: +12
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `breach.seiche.info`: 68/100 (this document), [markdown](https://verifymcp.io/servers/beepboop2025-data-breach-detector/breach.md), [page](https://verifymcp.io/servers/beepboop2025-data-breach-detector/breach)
- pypi · `data-breach-detector`: 24/100, [markdown](https://verifymcp.io/servers/beepboop2025-data-breach-detector/data-breach-detector.md), [page](https://verifymcp.io/servers/beepboop2025-data-breach-detector/data-breach-detector)

## Channel facts

- Endpoint: `https://breach.seiche.info/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.3.1`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 60/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 7 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC is configured correctly; the domain's records validate against the full chain to the root.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 77/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2091 tokens (~298/item across 7 items; 7 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http beepboop2025-data-breach-detector https://breach.seiche.info/mcp
```

### Codex

```toml
[mcp_servers.beepboop2025-data-breach-detector]
url = "https://breach.seiche.info/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "beepboop2025-data-breach-detector": {
      "type": "remote",
      "url": "https://breach.seiche.info/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add beepboop2025-data-breach-detector --url https://breach.seiche.info/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  beepboop2025-data-breach-detector:
    url: "https://breach.seiche.info/mcp"
```

### Other

```json
{
  "mcpServers": {
    "beepboop2025-data-breach-detector": {
      "type": "http",
      "url": "https://breach.seiche.info/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-02 (score 68, +2)

- [functional regression] Schema quality: 181 → 298
- [functional regression] Schema quality: excellent → unverified
- [functional] First check of Schema quality: 100

### 2026-08-01 (score 66, −1)

- [security] Tool “feed_sources” rewrote its description, which is the text the model reads
- [security] Tool “check_exposure” rewrote its description, which is the text the model reads
- [security] Tool “breach_news” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 134 → 181
- [functional regression] Schema quality: 134 → 178
- [functional] New tool “breach_history”
- [functional] New tool “breach_timeline”
- [functional] New tool “breach_stats”
- [cosmetic] “breach_news” added an optional parameter “source”
- [cosmetic] “breach_history” reworded the description of “limit”
- [cosmetic] “breach_news” reworded the description of “limit”
- [cosmetic] “breach_news” reworded the description of “sector”

### 2026-07-31 (score 67, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 67, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 67, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 66, +10)

- [functional regression] Schema quality: pass → fail
- [functional improvement] Tool coverage: 0% → 100%
- [functional] Schema quality: fair → excellent

### 2026-07-27 (score 56, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 55)

First indexed and scored.

## MCP tools (7)

### `breach_news` (~289 tokens)

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.

Input parameters:

- `limit` (integer): maximum disclosures to return (default 10; raise it deliberately, large pages are heavy for an agent loop)
- `offset` (integer): how many matching disclosures to skip before the page starts; with limit this walks a result set larger than any single page (count reports the full total)
- `sector`: optional keyword filter over entity, title, summary, categories and exposed data types, e.g. 'bank', 'health', 'crypto'
- `since_days` (integer): look-back window in days over disclosure dates (default 30)
- `source`: optional source filter: 'HaveIBeenPwned', 'RansomLook', 'ransomwatch-archive' or 'SEC EDGAR 8-K 1.05'

### `check_exposure` (~262 tokens)

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.

Input parameters:

- `limit` (integer): maximum matching disclosures to return (default 8; the mention count and the aggregates always cover every match)
- `offset` (integer): how many matches to skip before the page starts; with limit this reaches matches beyond the first page
- `query` (string, required): domain, company or brand to look up, e.g. 'example.com' or 'Acme'
- `since_days` (integer): optional look-back window in days; the default covers all history

### `breach_history` (~361 tokens)

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'.

Input parameters:

- `data_type`: require an exposed data type, e.g. 'passwords', 'credit card', 'health'
- `limit` (integer): maximum incidents to return (default 10; raise it deliberately, large pages are heavy for an agent loop)
- `min_accounts` (integer): only incidents exposing at least this many accounts
- `offset` (integer): how many matching incidents to skip before the page starts; count can run to five figures over the ~16k-post archive, so this is how the tail is reached
- `order` (string): 'newest' (default), 'oldest' or 'largest' (by accounts exposed)
- `query`: optional keyword over entity, title, summary, actor and data types; omit to browse the whole archive
- `sector`: industry keyword filter, e.g. 'bank', 'health', 'gaming'
- `year_from`: earliest incident year to include, e.g. 2013
- `year_to`: latest incident year to include, e.g. 2020

### `breach_timeline` (~265 tokens)

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.

Input parameters:

- `entity` (string, required): domain, company or brand to build the chronology for, e.g. 'yahoo.com' or 'Adobe'
- `limit` (integer): how many incidents the timeline list carries (default 12); the counts, span and judgment always cover every incident
- `offset` (integer): pages backwards through the chronology from the recent end: 0 gives the newest window, 12 gives the window before that

### `breach_stats` (~195 tokens)

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.

Input parameters:

- `group_by` (string): aggregation axis: 'year' (default), 'source', 'data_type', 'threat_level' or 'actor' (ransomware group)
- `limit` (integer): how many buckets to return, largest first (default 40); buckets_total reports how many exist, and grouping by actor over the ~16k-post archive produces far more
- `sector`: optional industry keyword filter applied before aggregating

### `assess_threat` (~114 tokens)

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.

Input parameters:

- `text` (string, required): the security text to classify — an advisory, alert or forum post

### `feed_sources` (~108 tokens)

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.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/beepboop2025-data-breach-detector/breach#diagnostics

## Score history

- 2026-08-03: 68
- 2026-08-02: 68
- 2026-08-01: 66
- 2026-07-31: 67
- 2026-07-30: 67
- 2026-07-29: 67
- 2026-07-28: 66
- 2026-07-27: 56
- 2026-07-26: 55

## Links

- Remote endpoint: https://breach.seiche.info/mcp
- Repository: https://github.com/beepboop2025/data-breach-detector
- Changelog RSS feed: https://verifymcp.io/servers/beepboop2025-data-breach-detector/breach/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/beepboop2025-data-breach-detector/breach/changelog.json
- HTML version of this page: https://verifymcp.io/servers/beepboop2025-data-breach-detector/breach