data-breach-detector

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

사용해야 할까요

품질 및 안전성

A
설명 품질
100%
스키마 완전성
82%
이름 품질
86%
오염 위험
100%
권한 일치
100%
프로토콜 준수
100%

도구 정의와 프로토콜 준수에 대한 자동 분석을 기반으로 합니다.

컨텍스트 비용

~2,384토큰 (도구 정의)
~2.1 KB일반적인 응답 크기
중간 정도의 주의 영향 (128k 컨텍스트의 1.86%)

이는 서버의 도구가 모델의 컨텍스트에 로드될 때마다 소비되는 대략적인 토큰 수입니다. 수치가 높을수록 다른 작업에 사용할 수 있는 주의가 줄어듭니다.

설치

원클릭 설치

`claude_desktop_config.json` 파일에 다음을 추가하세요:

{
  "mcpServers": {
    "data-breach-detector": {
      "command": "uvx",
      "args": [
        "data-breach-detector"
      ]
    }
  }
}

실행 가능한 패키지

pypidata-breach-detector0.3.1stdio

원격 엔드포인트

https://breach.seiche.info/mcpstreamable-http

할 수 있는 일

도구 목록

도구 (7)

🟢 읽기 전용🟡 쓰기🔴 삭제⚪ 알 수 없음
🟢breach_news(since_days, sector, source, limit, offset)

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.

입력 스키마

{
  "type": "object",
  "properties": {
    "since_days": {
      "default": 30,
      "description": "look-back window in days over disclosure dates (default 30)",
      "minimum": 1,
      "title": "Since Days",
      "type": "integer"
    },
    "sector": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "optional keyword filter over entity, title, summary, categories and exposed data types, e.g. 'bank', 'health', 'crypto'",
      "title": "Sector"
    },
    "source": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "optional source filter: 'HaveIBeenPwned', 'RansomLook', 'ransomwatch-archive' or 'SEC EDGAR 8-K 1.05'",
      "title": "Source"
    },
    "limit": {
      "default": 10,
      "description": "maximum disclosures to return (default 10; raise it deliberately, large pages are heavy for an agent loop)",
      "maximum": 100,
      "minimum": 1,
      "title": "Limit",
      "type": "integer"
    },
    "offset": {
      "default": 0,
      "description": "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)",
      "minimum": 0,
      "title": "Offset",
      "type": "integer"
    }
  },
  "title": "breach_newsArguments"
}
🟢check_exposure(query, since_days, limit, offset)

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.

입력 스키마

{
  "type": "object",
  "properties": {
    "query": {
      "description": "domain, company or brand to look up, e.g. 'example.com' or 'Acme'",
      "title": "Query",
      "type": "string"
    },
    "since_days": {
      "default": 100000,
      "description": "optional look-back window in days; the default covers all history",
      "minimum": 1,
      "title": "Since Days",
      "type": "integer"
    },
    "limit": {
      "default": 8,
      "description": "maximum matching disclosures to return (default 8; the mention count and the aggregates always cover every match)",
      "maximum": 100,
      "minimum": 1,
      "title": "Limit",
      "type": "integer"
    },
    "offset": {
      "default": 0,
      "description": "how many matches to skip before the page starts; with limit this reaches matches beyond the first page",
      "minimum": 0,
      "title": "Offset",
      "type": "integer"
    }
  },
  "required": [
    "query"
  ],
  "title": "check_exposureArguments"
}
🟢breach_history(query, year_from, year_to, sector, data_type, ...)

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

입력 스키마

{
  "type": "object",
  "properties": {
    "query": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "optional keyword over entity, title, summary, actor and data types; omit to browse the whole archive",
      "title": "Query"
    },
    "year_from": {
      "anyOf": [
        {
          "minimum": 2000,
          "type": "integer"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "earliest incident year to include, e.g. 2013",
      "title": "Year From"
    },
    "year_to": {
      "anyOf": [
        {
          "minimum": 2000,
          "type": "integer"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "latest incident year to include, e.g. 2020",
      "title": "Year To"
    },
    "sector": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "industry keyword filter, e.g. 'bank', 'health', 'gaming'",
      "title": "Sector"
    },
    "data_type": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "require an exposed data type, e.g. 'passwords', 'credit card', 'health'",
      "title": "Data Type"
    },
    "min_accounts": {
      "default": 0,
      "description": "only incidents exposing at least this many accounts",
      "minimum": 0,
      "title": "Min Accounts",
      "type": "integer"
    },
    "order": {
      "default": "newest",
      "description": "'newest' (default), 'oldest' or 'largest' (by accounts exposed)",
      "title": "Order",
      "type": "string"
    },
    "limit": {
      "default": 10,
      "description": "maximum incidents to return (default 10; raise it deliberately, large pages are heavy for an agent loop)",
      "maximum": 100,
      "minimum": 1,
      "title": "Limit",
      "type": "integer"
    },
    "offset": {
      "default": 0,
      "description": "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",
      "minimum": 0,
      "title": "Offset",
      "type": "integer"
    }
  },
  "title": "breach_historyArguments"
}
🟢breach_timeline(entity, limit, offset)

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.

입력 스키마

{
  "type": "object",
  "properties": {
    "entity": {
      "description": "domain, company or brand to build the chronology for, e.g. 'yahoo.com' or 'Adobe'",
      "title": "Entity",
      "type": "string"
    },
    "limit": {
      "default": 12,
      "description": "how many incidents the timeline list carries (default 12); the counts, span and judgment always cover every incident",
      "maximum": 100,
      "minimum": 1,
      "title": "Limit",
      "type": "integer"
    },
    "offset": {
      "default": 0,
      "description": "pages backwards through the chronology from the recent end: 0 gives the newest window, 12 gives the window before that",
      "minimum": 0,
      "title": "Offset",
      "type": "integer"
    }
  },
  "required": [
    "entity"
  ],
  "title": "breach_timelineArguments"
}
🟢breach_stats(group_by, sector, limit)

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.

입력 스키마

{
  "type": "object",
  "properties": {
    "group_by": {
      "default": "year",
      "description": "aggregation axis: 'year' (default), 'source', 'data_type', 'threat_level' or 'actor' (ransomware group)",
      "title": "Group By",
      "type": "string"
    },
    "sector": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "optional industry keyword filter applied before aggregating",
      "title": "Sector"
    },
    "limit": {
      "default": 40,
      "description": "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",
      "maximum": 500,
      "minimum": 1,
      "title": "Limit",
      "type": "integer"
    }
  },
  "title": "breach_statsArguments"
}
🟢assess_threat(text)

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.

입력 스키마

{
  "type": "object",
  "properties": {
    "text": {
      "description": "the security text to classify — an advisory, alert or forum post",
      "title": "Text",
      "type": "string"
    }
  },
  "required": [
    "text"
  ],
  "title": "assess_threatArguments"
}
🟢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.

입력 스키마

{
  "type": "object",
  "properties": {},
  "title": "feed_sourcesArguments"
}

커뮤니티

이 서버 평가하기

증거

최근 관측

검증됨버전이 기록되지 않음도구 7개
검증됨버전이 기록되지 않음도구 7개
검증됨버전이 기록되지 않음도구 7개