Skip to main content
Glama

dnsdomain

Read-onlyIdempotent

Full DNS + WHOIS/RDAP domain report in one call. Resolves A, AAAA, MX, TXT, NS, CNAME, SOA and DNSSEC over DNS-over-HTTPS, plus structured WHOIS via RDAP (registrar, registration/expiration/updated dates, EPP status, nameservers), and returns a 0-100 domain-hygiene score with letter grade (age, days-to-expiry, nameserver redundancy, MX presence, DNSSEC, SPF/DMARC, registrar lock). Deterministic, Ed25519-signed. 0.001 USDC via x402 on Base. SYNTHORA. First 3 calls FREE per wallet — send header 'X-WALLET: 0x' (no payment); then 0.001 USDC per call. [x402: 0.001 USDC per call on Base]

Input Schema

NameRequiredDescriptionDefault
domainYesDomain, URL or email address to report on

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "domain": "stripe.com"
      +  }
      +]
    • addedInput schema / properties / domain
      Added value: +{
      +  "description": "Domain, URL or email address to report on",
      +  "examples": [
      +    "stripe.com"
      +  ],
      +  "type": "string"
      +}
    • removedInput schema / properties / input
      Removed value: -{
      -  "description": "product parameters (JSON or text). Example: {\"domain\": \"stripe.com\"}",
      -  "type": "string"
      -}
    • addedInput schema / required
      Added value: +[
      +  "domain"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / input / description
      Previous value: -"product parameters (JSON or text). Example: {\"input\": \"{\\\"domain\\\": \\\"stripe.com\\\"}\"}"New value: +"product parameters (JSON or text). Example: {\"domain\": \"stripe.com\"}"
  3. Changed1 schema field changed
    • changedInput schema / properties / input / description
      Previous value: -"product parameters (JSON or text). Example: {\"domain\": \"stripe.com\"}"New value: +"product parameters (JSON or text). Example: {\"input\": \"{\\\"domain\\\": \\\"stripe.com\\\"}\"}"
  4. Added
  5. Removed
  6. Added
  7. Removed
  8. Added

TDQS

A3.6/5.0
Behavior4/5

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

The annotations already declare readOnly, idempotent and non-destructive, and the description goes further by disclosing price (0.001 USDC via x402 on Base), a free tier of three calls per wallet, the X-WALLET auth header, determinism, and Ed25519 signing. This is real behavioral context beyond the structured fields. It falls short of 5 because the interaction between the free tier and the header is ambiguous (is the header needed only while free calls remain?) and the pricing is stated twice in different forms.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The capability and output enumeration is front-loaded and useful, but the pricing model appears twice ('0.001 USDC via x402 on Base' and the bracketed x402 footer) and the bare 'SYNTHORA' branding is noise. Roughly a third of the text is payment repetition rather than decision-relevant content.

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?

With no output schema, the description must explain returns, and it does so well by naming the record types, the RDAP fields (registrar, dates, EPP status, nameservers) and the score components. What is missing is failure behavior — what happens on NXDOMAIN, a domain with no RDAP record, or a rejected wallet/payment — which matters for a network-dependent lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and there is only one parameter, so the schema ('Domain, URL or email address to report on') carries the full semantic load. The description adds no format examples, no normalization rules, and no error guidance for malformed domains, so it earns only the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — a full DNS plus WHOIS/RDAP report for a domain — and even enumerates the exact record types (A, AAAA, MX, TXT, NS, CNAME, SOA, DNSSEC) and hygiene scoring inputs. It is highly specific about what the tool produces. However, it never positions itself against sibling tools such as registry_watch, which an agent may confuse with domain-registry lookups.

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

Usage Guidelines3/5

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

Usage is implied through the capability list: an agent can infer it should call this when it needs DNS records plus registration data for one domain. But there is no explicit when-to-use/when-not, no alternatives named, and no guidance on how it relates to registry_watch or who_gho_indicator_timeseries-style watching tools. The payment/tier text is invocation mechanics, not selection guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources