Who to notify after a data breach and by what date: all US states, SEC, HIPAA, GDPR, UK. Sourced.
Scored across 3 tools
The three tools serve distinct roles: list_breach_laws is a reference lookup, who_to_notify is a computation engine, and list_capabilities is metadata. There is mild thematic overlap between list_breach_laws and who_to_notify since both concern breach laws, but their descriptions make the lookup-vs-compute boundary clear.
list_breach_laws and list_capabilities follow a consistent verb_noun pattern, while who_to_notify uses a question-style name instead. It is readable and the intent is obvious, but it is a minor break from the list_* convention.
Three tools for a focused domain of breach-law reference plus deadline computation is well-scoped and each tool earns its place. It is on the lean side but not thin, since the heavy domain knowledge is packed into who_to_notify's parameters.
The surface covers the core lifecycle: discover coverage (list_capabilities), look up laws (list_breach_laws), and resolve owed notices with deadlines (who_to_notify). Minor gaps like retrieving a single law's full detail exist, but the list tool and official sources largely compensate.
Lists breach notification laws with who is covered, which data types trigger them, encryption exemptions, every notice with its deadline rule and threshold, penalties and the official source. Filter by US state, country (ISO code or name) or scope (us_state, us_federal_sector, country, region). Free.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Optional: us_state, us_federal_sector, country or region. | |
| state | No | Optional US state code or name. | |
| country | No | Optional country code or name, for example "GB", "Germany", "Canada". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Lists' and 'Free' implicitly convey a read-only, no-cost lookup, and the enumeration of returned fields adds real transparency. It still omits auth/permission requirements, pagination, result-size behavior, and rate limits, so it does not fully close the annotation gap.
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?
A single dense sentence, front-loaded with the core action and then the content and filter options, followed by a short 'Free.' tag. Every clause carries information; it is long but not padded.
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 no output schema and no annotations, the description compensates by enumerating the returned record fields (deadlines, thresholds, penalties, source), which is exactly the missing return-shape information. Gaps remain around pagination and how the three filters interact when combined.
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% and the schema already documents all three optional filters, so the baseline is 3. The description restates the scope values and adds 'ISO code or name' context, but the schema's own example ('GB', 'Germany', 'Canada') already covers that ground, so there is little net addition.
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 states a specific verb and resource ('Lists breach notification laws') and then enumerates exactly what each entry contains: coverage, triggering data types, encryption exemptions, notice deadlines/thresholds, penalties, and source. That is far more informative than a bare name restatement. It doesn't explicitly distinguish itself from siblings like who_to_notify, so it stops short of a 5.
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?
Filtering guidance ('Filter by US state, country... or scope') implies the retrieval contexts the tool serves, and 'Free' hints at a cost consideration. However, there is no explicit when-to-use versus when-not, and no routing to who_to_notify or list_capabilities for adjacent questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists coverage (US states, US federal sector rules, countries), the date the data was last checked, and related Nero Labs Rules servers. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the return content (coverage areas, last-checked date, related servers) and that the call is free, which is real behavioral context. It does not mention authentication, rate limits, or freshness semantics beyond the date field.
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?
A single front-loaded sentence with no filler; every clause contributes either scope or cost information.
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?
Although there is no output schema, the description summarizes the return payload (coverage list, last-checked date, related servers), which is sufficient for a zero-parameter discovery tool. Minor gaps remain around auth or freshness semantics, but nothing essential 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?
The tool takes zero parameters, so the schema imposes no semantic burden and the baseline of 4 applies. The description correctly implies a no-argument listing call.
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 ('Lists') and resource ('coverage'), then enumerates exactly what is covered (US states, US federal sector rules, countries), the last-checked date, and related servers. It is clear and specific, though it does not explicitly distinguish itself from the sibling list_breach_laws, which is also a list-style tool.
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?
Usage is only implied: an agent can infer this is a discovery/first-call tool to learn what data is available, and 'Free' hints at a cost consideration. But there is no explicit when-to-use, when-not-to-use, or reference to the sibling tools list_breach_laws or who_to_notify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out every data breach notice a company owes and the deadline for each. Give affected (how many people in each US state or country), the data types exposed (for example ssn, drivers_license, payment_card, financial_account, medical, health_insurance, username_password, biometric, passport, dob, email_address), whether the data was encrypted with the key kept safe, the date the breach was discovered, and flags: sec_registrant (US public company), sector (hipaa_covered_entity, hipaa_business_associate, glba_financial, health_app, nydfs_licensee) and role (owner, or service_provider holding data for another company). Returns each notice owed (people affected, state attorneys general, credit bureaus, HHS, SEC Form 8-K, FTC, EU and UK data protection authorities, Canada, Australia) with the deadline as a date where the law sets a fixed period, the deadline rule in words, what the notice must contain, how to send it and the official source, earliest first. Unclear cases give the SAFE answer (notice treated as required) plus what it depends on. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | owner (default): the company that owns or licenses the data. service_provider: holds it for another company, which mostly means notifying that company quickly. | |
| sector | No | Sector rules that apply: hipaa_covered_entity, hipaa_business_associate, glba_financial (non-bank financial firms under the FTC Safeguards Rule), health_app (FTC Health Breach Notification Rule), nydfs_licensee (New York DFS regulated). | |
| affected | Yes | Where the affected people live: [{"state":"CA","count":1200},{"state":"TX","count":300},{"country":"Germany","count":40},{"country":"United Kingdom","count":15},{"country":"Canada","province":"Quebec","count":5}]. A bare two-letter code is read as a US state (CA = California); use {"country":"CA"} or "Canada" for Canada. | |
| encrypted | No | True only if all the exposed data was encrypted and the key was not exposed. Many US state laws then need no notice. Default false. | |
| data_types | No | Personal data exposed, for example ["ssn","drivers_license","payment_card"]. If left out every law is treated as triggered (SAFE). | |
| sec_registrant | No | True for a company that files reports with the US SEC (listed in the US). Adds Form 8-K Item 1.05. | |
| date_discovered | No | Date the breach was discovered (or you became aware of it), YYYY-MM-DD. Defaults to today. Deadlines are counted from it. | |
| materiality_date | No | SEC registrants: date the company decided the incident is material, YYYY-MM-DD. The 8-K is due 4 business days after it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses defaults ('encrypted' false, discovery date defaults to today, omitting data_types treats all laws as triggered), the failure mode for ambiguity ('Unclear cases give the SAFE answer ... plus what it depends on'), result ordering (earliest first), and cost/auth ('Free'). This is substantive behavioral context beyond the schema.
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 the purpose, then the required inputs, then the return shape and the safe-answer rule — a logical order with no filler sentences. It runs long and duplicates several parameter lists already in the schema, which is the only waste.
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, no output schema and no annotations, the description must explain returns and does: each notice owed, the deadline date or rule-in-words, required contents, delivery method, and official source, plus ordering. Nothing essential for correct invocation 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?
Schema description coverage is 100%, so every parameter is already documented in the schema; the description largely restates those same semantics (affected shapes, data_types examples, encrypted, date_discovered, sector/role flags). It adds little parameter meaning the schema does not already supply, so the 3 baseline applies.
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 computation and its output: 'Works out every data breach notice a company owes and the deadline for each,' then enumerates the notice classes (state AGs, credit bureaus, HHS, SEC 8-K, FTC, EU/UK DPAs, Canada, Australia). This is unmistakably a computation-over-inputs tool, clearly distinct from a jurisdiction lookup like list_breach_laws.
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 implies the usage context by listing the facts to supply (affected counts, data types, encryption, discovery date, registrant/sector/role flags), but never states when to reach for this tool rather than list_breach_laws, nor any when-not condition. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_breach_lawslist_capabilitieswho_to_notifyIncident-reporting deadlines from the law: CRA, NIS2, DORA, GDPR, HIPAA, SEC 8-K. 6 of 9 tools free.
Bulk breach notice deadline checks: US states, SEC, HIPAA, GDPR, UK, per check billing via Apify.
Indian cyber regulation register and incident-reporting deadlines (India, US, EU), read at source.
GDPR DSAR deadlines, breach triage, AI tool checks, HR retention and letters (UK/EU/CH)
Add one secure layer between your agents and this server.