Read-only breach intel, full history 2007-today: reports THAT an org was breached, never the data.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 4 of 4 tools scored.
Each tool targets a clearly distinct function: text analysis, news retrieval, entity lookup, and source listing. There is no overlap in purpose, making selection unambiguous.
All names use snake_case and are readable, but they mix verb_noun patterns (assess_threat, check_exposure) with noun_noun patterns (breach_news, feed_sources). This minor inconsistency prevents a perfect score.
With 4 tools, the server is well-scoped for a data breach detector covering analysis, news, lookup, and sources. Each tool earns its place without redundancy or missing essentials.
The tools cover core breach-related tasks (analysis, news, entity check, source info). A minor gap is the lack of batch or monitoring capabilities, but the primary use cases are addressed.
assess_threatClassify 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.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | the security text to classify — an advisory, alert or forum post |
breach_historyASearch 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'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | maximum incidents to return (default 10; raise it deliberately, large pages are heavy for an agent loop) | |
| order | No | 'newest' (default), 'oldest' or 'largest' (by accounts exposed) | newest |
| query | No | optional keyword over entity, title, summary, actor and data types; omit to browse the whole archive | |
| sector | No | industry keyword filter, e.g. 'bank', 'health', 'gaming' | |
| year_to | No | latest incident year to include, e.g. 2020 | |
| data_type | No | require an exposed data type, e.g. 'passwords', 'credit card', 'health' | |
| year_from | No | earliest incident year to include, e.g. 2013 | |
| min_accounts | No | only incidents exposing at least this many accounts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description explicitly states 'Returns disclosure metadata only, never breach contents' — a key behavioral constraint that protects the agent from misusing the tool. It also clarifies the archive's scope ('back to 2007') and that results can be ordered by 'date or size.' This adds valuable context not present in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense without fluff: sources, filter types, result scope, and example questions are packed into four sentences. It is front-loaded with the core action ('Search the FULL historical breach archive') and every clause earns its place. No wasted words.
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?
With 8 parameters and no output schema, the description covers the key behavioral aspects: sources, filters, ordering, return type ('disclosure metadata'), and example use cases. It doesn't detail the exact structure of returned incidents, but for a search tool with rich parameter schema, the guidance is strong. The only gap is the absence of a sample output shape.
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?
The input schema already provides 100% coverage with per-parameter descriptions. The tool description summarizes filter dimensions ('keyword, year range, sector, exposed data type or minimum scale') and ordering, but does not add syntax or meaning beyond what the schema already documents. Baseline 3 is appropriate because the schema does the heavy lifting.
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?
The description opens with 'Search the FULL historical breach archive' — a specific verb + resource — and enumerates data sources (HaveIBeenPwned, ransomwatch, RansomLook, SEC filings) and filter/order capabilities. It clearly distinguishes itself from sibling tools like breach_news or breach_stats because it covers the full historical archive rather than recent news or aggregated stats.
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?
It gives explicit use-case examples: 'what were the biggest breaches of 2013' and 'which airlines have ever been hit by ransomware.' This conveys when to use the tool for historical, broad-scope searches. It doesn't name alternative tools or list exclusions, but the context is clear enough for an agent to select this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
breach_newsRead 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | maximum disclosures to return (default 10; raise it deliberately, large pages are heavy for an agent loop) | |
| sector | No | optional keyword filter over entity, title, summary, categories and exposed data types, e.g. 'bank', 'health', 'crypto' | |
| source | No | optional source filter: 'HaveIBeenPwned', 'RansomLook', 'ransomwatch-archive' or 'SEC EDGAR 8-K 1.05' | |
| since_days | No | look-back window in days over disclosure dates (default 30) |
breach_statsAAggregate 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.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | No | optional industry keyword filter applied before aggregating | |
| group_by | No | aggregation axis: 'year' (default), 'source', 'data_type', 'threat_level' or 'actor' (ransomware group) | year |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds valuable behavioral context: 'Aggregate counts only; no leaked records' clarifies that the tool does not expose sensitive underlying data. It also notes the inclusion of 'five largest incidents ever recorded' as an extra behavior.
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?
The description is concise (two sentences), front-loads the core purpose, provides concrete example queries, and ends with a safety note. Every sentence adds value and there is no fluff.
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?
Given two optional parameters, no output schema, and strong annotations, the description is quite complete. It clarifies return scope (incidents/accounts counts, five largest incidents) and explicitly states no leaked records are returned. A minor gap is the lack of detail on exact response format or pagination, but for an aggregate tool this is acceptable.
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 description coverage is 100%, so the baseline is 3. The description repeats the group_by axes ('per year, per source, per exposed data type, per threat level, or per ransomware actor') but does not add new semantics beyond the schema's own parameter descriptions. It doesn't mention the 'sector' parameter, though the schema already describes it.
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?
The description clearly states the tool aggregates the breach archive into statistics, with a specific verb ('aggregate') and resource ('full breach archive'). It distinguishes itself from siblings by emphasizing 'aggregate counts only; no leaked records', setting it apart from tools like check_exposure or breach_history.
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?
The description provides explicit use cases with example questions ('how has breach volume trended since 2015', 'which ransomware groups have the most victims'). It gives clear context for when to use it, though it does not mention alternative tools or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
breach_timelineABuild the complete incident-by-incident CHRONOLOGY of one organization across every source and all history, oldest first, 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. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | domain, company or brand to build the chronology for, e.g. 'yahoo.com' or 'Adobe' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful behavioral context beyond those: it returns only metadata ('Metadata only; never the leaked data'), orders results oldest first, and includes computed risk judgments like repeat victimhood. This is useful and non-redundant disclosure.
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?
The description is front-loaded with the core purpose and delivers a dense but readable set of specifics. Every sentence earns its place—purpose, risk interpretation, data safety, and explicit alternative. The first sentence is long but well-structured, not bloated.
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?
Despite having no output schema, the description enumerates the output fields (first/latest incident, incidents per year, repeat victim, worst threat level, total accounts). It also covers constraints (metadata only), ordering, and an alternative tool. For a single-parameter read-only tool, this is complete and self-sufficient.
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 one parameter (entity) already includes examples like 'yahoo.com' or 'Adobe'. The description reaffirms the meaning by saying 'one organization' but does not add syntax or formatting details beyond the schema, so the 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?
The description uses a specific verb ('Build the complete incident-by-incident CHRONOLOGY') and names the resource ('one organization across every source and all history') plus explicit output judgments. It also distinguishes from sibling tools by naming check_exposure and from the chronology's unique scope.
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?
The description gives an explicit alternative for a different need: 'For a yes/no presence check use check_exposure.' However, it does not explain when to prefer this tool over other siblings like breach_history or breach_stats, so the guidance is good but not fully comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_exposureAnswer 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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | domain, company or brand to look up, e.g. 'example.com' or 'Acme' | |
| since_days | No | optional look-back window in days; the default covers all history |
feed_sourcesList 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.