Skip to main content
Glama

Server Details

Live DNS lookups for agents: A/MX/TXT/SPF/CNAME/PTR with TTLs and DNSSEC, via Google Public DNS.

Ownership verified
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

Available Tools

1 tool
resolve_dnsResolve DnsA
Read-onlyIdempotent
Inspect

Resolve any DNS record live via Google Public DNS. Answers: is DNS propagated? What are the MX/TXT/SPF/DKIM records? Where does this CNAME point? For reverse lookup pass name=.in-addr.arpa with type=PTR (e.g. 90.57.149.3.in-addr.arpa for 3.149.57.90). Returns Status (0 = NOERROR, 3 = NXDOMAIN), Answer records with TTLs, and the AD flag for DNSSEC validation.

ParametersJSON Schema
NameRequiredDescriptionDefault
doNoSet 'true' to include DNSSEC records (RRSIG) in the response
nameYesDomain name to resolve, e.g. 'kaiv.ai' (or reversed IP + .in-addr.arpa for PTR)
typeNoRecord type: A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, PTR, SRV. Default A.A

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive hints. The description adds valuable behavioral details such as the Status codes (NOERROR vs NXDOMAIN), the inclusion of Answer records with TTLs, and the AD flag for DNSSEC, which are not in the annotations. This enriches the agent's understanding of output and behavior.

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

Conciseness5/5

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

The description is front-loaded with the core purpose and use cases, followed by a concrete reverse-lookup example. Every sentence earns its place—no repetition, no fluff, and it is compact for the info it delivers.

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?

With no output schema, the description explicitly explains the response structure (Status, Answer with TTLs, AD flag). It also covers all three parameters, including the 'do' option for DNSSEC. The tool is well-specified for an agent to call correctly without missing information.

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%, with each parameter already documented. The description adds an example for PTR (reversed IP) but does not significantly expand on parameter meanings beyond what the schema provides. Baseline 3 applies because the schema already carries the semantics.

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?

The description starts with a specific verb ('Resolve') and resource ('any DNS record') and immediately clarifies the purpose via concrete use cases ('is DNS propagated?', MX/TXT/SPF/DKIM records, CNAME target). It leaves no ambiguity about what the tool does and is well-distinguished from any potential alternatives.

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

Usage Guidelines4/5

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

It clearly states when to use the tool with examples and gives specific instruction for reverse lookup (PTR with reversed IP). However, it does not explicitly mention when not to use it or any alternative tools, though none are listed as siblings. The context is strong enough to guide typical usage.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool update
    • Changedresolve_dns2 fields changed
      • addedInput schema / properties / type / default
        Added value: +"A"
      • addedInput schema / properties / type / enum
        Added value: +[
        +  "A",
        +  "AAAA",
        +  "MX",
        +  "TXT",
        +  "NS",
        +  "CNAME",
        +  "SOA",
        +  "CAA",
        +  "PTR",
        +  "SRV"
        +]
  2. 1 tool update
    • First observedresolve_dns

Frequently Asked Questions

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to perform pay-per-call DNS record lookups (A, AAAA, MX, TXT, CNAME, NS, SOA, SRV) via Cloudflare DNS-over-HTTPS, with x402 micropayments and no API key or signup.
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables DNS record lookups for types like A, MX, TXT, and CNAME, bulk queries of all major record types, and reverse DNS resolution from IP addresses to hostnames.
    5
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    A comprehensive DNS query server that enables querying all types of DNS records, including A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, CAA, and DNSSEC checks, as well as advanced tools like WHOIS-style lookup and DNS delegation tracing.
    1
    -
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap. The tool's purpose is singular and clearly defined, making misselection impossible.

Naming Consistency5/5

A single tool name follows no conflicting pattern, so consistency is trivially maintained. The verb_noun style ('resolve_dns') is clear and descriptive, aligning with best practices.

Tool Count3/5

At one tool, the server feels minimal and may lack depth for more complex DNS workflows. While the single tool is well-scoped, the count is at the borderline of what feels too thin for a full-featured server.

Completeness4/5

The tool covers the core DNS resolution domain comprehensively—any record type, reverse lookups, and DNSSEC status. It omits peripheral features like batch lookups or multi-server comparison, but for its stated purpose it is essentially complete.

Resources