# LeakData

> Check breach exposure for your verified email and check locally computed password hash prefixes.

- name: io.github.leakdatahq/leakdata-mcp
- version: 1.3.2
- connection class: R0 (autonomous)
- trust: 76/100 flags: no-repository
- quality: 72/100 (needs work)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/io.github.leakdatahq%2Fleakdata-mcp
- tools: https://api.protogrid.dev/v1/servers/io.github.leakdatahq%2Fleakdata-mcp/tools

**An agent can connect right now, no human step.** Remote endpoint, no authentication, reachable on the last probe.

## Connection (mcpServers)

```json
{
  "mcpServers": {
    "leakdata-mcp": {
      "type": "http",
      "url": "https://leakdata.io/mcp"
    }
  }
}
```


## Trust

- hygiene: 80
- liveness: 99
- freshness: 85
- provenance: 45
- drivers: +website +reachable +uptime-97% ~updated-40d-ago -no-repository
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 72/100 (needs work)

### protocol: 75 (weight 25)

- warn `protocol.modern`: newest supported version is 2025-11-25; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
- n/a `protocol.stateless`: only applies to 2026-07-28 servers
- pass `protocol.transport`: streamable HTTP
- n/a `protocol.list_ttl`: only applies to 2026-07-28 servers

### authorization: n/a (weight 15)

- n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth
- n/a `auth.secret_in_url`: no templated URL

### tool hygiene: 93 (weight 30)

- pass `tools.descriptions`: every tool has a description
- warn `tools.description_length`: 2 tools have descriptions over 1,024 characters, which crowds the context
- pass `tools.schemas`: every tool has an object input schema
- pass `tools.annotations`: 7 of 7 tools declare readOnlyHint or destructiveHint
- pass `tools.directory_hints`: every tool declares readOnlyHint, destructiveHint, idempotentHint and openWorldHint
- pass `tools.token_cost`: about 1,880 tokens to load every tool
- pass `tools.api_dump`: tools are not a one-to-one API dump

### stability: 25 (weight 15)

- warn `stability.changes`: 12 tool changes in 30 days
- fail `stability.rug_pull`: 1 tools kept their name but changed most of their description in 30 days; review before trusting them

### dependencies: n/a (weight 15)

- n/a `deps.known_vulns`, `deps.mcp_sdk_version`, `deps.resolvable`: no npm or PyPI package

- tools: 7, about 1,880 tokens to load them all
- tool set hash: 1eedf3689e7861c30aa8d448b230d490
- tools last changed: 2026-10-20T02:51:05.530Z
- badge: [![protogrid quality](https://protogrid.dev/badge/io.github.leakdatahq/leakdata-mcp.svg)](https://protogrid.dev/servers/io.github.leakdatahq/leakdata-mcp)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

- 2026-10-20 `leakdata.company_monitoring` changed (title, description, annotations)
  - before: Use this when someone asks about their own company or employer: whether it had a data breach, whether its domain, staff email addresses or work accounts appear in data breaches, or how to monitor a business domain. Explains what LeakData checks for a domain the company verifies it owns and returns any public catalog breaches listed for exactly that domain with their details. Explain setup using the returned checks and requirements; do not offer plans, prices or sales links. No sign-in is needed. It does not search employee addresses or reveal any person's data; never claim it did. Not listed means not in LeakData's catalog, not that the company was never breached.
  - after: Use this when someone asks about their own company or employer: whether it had a data breach, whether its domain, staff email addresses or work accounts appear in data breaches, or how to monitor a business domain. Explains what LeakData checks for a domain the company verifies it owns and returns any public catalog breaches listed for exactly that domain with their details. Explain setup using the returned checks and requirements; do not offer plans, prices or sales links. No sign-in is needed. It does not enable monitoring, search employee addresses, or reveal any person's data; never claim it did. Not listed means not in LeakData's catalog, not that the company was never breached.
- 2026-10-20 `leakdata.protection_summary` changed (title, annotations)
- 2026-10-19 `leakdata.password_prefix_check` removed
  - Call this only when the current user message supplies a locally computed five-character SHA-1 hash prefix and asks to check it. Never invent a prefix or reuse one from an earlier message. For general questions about password checks, explain local SHA-1 computation and sharing only its first five hexadecimal characters without calling a tool. Never accept a plaintext password or complete hash. Report only the aggregate values actually returned by this call. Results describe a prefix group only. A matching prefix does not establish whether a particular password is exposed. Do not report confirmed password exposure or recommend changing a password based only on this result. An empty group does not prove that a password is safe.
- 2026-10-19 `leakdata.mark_step_done` added
  - Use this only after the user says they completed (or want to reopen) a specific step from leakdata.action_plan, for example "I changed my Canva password". Pass that step's stepId from leakdata.action_plan and done=true, or done=false to reopen it; if no action plan result in this conversation contains the step, call leakdata.action_plan first. Saves the change to the user's LeakData action plan; it does not change anything on the breached site. A request to mark all or several steps done is not confirmation: ask which steps the user actually finished and call this once per confirmed step. Never guess a stepId.
- 2026-10-19 `leakdata.action_plan` added
  - Use this when the linked LeakData user asks what they should do about their breaches, what is left on their list, or wants to be walked through the steps. Returns the open and done steps of the user's own action plan (for example "Change your password" on a breached site), each with a stepId, the service it applies to, the masked monitored address and whether it is done. Walk the user through open steps one at a time, in the order returned (most urgent first). Report only the returned steps; never invent steps or mark progress yourself. Takes no arguments.
- 2026-10-19 `leakdata.company_monitoring` added
  - Use this when someone asks about their own company or employer: whether it had a data breach, whether its domain, staff email addresses or work accounts appear in data breaches, or how to monitor a business domain. Explains what LeakData checks for a domain the company verifies it owns and returns any public catalog breaches listed for exactly that domain with their details. Explain setup using the returned checks and requirements; do not offer plans, prices or sales links. No sign-in is needed. It does not search employee addresses or reveal any person's data; never claim it did. Not listed means not in LeakData's catalog, not that the company was never breached.
- 2026-10-19 `leakdata.recent_breaches` added
  - Use this when someone asks which data breaches happened recently or what the latest breaches are. Returns the newest breaches in LeakData's public catalog, newest incident date first, with date, affected account count, exposed data types and first steps. No sign-in is needed. It has no date filter: check the returned dates and say so when none fall in the period the user asked about. It is LeakData's catalog, not every breach worldwide. Not for general security, ransomware or vulnerability news.
- 2026-10-19 `leakdata.breach_lookup` added
  - Use this when someone asks whether a company, app or website was hacked or had a data breach, what data leaked, whether a breach notice they received is real, or what to do about a breach they heard of ("Was Canva hacked?", "What leaked in the Ticketmaster breach?"). Searches LeakData's public breach catalog by company, service or domain name and returns each matching breach's date, affected account count, exposed data types, a short summary and the first steps to take. No sign-in is needed. It does not tell whether a particular person's email is in the breach: when emailCheckAvailable is true, offer to check the user's own email with leakdata.search; when it is false, say LeakData cannot check addresses against that breach. When match is "similar", say the name only resembles what the user asked about. No match means the breach is not in LeakData's catalog, not that the company was never breached. If the company is the user's own business or employer, use leakdata.company_monitoring instead. Not for general security news or a person's name.
- 2026-10-19 `leakdata.protection_summary` added
  - Use this when the linked LeakData user asks how their monitoring is going, what LeakData has found for them, or whether anything new turned up. Returns the user's own monitored email addresses (masked), when each was last checked, how many findings each has, new findings in the last 30 days, and a count of open action-plan steps. It reports stored monitoring results; for a fresh check of the user's email use leakdata.search, and for the steps themselves use leakdata.action_plan. Takes no arguments. Report only the returned values.
- 2026-10-19 `leakdata.search` changed (title, description, inputSchema, annotations) **meaning changed**
  - before: Use this when the linked LeakData user asks to check their verified primary email. For a current check, call this tool and report only its returned results. Never present earlier conversation results as a new check; if the call fails, say the check could not be completed. For their own email without an address, set type to email and omit query: the server resolves the verified primary email from the linked account. If the user supplies an email address, preserve it in query for ownership validation. Never guess an email address or recover it from earlier conversations when query can be omitted. Domain checks are not available through this app; explain this without calling a tool. Arbitrary third-party identifiers, usernames, phone numbers, raw leak records, and credentials are not returned.
  - after: Use this when the linked LeakData user asks whether their own email was in a data breach ("Has my email been leaked?", "Am I in the Canva breach?", "Am I affected by any recent leaks?"). For a current check, call this tool and report only its returned results; never present earlier results as a new check, and if the call fails say the check could not be completed. For their own email, set type to email and omit query: the server uses the verified primary email of the linked account. If the user typed an address of their own, put it in query; only the verified primary email is checked, and for another address they own the result explains how to add it in LeakData. Never call this for someone else's address or to look up passwords, and never guess an address. No results means no LeakData record matched: never say the email is safe or was never leaked; a breach whose records LeakData does not hold cannot show up. Results for the user's other monitored addresses come from leakdata.protection_summary; company domains use leakdata.company_monitoring.

Full history: https://api.protogrid.dev/v1/servers/io.github.leakdatahq%2Fleakdata-mcp/changes

## Remotes

- https://leakdata.io/mcp (streamable-http, auth none, reachable true, uptime30d 0.9655172)

## Packages

_none_

## Tools (7)

- `leakdata.action_plan`: Use this when the linked LeakData user asks what they should do about their breaches, what is left on their list, or wants to be walked through the steps. Returns the open and done steps of the user's own action plan (for example "Change your password" on a breached site), each with a stepId, the service it applies to, the masked monitored address and whether it is done. Walk the user through open steps one at a time, in the order returned (most urgent first). Report only the returned steps; never invent steps or mark progress yourself. Takes no arguments.
- `leakdata.breach_lookup`: Use this when someone asks whether a company, app or website was hacked or had a data breach, what data leaked, whether a breach notice they received is real, or what to do about a breach they heard of ("Was Canva hacked?", "What leaked in the Ticketmaster breach?"). Searches LeakData's public breach catalog by company, service or domain name and returns each matching breach's date, affected account count, exposed data types, a short summary and the first steps to take. No sign-in is needed. It does not tell whether a particular person's email is in the breach: when emailCheckAvailable is true, offer to check the user's own email with leakdata.search; when it is false, say LeakData cannot check addresses against that breach. When match is "similar", say the name only resembles what the user asked about. No match means the breach is not in LeakData's catalog, not that the company was never breached. If the company is the user's own business or employer, use leakdata.company_monitoring instead. Not for general security news or a person's name.
- `leakdata.company_monitoring`: Use this when someone asks about their own company or employer: whether it had a data breach, whether its domain, staff email addresses or work accounts appear in data breaches, or how to monitor a business domain. Explains what LeakData checks for a domain the company verifies it owns and returns any public catalog breaches listed for exactly that domain with their details. Explain setup using the returned checks and requirements; do not offer plans, prices or sales links. No sign-in is needed. It does not enable monitoring, search employee addresses, or reveal any person's data; never claim it did. Not listed means not in LeakData's catalog, not that the company was never breached.
- `leakdata.mark_step_done`: Use this only after the user says they completed (or want to reopen) a specific step from leakdata.action_plan, for example "I changed my Canva password". Pass that step's stepId from leakdata.action_plan and done=true, or done=false to reopen it; if no action plan result in this conversation contains the step, call leakdata.action_plan first. Saves the change to the user's LeakData action plan; it does not change anything on the breached site. A request to mark all or several steps done is not confirmation: ask which steps the user actually finished and call this once per confirmed step. Never guess a stepId.
- `leakdata.protection_summary`: Use this when the linked LeakData user asks how their monitoring is going, what LeakData has found for them, or whether anything new turned up. Returns the user's own monitored email addresses (masked), when each was last checked, how many findings each has, new findings in the last 30 days, and a count of open action-plan steps. It reports stored monitoring results; for a fresh check of the user's email use leakdata.search, and for the steps themselves use leakdata.action_plan. Takes no arguments. Report only the returned values.
- `leakdata.recent_breaches`: Use this when someone asks which data breaches happened recently or what the latest breaches are. Returns the newest breaches in LeakData's public catalog, newest incident date first, with date, affected account count, exposed data types and first steps. No sign-in is needed. It has no date filter: check the returned dates and say so when none fall in the period the user asked about. It is LeakData's catalog, not every breach worldwide. Not for general security, ransomware or vulnerability news.
- `leakdata.search`: Use this when the linked LeakData user asks whether their own email was in a data breach ("Has my email been leaked?", "Am I in the Canva breach?", "Am I affected by any recent leaks?"). For a current check, call this tool and report only its returned results; never present earlier results as a new check, and if the call fails say the check could not be completed. For their own email, set type to email and omit query: the server uses the verified primary email of the linked account. If the user typed an address of their own, put it in query; only the verified primary email is checked, and for another address they own the result explains how to add it in LeakData. Never call this for someone else's address or to look up passwords, and never guess an address. No results means no LeakData record matched: never say the email is safe or was never leaked; a breach whose records LeakData does not hold cannot show up. Results for the user's other monitored addresses come from leakdata.protection_summary; company domains use leakdata.company_monitoring.