Skip to main content
Glama

Find State Breach Notices

breach_notices
Read-onlyIdempotent

Search the Washington, Delaware or California Attorney General breach-notice list by public notifying-organisation name and year (notice year for Washington and Delaware, reported year for California). Timing uses only the dates in each record: Washington and Delaware results label whether the interval is beyond that state's statutory window by the record's dates. The records do not show permitted delays, including law-enforcement requests, or any enforcement outcome; the timing flag is no legal finding. Never call a notice "late" or say an organisation "violated" the law. California has no discovery date, so no timing is computed. Resident counts are notices sent to residents, not unique people, and are never added across states; Delaware also reports the company's stated total affected separately. A notifying organisation may differ from the breached one. Names that may identify individuals are withheld, never returned or searchable. Absence from these three lists is no evidence that an organisation had no breach.

Input Schema

NameRequiredDescriptionDefault
yearNoOptional year of the state record date: WA/DE notice date or CA reported date.
limitNoMaximum notice rows returned, allowed 1-100.
stateYesRequired Attorney General notice list: WA, DE or CA.
organizationNoOptional case-insensitive public organization name substring, at most 80 characters; withheld names are never searched.
beyond_windowNoWA or DE only: beyond the statutory window by the record dates; the records do not show permitted delays.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only/idempotent/non-destructive, and the description adds substantial context beyond them: records omit permitted delays such as law-enforcement requests and omit enforcement outcomes, the timing flag is not a legal finding, and California has no discovery date so no timing is computed. It also discloses data-handling rules — withheld individual-identifying names are never returned or searchable.

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?

Purpose is front-loaded in the first sentence, followed by interpretation constraints. The caveat block is dense and long, but nearly every sentence carries semantic or legal-interpretation weight rather than filler.

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?

With no output schema, the description takes on return-value explanation itself — what the timing labels mean, that resident counts are notices sent rather than unique people and are never summed across states, and that Delaware also reports the company's stated total. That leaves little an agent needs to interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the year parameter maps to notice year for WA/DE versus reported year for CA, and beyond_window is scoped to WA/DE and framed as a date-interval label rather than a legal conclusion. It also explains that the notifying organisation may differ from the breached one, which changes how the organization filter should be used.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — searching the WA, DE, or CA AG breach-notice lists — plus its filtering dimensions (organisation name, year). It is concrete enough to separate from the sibling breach_notice_organization, but it never names or contrasts with that sibling explicitly, so it falls short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear usage context: filtering is by public notifying-organisation name and year, with the year meaning differing per state, and it warns that absence from these three lists is not evidence of no breach. It does not state explicit exclusions or point to alternatives such as the per-organisation sibling tool.

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