Loading ToolBench
MCP server for checking passwords and email accounts against the Have I Been Pwned breach database. Supports k-anonymity password checks, breach catalog queries, and account breach lookups.
Server has 6 well-named tools with clear, detailed descriptions (avg 180 chars, well above 10-char minimum). All tools have explicit input schemas with typed properties and required arrays. However, output schemas are completely undocumented, LLMs cannot plan downstream calls or extract fields. Parameter descriptions are strong (e.g., 'Password to check (stays inside the worker)'), but no error handling guidance, no pagination support for list_breaches, and no per-parameter constraints (enums, ranges). Security is well-handled (k-anonymity, no secrets in params), but composition could be tighter, check_account requires external API key injection not shown in tool definition.
Look up breaches an email account has been seen in. REQUIRES a paid HIBP subscription key (pass _apiKey). Returns the set of breach names; combine with get_breach for details.
Check whether a password appears in known breach corpora. Uses k-anonymity: the password is SHA-1ed locally, only the first 5 hex chars leave the worker, and the response is filtered to match the rest. Returns pwned count (0 = not seen). The password itself is never transmitted.
Direct k-anonymity lookup: pass the first 5 hex chars of a SHA-1 password hash, get back all SHA-1 suffixes with their pwned counts. Use this if you're hashing client-side and only want to send the prefix.
Fetch a single breach by name (the "Name" field from list_breaches, e.g., "Adobe", "LinkedIn"). Returns full breach metadata.
List all publicly-known data breaches catalogued by HIBP. Optionally filter to a specific domain (e.g., "linkedin.com"). Returns name, title, breach date, added date, affected accounts, description, data classes exposed, and verification status.
Output schemas completely undocumented. LLMs cannot infer what fields to expect from list_breaches, get_breach, list_data_classes, or check_account responses. This blocks downstream tool chaining and forces agents to guess field names.
list_breaches lacks pagination support (no limit, offset, or page parameters). HIBP may return hundreds of breaches; returning all at once wastes tokens and risks context window exhaustion. No total count or next_cursor documented.
check_password_prefix parameter 'sha1_prefix' lacks format constraint. Description says '5 hexadecimal characters' but no regex pattern or length validation in schema. LLMs may pass invalid values like 'ABCDE' (uppercase) or '12345' (5 digits, not hex).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Canonical list of HIBP "data class" tags (e.g., "Email addresses", "Passwords", "Geographic locations"). Useful for filtering breaches.
check_account requires '_apiKey' injection but this is not documented in the tool definition. The description mentions 'pass _apiKey' but no parameter named '_apiKey' appears in inputSchema. This breaks the tool contract and confuses LLMs about how to provide credentials.
No error handling guidance. Tools do not document what happens on API failures (rate limits, invalid input, network errors), what the LLM should do next, or whether errors are retryable. Agents will not know whether to retry or ask the user.