Lists all data classes of compromised data known to HaveIBeenPwned, helping identify what information types are exposed in breaches. No API key required.
List all data classes (types of compromised data) known to HaveIBeenPwned. Free endpoint, no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds a genuinely new behavioral fact not in the annotations: no API key is required and the endpoint is free, which affects auth handling. It does not describe response shape, but for a no-param list endpoint that gap is minor.
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?
Two short sentences, zero waste, with the what (list data classes) front-loaded and the access note second. Appropriately sized for a trivial lookup endpoint.
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?
For a no-parameter, read-only enumeration endpoint with annotations covering safety and no output schema, the description covers purpose and access requirements. Adding a hint that these classes are the valid values used to filter breach searches would make it fully self-sufficient, but nothing essential is absent.
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 baseline is 4 and there is no parameter surface for the description to clarify. Nothing is missing or contradicting on this dimension.
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 and resource ('List all data classes') and immediately defines the resource for an agent that may not know the term ('types of compromised data known to HaveIBeenPwned'). This is clearly distinguishable from sibling breach tools like breachList and breachSearch, which return breach records rather than the class taxonomy.
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 a useful access hint ('Free endpoint, no API key required') but never states when to reach for this tool versus breachList, breachSearch, or breachPastes. Usage is only implied — an agent must infer that this supplies the vocabulary for filtering other breach queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.