MCP Server

The corpus, as tools your AI agent can call. Ask Claude what a hash is and it looks it up here — no copying digests between a chat window and a web form.

6,395,497,688 entries per algorithm · md5 · sha-1 · sha-256 · ntlm

https://mcp.redhacker.ai/mcp

Tools

Try these

What password produces the MD5 hash 5f4dcc3b5aa765d61d8327deb882cf99?

Here's a hash I pulled off a box: $2y$10$N9qo8uLOickgx2ZMRZoMye
What type is it, and can it be cracked with a lookup?

Check whether the NTLM hash 8846f7eaee8fb117ad06bdd830b7586c appears in
any public breach corpus — but do it without sending the hash anywhere.

I have these four NTLM hashes from an AD audit. Which are known passwords,
and how big is the corpus you checked them against?

What it will not do

This service maps a hash to a plaintext that appears in a public corpus. It does not accept an identity — an email address, a username, a phone number — and return a credential for it. That is a different product with a different legal posture.

The rule is enforced in code, not promised in prose: every parameter that accepts input is checked, and identity-shaped input is refused with an explanation rather than quietly attempted. Ask the connector to look up an email address and it will tell you why it cannot.

Limits

Exceeding one returns 429 with a Retry-After header; well-behaved clients back off on their own. Limits are counted per connection rather than per IP address on purpose — requests from Claude all arrive from the same egress addresses, so a per-IP limit would put every user of this connector into one bucket and let a single heavy user starve everyone else.

For bulk work — thousands of hashes from an NTDS extract — the batch API is the right tool, not a chat window.

Who operates this

redhacker.ai is operated by Red Hacker Ai, Inc., a corporation registered in Florida, United States — a matter of public record, searchable by name on the Florida Division of Corporations registry. The service runs on hardware the company owns, with Cloudflare in front as CDN and WAF. Questions, abuse reports and security contact: [email protected].

The service was given an independent third-party security assessment by Chad Cybersecurity Consulting Inc. on 21 August 2026, carried out after this MCP connector was deployed — so the connector, its rate limiting and its tool surface were within its scope. We name the assessing firm and the date rather than simply claiming an audit, so you can weigh both yourself.

The server code is public at github.com/secopssite/redhacker.ai, which is the part you can verify without taking anyone's word for it.

Where the corpus comes from

The index is built from published password wordlists — bare strings, one per line. The catalogue of candidate sources, with a download URL and a measured crack rate for each, is versioned in the public repository as tools/sources.tsv, so you can read exactly what the pool is drawn from rather than take a description of it on trust.

None of these are credential dumps. Every source is a password list; not one of them pairs a password with an email address, a username or an account. That is why this service cannot look up a person — there is no identity in the data to look up. The tools reject an email address or phone number outright rather than searching for it.

Words are merged and deduplicated into one file with a fixed set of rules:

• Carriage returns stripped, blank lines dropped.
• Lines longer than 64 characters dropped — real passwords are shorter, and long junk costs index entries for nothing.
• Deduplicated, since the source lists overlap enormously.
• Case is never folded. Passwords are case-sensitive, so lowercasing would destroy candidates and quietly reduce the hit rate.

One honest limit on this. The merge that produced the current index was run before the build tooling recorded its inputs, so while the sourcing policy and cleaning rules above are exactly what was applied, the specific subset of sources.tsv that went into this index is not individually attested. The next rebuild writes a provenance record alongside the corpus, and it will be published here. Until then, treat the composition as the policy described above rather than as a verified bill of materials.

Privacy

• No account, so nothing is tied to an identity. There is no sign-up, no key and no profile.
• Hashes are not logged. A digest passes through memory to answer the request and is not written down.
• Requests are logged for 30 days. Source IP, timestamp and the endpoint called — standard web server logs, kept 30 days and then discarded. So the hash is not recorded, but the fact that you made a query is, along with the address you made it from.
• Nothing is shared with anyone. No third parties, no analytics on this hostname, no advertising.
• Prefer check_hash_prefix when the hash is not yours. It is the only mode where the property is structural rather than a promise — we cannot disclose what we were never sent. It hides which hash you checked, not that you checked one: the request still carries your IP, the time and the 6-character bucket. Where the query itself is sensitive, crack locally.

Full detail on the privacy page.

Caveats worth carrying into a report

A bucket match confirms a prefix, not a digest. check_hash_prefix compares the stored 8-byte prefix, not the full hash. The odds of a collision are roughly 3 in 10 billion — a strong indicator, not proof.

Not found is not the same as strong. It means the password is absent from this corpus. Say which corpus, and how large it was.