Skip to main content
Glama
beepboop2025

data-breach-detector

by beepboop2025
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

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:

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

  2. History is first-class. breach_history, breach_timeline and 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.

  3. The ethical boundary is in the code, not the terms of service. No 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.

  4. Honesty is instrumented. feed_sources reports 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.)

  5. 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 .onion marketplace 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

breach_news(since_days, sector, source, limit, offset)

recent disclosures — entity, date, scale, exposed data types, severity

check_exposure(query, since_days, limit, offset)

does a domain/company appear anywhere in breach data — yes/no + metadata

breach_history(query, year_from, year_to, sector, data_type, min_accounts, order, limit, offset)

search the full archive back to 2007

breach_timeline(entity, limit, offset)

one organization's incident-by-incident chronology + repeat-victim assessment

breach_stats(group_by, sector, limit)

aggregates per year / source / data type / threat level / ransomware actor

assess_threat(text)

classify a piece of security text — level, categories, action (no network)

feed_sources()

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/mcp

Or 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 tools
assess_threatA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesthe security text to classify — an advisory, alert or forum post

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool performs 'pure local analysis: it collects nothing, stores nothing and reaches no network; the text never leaves the server.' This adds meaningful privacy and network behavior not covered by the annotations' readOnlyHint and idempotentHint. No contradiction exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action and output list, followed by a concise privacy note and usage directive. Every sentence serves a purpose, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there is no output schema, the description does a good job of listing the outputs (threat level, matched categories, financial-target flags, confidence score, recommended action) and the input scenario. It does not specify possible values or formats, but it provides sufficient context for understanding the tool's role and use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully describes the single parameter ('text' with description 'the security text to classify — an advisory, alert or forum post'). The tool description repeats this phrasing almost verbatim without adding new meaning, so with 100% schema coverage, a baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Classify') and identifies the resource ('a piece of security text') and the outputs (threat level, categories, flags, confidence, recommended action). This clearly distinguishes it from sibling tools like breach_news and check_exposure, which focus on retrieving data rather than analyzing text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit context: 'Use it to triage findings surfaced by breach_news or from your own monitoring.' This tells the agent when to invoke the tool, though it does not name alternative tools or give when-not-to-use conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

breach_historyA
Read-onlyIdempotent
Inspect

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

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNomaximum incidents to return (default 10; raise it deliberately, large pages are heavy for an agent loop)
orderNo'newest' (default), 'oldest' or 'largest' (by accounts exposed)newest
queryNooptional keyword over entity, title, summary, actor and data types; omit to browse the whole archive
offsetNohow 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
sectorNoindustry keyword filter, e.g. 'bank', 'health', 'gaming'
year_toNolatest incident year to include, e.g. 2020
data_typeNorequire an exposed data type, e.g. 'passwords', 'credit card', 'health'
year_fromNoearliest incident year to include, e.g. 2013
min_accountsNoonly incidents exposing at least this many accounts

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering mutation safety. The description adds valuable behavioral disclosures: it returns only metadata (no contents), notes that large pages are heavy for an agent loop (in the limit param), and explains offset semantics for reaching the tail of a ~16k-post archive. This goes well beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise yet information-dense, with the core action ('Search the FULL historical breach archive') front-loaded. Every sentence earns its place: sources, filter capabilities, return-type limitation, and concrete example queries. It is well-structured and does not over-elaborate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (9 parameters, multiple sources, no output schema), the description is remarkably complete. It covers the full date range, data sources, filter dimensions, return scope, and even performance guidance for large pages. The absence of an output schema is mitigated by 'Returns disclosure metadata only', which sets clear expectations for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description provides a high-level summary of filter types ('keyword, year range, sector, exposed data type or minimum scale') and ordering ('by date or size'), but this does not add meaningful detail beyond what is already in the schema parameter descriptions. Thus, no score above baseline is warranted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool searches the FULL historical breach archive, enumerates specific data sources (HIBP, ransomwatch, RansomLook, SEC filings), and clarifies it returns disclosure metadata only. This clearly distinguishes breach_history from sibling tools like breach_news or breach_stats by emphasizing the historical, archive-wide scope. Examples ('biggest breaches of 2013') further anchor its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context with 'Use this for questions like...' and defines what it does not return ('never breach contents'). However, it does not explicitly name alternatives or state when to prefer other sibling tools, so it falls short of a 5 which requires explicit when-not/alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

breach_newsA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNomaximum disclosures to return (default 10; raise it deliberately, large pages are heavy for an agent loop)
offsetNohow 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)
sectorNooptional keyword filter over entity, title, summary, categories and exposed data types, e.g. 'bank', 'health', 'crypto'
sourceNooptional source filter: 'HaveIBeenPwned', 'RansomLook', 'ransomwatch-archive' or 'SEC EDGAR 8-K 1.05'
since_daysNolook-back window in days over disclosure dates (default 30)

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnly, openWorld, idempotent), the description discloses that '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.' This clearly explains what the tool does not return and its redaction behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph that front-loads the core purpose and then covers key constraints (metadata only, redaction, ordering) and usage pointers. Every sentence contributes value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the output row composition (entity, date, scale, data types, threat level, source), ordering (newest first), and redaction. Combined with a fully self-documenting schema and sibling disambiguation, the context is complete for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with detailed parameter descriptions (e.g., limit default, range, 'large pages are heavy', offset semantics, sector filter scope). The description adds little new parameter semantics beyond the schema, simply reiterating the sector filter usage. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it 'Read[s] recent breach and ransomware DISCLOSURES from public threat-intel feeds' and specifies the sources (HaveIBeenPwned, RansomLook, SEC 8-K). It explicitly distinguishes itself from siblings by noting 'for one specific organization use check_exposure; for all-time history use breach_history.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit when-to-use guidance: 'Use sector to narrow to an industry keyword; for one specific organization use check_exposure; for all-time history use breach_history.' It also mentions offset/limit behavior in the schema descriptions, reinforcing usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

breach_statsA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNohow 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
sectorNooptional industry keyword filter applied before aggregating
group_byNoaggregation axis: 'year' (default), 'source', 'data_type', 'threat_level' or 'actor' (ransomware group)year

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds meaningful behavior beyond those: 'Aggregate counts only; no leaked records' clarifies it never returns raw records, and 'plus the five largest incidents ever recorded' discloses an extra output. These traits are not covered by annotations, so the description adds useful transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly packed sentences: first states capability and dimensions, second gives real usage examples and a clear boundary. No filler or redundancy; every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description reasonably conveys return shape ('incidents and accounts exposed per year...' plus five largest incidents). It addresses complexity with examples and the no-leaked-records caveat. Slight gap is not detailing limit behavior or bucket ordering, but those are covered in the schema, so remaining context is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with detailed descriptions, including default values, min/max, and semantic notes (e.g., limit buckets_total behavior). The tool description adds no new parameter-specific meaning beyond restating group_by options already in the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Aggregate' with clear resource 'full breach archive' and enumerates exact output dimensions (per year, source, data type, threat level, actor). It differentiates from siblings via 'Aggregate counts only; no leaked records' and answers concrete analyst questions, making purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance via example questions ('how has breach volume trended...', 'which ransomware groups...'). While it doesn't name alternative tools or state when not to use it, the context is clear enough for an agent to select it over the listed siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

breach_timelineA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNohow many incidents the timeline list carries (default 12); the counts, span and judgment always cover every incident
entityYesdomain, company or brand to build the chronology for, e.g. 'yahoo.com' or 'Adobe'
offsetNopages backwards through the chronology from the recent end: 0 gives the newest window, 12 gives the window before that

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses that the tool is metadata-only ('never the leaked data'), that the timeline list carries a window (not all incidents) and how paging works, and that repeat victimhood is a forward-looking risk signal. This adds meaningful behavioral context not derivable from annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is verbose but every sentence earns its place: purpose, summary fields, timeline behavior, interpretative note on repeat victimhood, metadata-only disclosure, and alternative tool. It is front-loaded with the main action and structured logically, though slightly longer than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by naming the summary fields and the timeline list structure, explaining the window and paging, and stating the metadata-only limitation. It does not enumerate every field in the incident list, but given the tool's complexity and that all parameters are documented, this is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters, so baseline is 3. The description adds valuable semantics for limit and offset by explaining the paging behavior ('paging backwards with offset' and the default window), and gives examples for entity ('yahoo.com' or 'Adobe'). This enhances beyond the schema descriptions, justifying a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool builds an incident-by-incident chronology for one organization across all sources, with summary judgments like first/latest incident, incidents per year, repeat victim status, worst threat level, and total accounts. It explicitly differentiates from check_exposure by directing users to that tool for yes/no presence checks, satisfying sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: it explains the timeline window and paging behavior ('defaulting to the most recent limit incidents and paging backwards with offset'), notes that summary fields always cover every incident, and gives an explicit alternative for a different use case ('For a yes/no presence check use check_exposure'). This tells the agent when to use this tool vs. alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_exposureA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNomaximum matching disclosures to return (default 8; the mention count and the aggregates always cover every match)
queryYesdomain, company or brand to look up, e.g. 'example.com' or 'Acme'
offsetNohow many matches to skip before the page starts; with limit this reaches matches beyond the first page
since_daysNooptional look-back window in days; the default covers all history

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnly, openWorld, idempotent), the description adds critical behavioral details: it never returns exposed records, it is built from disclosure feeds rather than proof of compromise, and it explains that aggregates cover all matches while the matches list is paged via limit/offset. These go well beyond the structured annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured, front-loading the core purpose before expanding into caveats, alternatives, and pagination. Each sentence adds necessary information, and there is no fluff. It is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description enumerates the return fields (yes/no, mention count, worst threat level, total accounts exposed, data types, metadata) and clarifies API behavior. It fully covers the necessary context for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

While schema description coverage is 100%, the description adds meaning beyond the schema by explaining how limit/offset affect only the matches page, not the aggregates or mention count, and that since_days default covers all history. This clarifies interaction between parameters and return values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to answer whether a domain, company, or brand appears in breach/ransomware disclosures across all history, returning a yes/no with aggregates and metadata. It also explicitly distinguishes from siblings by naming breach_timeline and breach_news for other use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: it labels the tool as a triage signal, warns against treating it as proof of compromise, and directs users to breach_timeline for chronological details or breach_news for recent news. It also clarifies that the tool never returns exposed records, setting expectations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

feed_sourcesA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint and idempotentHint. The description adds valuable context: an 'honest staleness flag', cache ages, and explicit limitations on what is NOT provided (no PII, no arbitrary crawling). This goes beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and well-structured: first sentence lists the output, second confirms no args, third states scope, and fourth gives usage guidance. Every sentence earns its place, with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the zero-parameter, no-output-schema design, the description fully covers what the agent needs: what is returned (feeds, counts, new items, staleness, cache ages), scope limits, and when to use it. It is complete for a read-only health-check tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description explicitly states 'Takes no arguments', which confirms the empty schema and removes any ambiguity for the agent. This is clear and sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and a precise resource ('public disclosure feeds'), then enumerates exact output elements (cached disclosure counts, newest item, staleness flag, cache ages). This clearly distinguishes it from siblings like breach_news or breach_history, which focus on content rather than feed health.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Check this first if another tool's answer looks thin', giving a concrete usage scenario. It also states scope exclusions ('no .onion access, no arbitrary fetching or crawling, no credential or PII output'), which tells when not to use the tool. This is clear when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.3.2
    • Changedbreach_history3 fields changed
      • changedInput schema / properties / limit / default
        Previous value: -25New value: +10
      • changedInput schema / properties / limit / description
        Previous value: -"maximum incidents to return (default 25)"New value: +"maximum incidents to return (default 10; raise it deliberately, large pages are heavy for an agent loop)"
      • addedInput schema / properties / offset
        Added value: +{
+  "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"
+}
    • Changedbreach_news3 fields changed
      • changedInput schema / properties / limit / default
        Previous value: -25New value: +10
      • changedInput schema / properties / limit / description
        Previous value: -"maximum disclosures to return (default 25)"New value: +"maximum disclosures to return (default 10; raise it deliberately, large pages are heavy for an agent loop)"
      • addedInput schema / properties / offset
        Added value: +{
+  "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"
+}
    • Changedbreach_stats1 field changed
      • addedInput schema / properties / limit
        Added value: +{
+  "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"
+}
    • Changedbreach_timeline2 fields changed
      • addedInput schema / properties / limit
        Added value: +{
+  "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"
+}
      • addedInput schema / properties / offset
        Added value: +{
+  "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"
+}
    • Changedcheck_exposure2 fields changed
      • addedInput schema / properties / limit
        Added value: +{
+  "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"
+}
      • addedInput schema / properties / offset
        Added value: +{
+  "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"
+}
  2. 4 tool updatesv0.1.0
    • Addedbreach_history
    • Changedbreach_news2 fields changed
      • changedInput schema / properties / sector / description
        Previous value: -"optional keyword filter over title, summary, categories and exposed data types, e.g. 'bank', 'health', 'crypto'"New value: +"optional keyword filter over entity, title, summary, categories and exposed data types, e.g. 'bank', 'health', 'crypto'"
      • addedInput schema / properties / source
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "optional source filter: 'HaveIBeenPwned', 'RansomLook', 'ransomwatch-archive' or 'SEC EDGAR 8-K 1.05'",
+  "title": "Source"
+}
    • Addedbreach_stats
    • Addedbreach_timeline
  3. 4 tool updates
    • First observedassess_threat
    • First observedbreach_news
    • First observedcheck_exposure
    • First observedfeed_sources
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 7 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Have I Been Pwned MCP Server

    Cyreslab-AI
    A
    license
    A
    quality
    C
    maintenance
    A 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.
    4
    2
    MIT

  • mcp-threatintel

    pete-builds
    A
    license
    Not graded
    quality
    A
    maintenance
    A threat intelligence MCP server for Claude Code that enables lookup of IOCs, threat feeds, breached credentials, CVEs, and dark web data.
    2
    MIT