Skip to main content
Glama
Sign In

WhoisFreaks

by io.github.WhoisFreaks
OverviewDiscussionsAdmin

Reverse WHOIS search

reverseWhoisLookup
Read-onlyIdempotent

Find domains whose WHOIS records contain a given email, registrant name or company, or whose name contains a keyword, across 4.6 billion WHOIS records. Use this to map everything a person or organisation has registered, for example when investigating a phishing actor or auditing a company's domain portfolio. Provide exactly one of email, owner, company or keyword. To look up the owner of one known domain use liveWhoisLookup. To find look-alike domains of a brand (typosquats) use domainDiscovery. mode=mini returns a short summary per domain and 100 domains per page, against 50 full records per page in the default mode. Costs 5 credits per page, so prefer mini when you only need the list of domains. Results are paginated: the response gives the total pages, and page selects the next one. Behavior: read-only. Makes one request to the WhoisFreaks API using your WhoisFreaks API key (the WHOISFREAKS_API_KEY environment variable, or on the hosted server the key sent with the request) and uses that account's API credits; nothing is created or changed. If the call fails, the result is a short message instead of data, for example: key invalid, or plan or credits used up (HTTP 401), domain extension not supported (HTTP 403), no data found (HTTP 404), or rate limit reached (HTTP 429).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "reverseWhoisLookup"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNo'default' (the default) returns the full WHOIS record of each domain, 50 per page. 'mini' returns only the domain name, creation/update/expiry dates and the registrant's name, email and company, 100 per page.
pageNoPage number for paginated results. Default: 1
emailNoSearch by registrant email address, exact or regex match. Example: admin@example.com
exactNofalse (the default): keyword matches every domain that contains it, and owner and company match as a phrase. true: match the value exactly.
ownerNoSearch by registrant/owner name, matched as a phrase unless exact=true. Example: John Doe
formatNoResponse format. Default: json
companyNoSearch by company/organization name, matched as a phrase unless exact=true. Example: Alphabet Inc
keywordNoSearch by text in the domain name. With exact=false (the default) it matches every domain whose name contains it. Example: google

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover read-only and open-world, yet the description still adds real context: it states the API key source (WHOISFREAKS_API_KEY or hosted key), that the account's credits are consumed, the 5-credits-per-page cost, and the concrete failure modes with HTTP codes (401 key/credits, 403 extension, 404 no data, 429 rate limit). The only gap is that it doesn't state how 'no match' differs from a 404 error, an edge case an agent reconciling empty results would want.

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, then routing alternatives, then mechanics and errors in a sensible order. It is dense and mostly earns its length, but the parenthetical about the hosted server's key and the inventory of HTTP codes could be trimmed to the two or three an agent can act on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter, paginated, credit-metered search with no output schema, the description supplies cost model, page-size differences, error surface, and pagination behavior — enough to call it safely. What it lacks is any statement of the concrete response shape (field names returned per domain) and the default result behavior when multiple filter params are combined.

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 baseline is 3, but the description adds meaning not encoded structurally: the mutual-exclusivity/non-empty requirement across email, owner, company and keyword is absent from the schema (0 required params, no oneOf), and the per-page cost plus result volume differences are called out. It also implies page/total-page interaction, though it leaves 'exact' semantics entirely to the schema.

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?

States a specific verb and resource ('Find domains whose WHOIS records contain a given email, registrant name or company...') plus scale (4.6 billion records), and explicitly distinguishes itself from two named siblings (liveWhoisLookup for one known domain, domainDiscovery for typosquats). An agent can route correctly without opening any schema.

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

Usage Guidelines5/5

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

Gives task-level use cases (phishing investigation, portfolio audit), a hard input constraint ('Provide exactly one of email, owner, company or keyword'), and names the alternatives with the conditions that select them. It even advises mode=mini when only the domain list is needed, which is a genuine usage decision.

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

All WhoisFreaks toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources