Skip to main content
Glama
Sign In
Whoisfreaks

Whoisfreaks

by WhoisFreaks
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

DNS history

dnsHistory
Read-onlyIdempotent

Retrieve historical DNS records for a domain to track past A, MX, NS, and other record changes over time, supporting investigations, migrations, and origin IP or mail server research.

Instructions

Get the historical DNS records of a domain, showing how its A, MX, NS and other records changed over time. Use this for investigations and migrations: earlier hosting IPs (for example the origin IP behind a CDN), past mail servers, or name server changes. For the current records only use dnsLookup. For ownership changes use whoisHistory. Costs 2 credits per page. Returns past records with the dates they were observed. Results are paginated: raise page to get more, and filter by type to reduce output. 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": {
      "domainName": "<domainName>"
    },
    "name": "dnsHistory"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage number for paginated results. Default: 1
typeNoRecord types to return: 'all' (the default), one type such as A, or a comma-separated list such as a,mx,ns. Supported: A, AAAA, MX, NS, CNAME, SOA, TXT.
formatNoResponse format. Default: json
domainNameYesDomain name to retrieve historical DNS records for. Example: whoisfreaks.com

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.1.0
    • addedInput schema / properties / page / minimum
      Added value: +1
    • changedInput schema / properties / type / description
      Previous value: -"DNS record type to retrieve history for. Default: all"New value: +"Record types to return: 'all' (the default), one type such as A, or a comma-separated list such as a,mx,ns. Supported: A, AAAA, MX, NS, CNAME, SOA, TXT."
    • removedInput schema / properties / type / enum
      Removed value: -[
-  "A",
-  "AAAA",
-  "MX",
-  "NS",
-  "CNAME",
-  "SOA",
-  "TXT",
-  "SPF",
-  "all"
-]
  2. First observedv1.0.2

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive, openWorld), the description discloses cost (2 credits per page), credential source (WHOISFREAKS_API_KEY or hosted key), credit consumption on the account, and the failure surface with concrete HTTP codes 401/403/404/429. The one redundant sentence restating read-only behavior does not detract from otherwise unusually rich disclosure.

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 and sibling routing are front-loaded, then cost, then error modes — a sensible information hierarchy. The closing behavior paragraph is somewhat long and partially repeats what the annotations already assert (read-only, nothing changed), which is the only waste.

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?

For a read tool with no output schema, the definition covers what comes back ('past records with the dates they were observed'), pagination, cost, auth requirements, and error outcomes — enough for an agent to call it and interpret a failure without guessing.

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 earns extra by explaining the operational intent of two parameters — raise 'page' to get more results, narrow 'type' to reduce output — which the schema documents syntactically but not as a strategy.

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 ('Get the historical DNS records of a domain') plus the record families covered (A, MX, NS and others), which is exactly what distinguishes it from the live-record sibling dnsLookup and the ownership sibling whoisHistory.

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 (origin IP behind a CDN, past mail servers, name server changes) and explicitly routes elsewhere: 'For the current records only use dnsLookup. For ownership changes use whoisHistory.' When-to-use and when-not-to-use are both stated.

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

Deploy Server

Other Tools