Have I Been Pwned

Have I Been Pwned - Data Classes

hibp_list_data_classes

Read-onlyIdempotent

List the data classes used across public HIBP breach models, such as email addresses or passwords.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`response_format`	No	Format only the text content as markdown (default) or a JSON string. The same machine-readable data is always returned in structuredContent.	markdown

Output Schema

TableJSON Schema

Name	Required	Description
`message`	No	Present when the tool returns an error.
`guidance`	No	Additional guidance for resolving the tool error.
`statusCode`	No	Present when the tool returns an error.
`dataClasses`	No
`rateLimitResetAt`	No	UTC timestamp indicating when the current rate limit window should have reset.
`retryAfterHeaders`	No	Retry headers that mirror the standard HTTP rate-limit response when applicable.
`retryAfterSeconds`	No	How long to wait before retrying, when the tool is rate limited.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed3 schema fields changedAug 27, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedInput schema / properties / response_format / description

Previous value: -"Format the text response as markdown (default) or JSON. structuredContent is always returned."New value: +"Format only the text content as markdown (default) or a JSON string. The same machine-readable data is always returned in structuredContent."

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedJul 23, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the resource scope (public HIBP models) and example classes, but no additional behavioral details such as rate limits, pagination, or output nuances. This is consistent with annotations and meets the baseline for a read-only list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with zero waste. It immediately states the action and subject, then gives illustrative examples. No unnecessary words or redundant restatements of the title.

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?

Given the low complexity (one optional param, output schema present, strong annotations), the description is fully sufficient. It communicates what the tool does, and the schema and output schema cover the remaining details like format options and return structure. Nothing an agent needs to invoke it correctly is missing.

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

Parameters3/5

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

The single parameter (response_format) is fully documented in the input schema with an enum, default, and description. The tool description adds no parameter-specific guidance beyond what the schema already provides, so the baseline of 3 applies given 100% schema coverage.

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

Purpose5/5

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

The description states a specific verb ('List') and a precise resource ('data classes used across public HIBP breach models'), and gives concrete examples ('email addresses or passwords'). This clearly distinguishes it from all sibling tools, which focus on specific breaches, accounts, or domains.

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?

The description clearly conveys the tool's scope and purpose ('data classes across public HIBP breach models'). While it does not explicitly name alternatives or state when *not* to use it, the unique focus on data classes makes the usage context obvious among the siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Have I Been Pwned tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a unique combination of resource and action (e.g., list_breaches vs. get_latest_breach vs. get_breach; get_stealer_logs_by_email vs. by_email_domain vs. by_website_domain). Even similar tools like get_breached_account and get_breached_account_range are clearly differentiated by method (email vs. hash prefix) and access requirements. No two tools appear to do the same thing.

Naming Consistency5/5

All tools follow the `hibp_<verb>_<object>` pattern with snake_case, consistently using verbs like get, list, send, verify, generate. The stealer logs tools extend this with `_by_<identifier>` suffixes, maintaining uniformity. No mixing of camelCase or irregular verb styles.

Tool Count4/5

17 tools is slightly above the typical 3-15 range but appropriate given the breadth of HIBP's API (breaches, pastes, passwords, stealer logs, subscription management, domain verification). Each tool maps to a distinct endpoint or workflow, and none feel redundant. The count is justified, though it leans toward the heavier side.

Completeness5/5

The tool set covers all major HIBP features: breach lookup (by name, list, latest), account breaches (email and range), pastes, pwned passwords, stealer logs (by email, email domain, website domain), subscription status, subscribed domains, data classes, and a full domain verification lifecycle (generate, send, verify). There are no obvious dead ends or missing core operations for the domain.

Resources

Need Help?