Whoisfreaks

Overview Schema Source Related Servers Discussions Admin

Reverse DNS search

reverseDnsLookup

Read-onlyIdempotent

Find domains whose DNS records point to an IP, range, mail server, name server, or other value to reveal shared hosting and map infrastructure.

Instructions

Find domains whose DNS records point to a given value: an IP address or range, mail server, name server or other record value. Use this to see which other sites share a hosting IP, which domains use a mail server or name server, or to map infrastructure during an investigation. Set type to match the value: a for an IPv4 address or range (default), aaaa for IPv6, mx for a mail server, ns for a name server. For a domain's own records use dnsLookup. For the registered owner of an IP block use ipWhoisLookup. exact=false (the default) enables '*' wildcard matching, for example *.cloudflare.com. sort=desc with sortBy=lastSeen puts the most recently seen domains first. Costs 5 credits per page of up to 100 domains. Popular IPs and name servers can match millions of domains, so use page and stop once you have enough. 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

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "value": "<value>"
    },
    "name": "reverseDnsLookup"
  }
}

Input Schema

Name	Required	Description
`page`	No	Page number for paginated results. Default: 1
`sort`	No	Sort the results by sortBy, ascending or descending. Omit for unsorted results.
`type`	No	One DNS record type to search within. Default: a
`exact`	No	false (the default): the value is matched as a pattern, where '*' matches any characters. true: exact match. Ignored for A and AAAA, which always match the IP or range.
`value`	Yes	The value to search for in DNS records: an IP address or CIDR range for A/AAAA (8.8.8.8 \| 104.16.0.0/16), a host name for MX, NS or CNAME (mail.example.com), or text for TXT and SOA. With exact=false, '*' matches any characters.
`format`	No	Response format. Default: json
`sortBy`	No	Date that sort orders by. Only used together with sort. Default: lastSeen

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv2.1.0Nov 13, 2026

changedInput schema / properties / exact / description

Previous value: -"true = exact value match (default). false = allow wildcard/pattern matching with '*'."New value: +"false (the default): the value is matched as a pattern, where '*' matches any characters. true: exact match. Ignored for A and AAAA, which always match the IP or range."

addedInput schema / properties / page / minimum
```
Added value: +1
```

addedInput schema / properties / sort

Added value: +{
+  "description": "Sort the results by sortBy, ascending or descending. Omit for unsorted results.",
+  "enum": [
+    "asc",
+    "desc"
+  ],
+  "type": "string"
+}

addedInput schema / properties / sortBy

Added value: +{
+  "description": "Date that sort orders by. Only used together with sort. Default: lastSeen",
+  "enum": [
+    "firstSeen",
+    "lastSeen"
+  ],
+  "type": "string"
+}

changedInput schema / properties / type / description

Previous value: -"DNS record type to search within. Default: A"New value: +"One DNS record type to search within. Default: a"

changedInput schema / properties / type / enum

Previous value: -[
-  "A",
-  "AAAA",
-  "MX",
-  "NS",
-  "CNAME",
-  "SOA",
-  "TXT"
-]New value: +[
+  "a",
+  "aaaa",
+  "mx",
+  "ns",
+  "cname",
+  "txt",
+  "soa"
+]

changedInput schema / properties / value / description

Previous value: -"The value to search for in DNS records. For A records: an IP address (8.8.8.8). For MX/NS: a hostname (mail.example.com). Supports wildcard '*' when exact=false."New value: +"The value to search for in DNS records: an IP address or CIDR range for A/AAAA (8.8.8.8 | 104.16.0.0/16), a host name for MX, NS or CNAME (mail.example.com), or text for TXT and SOA. With exact=false, '*' matches any characters."

First observedv1.0.2Nov 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent, and the description goes well past them: one request per call to the WhoisFreaks API, credentials resolution via WHOISFREAKS_API_KEY or the request-supplied key, credit consumption (5 per page of up to 100), and the failure surface with concrete HTTP codes (401/403/404/429) returning a message rather than data. This is exactly the kind of cost, auth, and failure behavior an agent cannot infer from structured fields.

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?

Front-loaded with purpose, then usage, then type mapping, then pagination/cost, then the behavior block — a sensible information hierarchy with no filler sentences. The enumerated HTTP failure codes are slightly list-heavy, but each maps to a distinct recovery decision, so the length is mostly earned.

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?

No output schema exists, and the description compensates by stating the result unit ('5 credits per page of up to 100 domains') and warning that popular IPs and name servers can match millions of domains, which shapes paging strategy. Together with credential and error behavior, nothing an agent needs in order to call this correctly is missing.

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 the baseline is 3; the description still adds value by tying type to value shape ('a for an IPv4 address or range,' 'mx for a mail server') and by giving a concrete wildcard example ('*.cloudflare.com') plus the working 'sort=desc with sortBy=lastSeen' combination. It does not cover cname/txt/soa or format in prose, leaving that 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?

Opens with a specific verb and resource: 'Find domains whose DNS records point to a given value,' and enumerates the value kinds (IP/range, mail server, name server, other record value). It explicitly distinguishes itself from dnsLookup and ipWhoisLookup, so an agent can route between them without opening another 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 concrete use cases ('see which other sites share a hosting IP,' 'which domains use a mail server or name server,' 'map infrastructure during an investigation') plus explicit alternatives: dnsLookup for a domain's own records, ipWhoisLookup for IP block ownership. It also states when to stop paging ('use page and stop once you have enough'), which is real invocation guidance.

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