Skip to main content
Glama

AlertsBar

exposure_samples_for_domain

Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesDomain to check, e.g. example.com. A full URL is accepted and normalized, same rules as exposure_counts_for_domain.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesNormalized domain actually queried. May differ from the input - report this one to the user.
recordsYesA 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • changedOutput schema / description
      Previous 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."
    • changedOutput schema / properties / records / description
      Previous 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."
    • changedOutput schema / properties / records / items / properties / estimated_incident_at / description
      Previous 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."
    • changedOutput schema / properties / records / items / properties / indexed_at / description
      Previous 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."
    • changedOutput schema / properties / records / items / properties / login / description
      Previous 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."
    • changedOutput schema / properties / records / items / properties / source / description
      Previous 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."
    • changedOutput schema / properties / records / items / properties / source / type
      Previous value: -[
      -  "integer",
      -  "string"
      -]New value: +"integer"
    • changedOutput schema / properties / records / items / properties / type / description
      Previous 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."
    • changedOutput schema / properties / records / items / properties / url / description
      Previous 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. Changed3 schema fields changed
    • changedOutput schema / properties / records / items / properties / estimated_incident_at / description
      Previous 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."
    • changedOutput schema / properties / records / items / properties / source / description
      Previous 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."
    • changedOutput schema / properties / records / items / properties / type / description
      Previous 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)."
  3. Changed3 schema fields changed
    • addedOutput schema / properties / records / items / properties / login
      Added 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"
      +}
    • addedOutput schema / properties / records / items / properties / source
      Added 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"
      +  ]
      +}
    • changedOutput schema / properties / records / items / required
      Previous value: -[
      -  "type",
      -  "url",
      -  "estimated_incident_at",
      -  "indexed_at"
      -]New value: +[
      +  "type",
      +  "url",
      +  "login",
      +  "source",
      +  "estimated_incident_at",
      +  "indexed_at"
      +]
  4. Added

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources