# data-breach-detector

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

- name: io.github.beepboop2025/data-breach-detector
- version: 0.3.2
- connection class: R0 (autonomous)
- trust: 91/100
- quality: 88/100 (good)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/io.github.beepboop2025%2Fdata-breach-detector
- tools: https://api.protogrid.dev/v1/servers/io.github.beepboop2025%2Fdata-breach-detector/tools

**An agent can connect right now, no human step.** Remote endpoint, no authentication, reachable on the last probe.

## Connection (mcpServers)

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


## Trust

- hygiene: 100
- liveness: 100
- freshness: 85
- provenance: 80
- drivers: +repository +namespace-matches-repo +reachable +uptime-100% ~updated-66d-ago
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 88/100 (good)

### protocol: 75 (weight 25)

- warn `protocol.modern`: newest supported version is 2025-11-25; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
- n/a `protocol.stateless`: only applies to 2026-07-28 servers
- pass `protocol.transport`: streamable HTTP
- n/a `protocol.list_ttl`: only applies to 2026-07-28 servers

### authorization: n/a (weight 15)

- n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth
- n/a `auth.secret_in_url`: no templated URL

### tool hygiene: 86 (weight 30)

- pass `tools.descriptions`: every tool has a description
- pass `tools.description_length`: descriptions are concise
- pass `tools.schemas`: every tool has an object input schema
- pass `tools.annotations`: 7 of 7 tools declare readOnlyHint or destructiveHint
- fail `tools.directory_hints`: no tool declares all four of readOnlyHint, destructiveHint, idempotentHint and openWorldHint; missing: breach_news (destructiveHint); check_exposure (destructiveHint); breach_history (destructiveHint); …
- pass `tools.token_cost`: about 2,471 tokens to load every tool
- pass `tools.api_dump`: tools are not a one-to-one API dump

### stability: 100 (weight 15)

- pass `stability.changes`: no tool changes in 30 days
- pass `stability.rug_pull`: no tool changed its meaning under the same name

### dependencies: 100 (weight 15)

- pass `deps.known_vulns`: no known advisory in 30 resolved packages
- pass `deps.mcp_sdk_version`: mcp 1.30.0, no known advisory
- pass `deps.resolvable`: data-breach-detector@0.3.1 resolved: 30 packages

- tools: 7, about 2,471 tokens to load them all
- tool set hash: 36f582702b6b5b152cdb4b2625421b81
- badge: [![protogrid quality](https://protogrid.dev/badge/io.github.beepboop2025/data-breach-detector.svg)](https://protogrid.dev/servers/io.github.beepboop2025/data-breach-detector)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

_No tool definition changes recorded._

## Dependencies

- pypi data-breach-detector@0.3.1: resolved, 29 dependencies, MCP SDK mcp 1.30.0

Dependency graphs from deps.dev; advisories from OSV.dev, including the GitHub Advisory Database and the PyPI Advisory Database; all CC BY 4.0.

## Remotes

- https://breach.seiche.info/mcp (streamable-http, auth none, reachable true, uptime30d 1)

## Packages

- pypi data-breach-detector@0.3.1

## Tools (7)

- `assess_threat`: 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.
- `breach_history`: 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'.
- `breach_news`: 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.
- `breach_stats`: 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.
- `breach_timeline`: 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.
- `check_exposure`: 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.
- `feed_sources`: 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.