AlertsBar
Server Details
Domain exposures: breaches, infostealers, ULP heap, cookies. Counts and samples, free.
- Status
- Healthy
- Uptime
- 99.9% over 20 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one returns aggregate counters, the other a random capped sample of records. Descriptions explicitly tell the agent when to use each (counts first for scale/freshness, samples only when concrete examples are requested), leaving no room for misselection.
Both names follow the same predictable pattern: exposure_<operation>_for_domain. The parallel structure makes the pair immediately readable and consistent.
Two tools is on the thin side for a lookup service, though the narrow domain (counts plus samples) justifies a minimal surface. It leans borderline rather than clearly well-scoped.
Core read operations for credential-exposure data are covered: aggregate counters and example records, with clear semantics for nulls, freshness, and indexing dates. Minor gaps exist (no bulk/multi-domain query or availability listing), but agents can work around these easily.
Available Tools
2 toolsexposure_counts_for_domainARead-onlyInspect
Credential-exposure counters for a domain. Counts only - no credential values or per-account detail. Sources: known breaches, infostealer infections, unattributed heap of ULP (Url,Login,Password) bundles, stolen cookies. All figures are INDEXATION dates, not incident dates: _month/_week mean 'newly indexed', never 'newly leaked' - the underlying leak may be years old. Windows nest (_total includes _month includes _week) - never sum them. Counters are rebuilt once daily, so figures are up to 24h old and never real-time. Repeated calls for the same input within a day return identical values - do not re-query to check for changes. Accepts a bare domain or a full URL; scheme, path, port, case and a leading www. are stripped and subdomains collapse to the registrable domain (multi-tenant hosting suffixes such as github.io are not collapsed). An IDN must already be in punycode (xn--) form. Invalid input (not a domain, an IP address) returns an error. If the domain is not in the index at all, every counter and both dates are null: that means NO DATA, not that the domain is clean - never report it as 'no exposure'. first_indexed_at and last_indexed_at give the date range of the domain's records; use last_indexed_at as the 'last updated' date for the domain. Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. example.com. A full URL is accepted and normalized. |
Output Schema
| Name | Required | Description |
|---|---|---|
| domain | Yes | Normalized domain actually queried. May differ from the input - report this one to the user. |
| cookies_week | Yes | Indexed in last 7d. Subset of cookies_month. |
| breaches_week | Yes | Indexed in last 7d. Subset of breaches_month. |
| cookies_month | Yes | Indexed in last 30d. Subset of cookies_total. |
| cookies_total | Yes | Stolen browser session cookies, indexed all time. Non-zero means session-hijacking risk that a password reset alone does not fix. Cookies are counted here only; they are not included in exposure_samples_for_domain. |
| breaches_month | Yes | Indexed in last 30d. Subset of breaches_total. |
| breaches_total | Yes | Records from known breach incidents, indexed all time. |
| heap_staff_week | Yes | Indexed in last 7d. Subset of heap_staff_month. |
| heap_users_week | Yes | Indexed in last 7d. Subset of heap_users_month. |
| last_indexed_at | Yes | Date-time (format YYYY-MM-DD HH:MM:SS, UTC) when AlertsBar last indexed a record for this domain. This is the domain's 'last updated' date and the only reliable freshness signal - samples are random and say nothing about recency. Say 'newly indexed', never 'newly leaked'. Null if the domain is not in the index. |
| first_indexed_at | Yes | Date-time (format YYYY-MM-DD HH:MM:SS, UTC) when AlertsBar first indexed a record for this domain. Indexation date, not incident date - never say the domain was first leaked then. Null if the domain is not in the index. |
| heap_staff_month | Yes | Indexed in last 30d. Subset of heap_staff_total. |
| heap_staff_total | Yes | Staff logins in unattributed heap of ULP (Url,Login,Password) bundles - no linkable breach, device or leak date. Credentials circulating in the wild. |
| heap_users_month | Yes | Indexed in last 30d. Subset of heap_users_total. |
| heap_users_total | Yes | Customer logins in unattributed heap of ULP (Url,Login,Password) bundles - no linkable breach, device or leak date. |
| stealers_staff_week | Yes | Indexed in last 7d. Subset of stealers_staff_month. |
| stealers_users_week | Yes | Indexed in last 7d. Subset of stealers_users_month. |
| stealers_staff_month | Yes | Indexed in last 30d. Subset of stealers_staff_total. |
| stealers_staff_total | Yes | Staff logins from infostealer-infected devices, indexed all time. Implies a compromised machine, not just a leaked password. The credentials may be for any site, not only this domain's own systems. |
| stealers_users_month | Yes | Indexed in last 30d. Subset of stealers_users_total. |
| stealers_users_total | Yes | Customer logins for this domain's site from infostealer-infected devices, indexed all time. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint available in annotations, the description carries the rest: daily rebuild with up to 24h staleness, idempotent same-day results, indexation-vs-incident date semantics, nested-window warning never to sum counters, free/no-auth. It also discloses the critical null-vs-clean trap that an agent would otherwise misreport.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence and every subsequent sentence carries distinct operational information, so nothing is filler. It is still a dense block, and the normalization rules could be tightened, but the length is justified by the number of traps being flagged.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is not required, yet the description still explains what the returned counters mean, the window nesting, and the all-null case. Together with annotations and schema, an agent has everything needed to call and interpret it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already says a URL is accepted and normalized, yet the description adds real semantics beyond it: scheme/path/port/case/www stripping, subdomain collapse to registrable domain, the multi-tenant suffix exception, required punycode for IDNs, and error behavior for IPs/invalid input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (credential-exposure counters) and explicitly scopes out the detail available elsewhere ('Counts only - no credential values or per-account detail'), which cleanly separates it from the sibling exposure_samples_for_domain. An agent can pick between the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear runtime guidance: do not re-query within a day, treat nulls as NO DATA rather than clean, and use last_indexed_at as the domain's 'last updated'. It routes detail-seekers away implicitly ('no credential values or per-account detail') but never names the sibling tool outright, so the alternative is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
exposure_samples_for_domainARead-onlyInspect
A small RANDOM sample of individual exposure records for a domain - metadata only, capped in number: up to 20 records per type (stealers_users, stealers_staff, heap_users, heap_staff, breaches). Cookies are not sampled - see cookies_* in exposure_counts_for_domain. The sample is neither the newest nor the largest nor the most severe records, and it can differ between calls; identical-looking records can repeat and because of different logins/passwords. Each record says WHICH url was affected, WHICH domain the captured login belonged to, from WHICH source type, roughly when the incident was, and when the record was indexed. It carries NO credentials: no password, no username, and the login's local part is redacted. Use exposure_counts_for_domain first for the scale of the problem and for freshness (last_indexed_at); use this only when the user asks to see concrete examples. Calling again returns another random subset, never the full set - do not call it repeatedly to collect more records.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. example.com. A full URL is accepted and normalized, same rules as exposure_counts_for_domain. |
Output Schema
| Name | Required | Description |
|---|---|---|
| domain | Yes | Normalized domain actually queried. May differ from the input - report this one to the user. |
| records | Yes | A random subset of up to 20 records per type, listed by indexed_at descending inside this response. NOT the newest records: a recent or old indexed_at here says nothing about the domain's overall recency - use last_indexed_at from exposure_counts_for_domain. Capped server-side; an empty array means nothing is indexed for this domain. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, so the description carries real weight and delivers: randomness/non-determinism ('can differ between calls'), duplication ('identical-looking records can repeat'), the sampling bias ('neither newest nor largest nor most severe'), and privacy behavior ('carries NO credentials... local part is redacted'). This is behavioral context far beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what the tool returns, then record fields, then usage guidance. Dense and information-bearing, though somewhat long; a couple of clauses (what each record 'says') could be tightened since an output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-param, read-only sampling tool with an output schema, the description covers everything an agent needs: scope, cap, randomness, credential redaction, and how it relates to the counts sibling. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema coverage is 100%, so the schema already documents 'domain'. The description adds little parameter-level syntax, though it notes cookies are out of scope and references the same normalization rules as the sibling. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('A small RANDOM sample of individual exposure records for a domain'), enumerates the record types and the cap (20 per type), and immediately contrasts with the sibling cookies_* / exposure_counts_for_domain. An agent can distinguish this from exposure_counts_for_domain without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: 'Use exposure_counts_for_domain first for the scale of the problem and for freshness; use this only when the user asks to see concrete examples.' It also gives an explicit anti-pattern: 'do not call it repeatedly to collect more records.' Both when-to-use and when-not-to-use are covered.
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.
2 tool updates
- Changed
exposure_counts_for_domain26 fields changed- changed
Output schema / descriptionPrevious value: -"Counters as of the last daily rebuild. Windows count back from that rebuild, not from request time. Every _total/_month/_week is counted by INDEXATION date, not by when the leak or infection happened. staff = login is an address at this domain (employees); users = login belongs elsewhere but the record is for this domain's site (customers)."New value: +"Counters as of the last daily rebuild. Windows count back from that rebuild, not from request time. Every _total/_month/_week and both dates are by INDEXATION date, not by when the leak or infection happened. All counters and both dates are null when the domain is not in the index (no data - not the same as clean). staff = login is an address at this domain; users = login belongs elsewhere but the record is for this domain's site (customers). For public mailbox providers (e.g. gmail.com, ukr.net) staff means holders of mailboxes at that domain, NOT employees, and the numbers can be huge - do not present them as an employee compromise. Placeholder or test domains (e.g. example.com) also produce staff records that belong to nobody in particular." - changed
Output schema / properties / breaches_month / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / breaches_total / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / breaches_week / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / cookies_month / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / cookies_total / descriptionPrevious value: -"Stolen browser session cookies, indexed all time. Non-zero means session-hijacking risk that a password reset alone does not fix."New value: +"Stolen browser session cookies, indexed all time. Non-zero means session-hijacking risk that a password reset alone does not fix. Cookies are counted here only; they are not included in exposure_samples_for_domain." - changed
Output schema / properties / cookies_total / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / cookies_week / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - added
Output schema / properties / first_indexed_atAdded value: +{ + "description": "Date-time (format YYYY-MM-DD HH:MM:SS, UTC) when AlertsBar first indexed a record for this domain. Indexation date, not incident date - never say the domain was first leaked then. Null if the domain is not in the index.", + "type": [ + "string", + "null" + ] +} - changed
Output schema / properties / heap_staff_month / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / heap_staff_total / descriptionPrevious value: -"Staff logins in unattributed heap of ULP bundles - no linkable breach, device or leak date. Credentials circulating in the wild."New value: +"Staff logins in unattributed heap of ULP (Url,Login,Password) bundles - no linkable breach, device or leak date. Credentials circulating in the wild." - changed
Output schema / properties / heap_staff_total / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / heap_staff_week / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / heap_users_month / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / heap_users_total / descriptionPrevious value: -"Customer logins in unattributed heap of ULP bundles - no linkable breach, device or leak date."New value: +"Customer logins in unattributed heap of ULP (Url,Login,Password) bundles - no linkable breach, device or leak date." - changed
Output schema / properties / heap_users_total / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / heap_users_week / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - added
Output schema / properties / last_indexed_atAdded value: +{ + "description": "Date-time (format YYYY-MM-DD HH:MM:SS, UTC) when AlertsBar last indexed a record for this domain. This is the domain's 'last updated' date and the only reliable freshness signal - samples are random and say nothing about recency. Say 'newly indexed', never 'newly leaked'. Null if the domain is not in the index.", + "type": [ + "string", + "null" + ] +} - changed
Output schema / properties / stealers_staff_month / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / stealers_staff_total / descriptionPrevious value: -"Staff logins from infostealer-infected devices, indexed all time. Implies a compromised machine, not just a leaked password."New value: +"Staff logins from infostealer-infected devices, indexed all time. Implies a compromised machine, not just a leaked password. The credentials may be for any site, not only this domain's own systems." - changed
Output schema / properties / stealers_staff_total / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / stealers_staff_week / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / stealers_users_month / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / stealers_users_total / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / stealers_users_week / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / requiredPrevious value: -[ - "domain", - "breaches_total", - "breaches_month", - "breaches_week", - "cookies_total", - "cookies_month", - "cookies_week", - "stealers_staff_total", - "stealers_staff_month", - "stealers_staff_week", - "stealers_users_total", - "stealers_users_month", - "stealers_users_week", - "heap_staff_total", - "heap_staff_month", - "heap_staff_week", - "heap_users_total", - "heap_users_month", - "heap_users_week" -]New value: +[ + "domain", + "first_indexed_at", + "last_indexed_at", + "breaches_total", + "breaches_month", + "breaches_week", + "cookies_total", + "cookies_month", + "cookies_week", + "stealers_staff_total", + "stealers_staff_month", + "stealers_staff_week", + "stealers_users_total", + "stealers_users_month", + "stealers_users_week", + "heap_staff_total", + "heap_staff_month", + "heap_staff_week", + "heap_users_total", + "heap_users_month", + "heap_users_week" +]
- Changed
exposure_samples_for_domain9 fields changed- changed
Output schema / descriptionPrevious value: -"A capped sample of exposure records. Metadata only - no credentials of any kind. This is a SAMPLE, never the full set: the number of records here says nothing about the true volume, which only exposure_counts_for_domain reports. Never describe the count of records in this response as the number of exposures."New value: +"A random capped sample of exposure records. Metadata only - no credentials of any kind. This is a SAMPLE, never the full set: the number of records here says nothing about the true volume, which only exposure_counts_for_domain reports. Never describe the count of records in this response as the number of exposures, and never infer how recent the domain's exposure is from this list." - changed
Output schema / properties / records / descriptionPrevious value: -"The sampled records, newest indexed first. Capped server-side; an empty array means nothing is indexed for this domain."New value: +"A random subset of up to 20 records per type, listed by indexed_at descending inside this response. NOT the newest records: a recent or old indexed_at here says nothing about the domain's overall recency - use last_indexed_at from exposure_counts_for_domain. Capped server-side; an empty array means nothing is indexed for this domain." - changed
Output schema / properties / records / items / properties / estimated_incident_at / descriptionPrevious value: -"Unix seconds, and its meaning follows type. stealers_*: ESTIMATED infection date - an estimate, so always say 'around' or 'estimated'. breaches: the date the breach was PUBLISHED, which is later than when it happened - say 'published', never 'happened'. heap_*: always null, never render it - say the leak date is unknown."New value: +"Unix seconds or null, and its meaning follows type. stealers_*: ESTIMATED infection date - an estimate, so always say 'around' or 'estimated'. breaches: the date the breach was PUBLISHED, which is later than when it happened - say 'published', never 'happened'. heap_*: always null (unknown) - never render it as a date, say the leak date is unknown." - changed
Output schema / properties / records / items / properties / indexed_at / descriptionPrevious value: -"Unix seconds. When AlertsBar indexed this record. Always a fact, unlike estimated_incident_at. A recent indexed_at with an older estimated_incident_at means a long-standing compromise only just discovered - say 'newly discovered', never 'newly leaked'."New value: +"Unix seconds (UTC). When AlertsBar indexed this record. Always a fact, unlike estimated_incident_at. A recent indexed_at with an older estimated_incident_at means a long-standing compromise only just discovered - say 'newly discovered', never 'newly leaked'. Many breach records share one identical indexed_at because they were bulk-imported." - changed
Output schema / properties / records / items / properties / login / descriptionPrevious value: -"The captured login with its LOCAL PART REDACTED, e.g. ...@company.com - only the domain part is real, and no address, name or individual is identified. This is what ties the record to the queried domain: for *_staff the domain part equals the queried domain, meaning an address at this organisation was found with credentials for url; for *_users it is an outside provider (gmail.com and such), meaning an external person's credentials for this organisation's site were taken. Use it to explain WHY a record belongs to this domain. The dots are a redaction, NOT a wildcard: this is one single account, never all addresses at that domain. Full logins are not available through MCP at all - they require domain ownership verification and an API key."New value: +"The captured login with its LOCAL PART REDACTED, e.g. ...@company.com - only the part after @ is real, and no address, name or individual is identified. This is what ties the record to the queried domain: for *_staff the domain part equals the queried domain, meaning an address at this domain was found with credentials for url; for *_users it is usually an outside provider (gmail.com and such), meaning an external person's credentials for this organisation's site were taken. For stealers_users the part after @ can also be a bare host label (e.g. ...@local) or missing entirely (just '...'), and letter case is as captured. Use it to explain WHY a record belongs to this domain. The dots are a redaction, NOT a wildcard: this is one single account, never all addresses at that domain. Full logins are not available through MCP at all - they require domain ownership verification and an API key." - changed
Output schema / properties / records / items / properties / source / descriptionPrevious value: -"Opaque internal reference source feed or breach inside AlertsBar, shared by every record from it; quote it to identify the incident, not the individual row. Its only purpose is follow-up - the user can quote it to AlertsBar support or use it against the REST API to pull the full record. Show it verbatim as a reference id when the user wants to investigate a specific record further, and otherwise leave it out of the summary."New value: +"Opaque internal id of the source feed or breach inside AlertsBar, shared by every record that came from it - it identifies the feed, not the individual row. It is NOT a name: do not read a stealer family, breach name, vendor or feed out of it, and never guess what it stands for. Its only purpose is follow-up - the user can quote it to AlertsBar support or use it against the REST API to pull the full record. Show it verbatim as a reference id when the user wants to investigate a specific record further, and otherwise leave it out of the summary." - changed
Output schema / properties / records / items / properties / source / typePrevious value: -[ - "integer", - "string" -]New value: +"integer" - changed
Output schema / properties / records / items / properties / type / descriptionPrevious value: -"Which source this record came from. stealers_* = credentials taken off a specific infostealer-infected device, so a machine is compromised, not just a password. heap_* = credentials found in an unattributed ULP (Url,Login,Password) bundle, with no linkable incident, device or date. breaches = a record from a known breach incident. *_staff = the login was an address at this domain (employee); *_users = the login belonged elsewhere but the record targets this domain's site (customer)."New value: +"Which source this record came from. stealers_* = credentials taken off a specific infostealer-infected device, so a machine is compromised, not just a password. heap_* = credentials found in an unattributed ULP (Url,Login,Password) bundle, with no linkable incident, device or date. breaches = a record from a known breach incident. *_staff = the login was an address at this domain; *_users = the login belonged elsewhere but the record targets this domain's site (customer). For public mailbox providers (gmail.com, ukr.net) *_staff means a mailbox holder, not an employee. Cookies never appear here." - changed
Output schema / properties / records / items / properties / url / descriptionPrevious value: -"The URL the captured credentials were for - the specific login endpoint, not just the domain. This is the actionable field: it says which of the organisation's systems is affected."New value: +"The URL, hostname or app identifier the captured credentials were for, shown as captured and NOT normalized: it may lack a scheme, include a path, be an android:// app id, a localhost/dev address or a placeholder host. For *_users it is normally a system of the queried organisation. For *_staff it is often a THIRD-PARTY site the employee signed in to, not the organisation's own system - do not say the organisation's system was breached unless the host belongs to the queried domain."
2 tool updates
- Changed
exposure_counts_for_domain2 fields changed- changed
Output schema / properties / heap_staff_total / descriptionPrevious value: -"Staff logins in unattributed ULP bundles - no linkable breach, device or leak date. Credentials circulating in the wild."New value: +"Staff logins in unattributed heap of ULP bundles - no linkable breach, device or leak date. Credentials circulating in the wild." - changed
Output schema / properties / heap_users_total / descriptionPrevious value: -"Customer logins in unattributed ULP bundles - no linkable breach, device or leak date."New value: +"Customer logins in unattributed heap of ULP bundles - no linkable breach, device or leak date."
- Changed
exposure_samples_for_domain3 fields changed- changed
Output schema / properties / records / items / properties / estimated_incident_at / descriptionPrevious value: -"Unix seconds, and its meaning follows type. stealers_*: ESTIMATED infection date - an estimate, so always say 'around' or 'estimated'. breaches: the date the breach was PUBLISHED, which is later than when it happened - say 'published', never 'happened'. heap_*: always null, because heap records carry no incident date at all; say the date is unknown and give no number."New value: +"Unix seconds, and its meaning follows type. stealers_*: ESTIMATED infection date - an estimate, so always say 'around' or 'estimated'. breaches: the date the breach was PUBLISHED, which is later than when it happened - say 'published', never 'happened'. heap_*: always null, never render it - say the leak date is unknown." - changed
Output schema / properties / records / items / properties / source / descriptionPrevious value: -"Opaque internal reference for this record inside AlertsBar. It is NOT a name: do not read a stealer family, breach name, vendor or feed out of it, and never guess what it stands for. Its only purpose is follow-up - the user can quote it to AlertsBar support or use it against the REST API to pull the full record. Show it verbatim as a reference id when the user wants to investigate a specific record further, and otherwise leave it out of the summary."New value: +"Opaque internal reference source feed or breach inside AlertsBar, shared by every record from it; quote it to identify the incident, not the individual row. Its only purpose is follow-up - the user can quote it to AlertsBar support or use it against the REST API to pull the full record. Show it verbatim as a reference id when the user wants to investigate a specific record further, and otherwise leave it out of the summary." - changed
Output schema / properties / records / items / properties / type / descriptionPrevious value: -"Which source this record came from. stealers_* = credentials taken off a specific infostealer-infected device, so a machine is compromised, not just a password. heap_* = credentials found in an unattributed ULP bundle, with no linkable incident, device or date. breaches = a record from a known breach incident. *_staff = the login was an address at this domain (employee); *_users = the login belonged elsewhere but the record targets this domain's site (customer)."New value: +"Which source this record came from. stealers_* = credentials taken off a specific infostealer-infected device, so a machine is compromised, not just a password. heap_* = credentials found in an unattributed ULP (Url,Login,Password) bundle, with no linkable incident, device or date. breaches = a record from a known breach incident. *_staff = the login was an address at this domain (employee); *_users = the login belonged elsewhere but the record targets this domain's site (customer)."
1 tool update
- Changed
exposure_samples_for_domain3 fields changed- added
Output schema / properties / records / items / properties / loginAdded value: +{ + "description": "The captured login with its LOCAL PART REDACTED, e.g. ...@company.com - only the domain part is real, and no address, name or individual is identified. This is what ties the record to the queried domain: for *_staff the domain part equals the queried domain, meaning an address at this organisation was found with credentials for url; for *_users it is an outside provider (gmail.com and such), meaning an external person's credentials for this organisation's site were taken. Use it to explain WHY a record belongs to this domain. The dots are a redaction, NOT a wildcard: this is one single account, never all addresses at that domain. Full logins are not available through MCP at all - they require domain ownership verification and an API key.", + "type": "string" +} - added
Output schema / properties / records / items / properties / sourceAdded value: +{ + "description": "Opaque internal reference for this record inside AlertsBar. It is NOT a name: do not read a stealer family, breach name, vendor or feed out of it, and never guess what it stands for. Its only purpose is follow-up - the user can quote it to AlertsBar support or use it against the REST API to pull the full record. Show it verbatim as a reference id when the user wants to investigate a specific record further, and otherwise leave it out of the summary.", + "type": [ + "integer", + "string" + ] +} - changed
Output schema / properties / records / items / requiredPrevious value: -[ - "type", - "url", - "estimated_incident_at", - "indexed_at" -]New value: +[ + "type", + "url", + "login", + "source", + "estimated_incident_at", + "indexed_at" +]
2 tool updates
- Changed
exposure_counts_for_domain1 field changed- changed
Input schema / properties / domain / descriptionPrevious value: -"Domain to check, e.g. example.com."New value: +"Domain to check, e.g. example.com. A full URL is accepted and normalized."
- Added
exposure_samples_for_domain
1 tool update
- First observed
exposure_counts_for_domain
Related MCP Connectors
Breach intelligence API: email search, domain monitoring, passwords and stealer logs.
WHOIS/RDAP, DNS, SSL, live subdomains with IPs, and SPF/DMARC/DKIM for any domain.
Discover exposed assets, leaked secrets, APIs & client-side vulns across your attack surface
- NetAPIOAuthcom.netapi
Domain data: Top 1M domain ranks, compromised checks, new domain search, registered domain lists.
Related MCP Servers
- AlicenseAqualityDmaintenanceDomain intelligence for DNS, WHOIS/RDAP, SSL/TLS, subdomain discovery, availability, valuation, email security, and typosquatting and brand protection.11MIT
- FlicenseNot gradedqualityBmaintenancePassive website security and trust auditor that checks for security, SEO, AI surface, email, and other exposures, producing a score and remediation plan.-
- AlicenseAqualityBmaintenanceDomain and company intelligence for AI agents. Enables vetting companies, qualifying leads, and mapping targets from free public data without API keys.601MIT
- AlicenseAqualityDmaintenanceDark web & threat intelligence for AI agents. HIBP, ThreatFox, ransomware tracking, Tor .onion access, blockchain intel, exploit search, stealer logs, malware analysis — unified into a single MCP server.66450 npm477MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.