LeakData

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.

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.

Takes no parameters.

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.

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.

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.

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.

Takes no parameters.

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.