Skip to main content
Glama

Devops Check Dns

devops_check_dns
Read-onlyIdempotent

Resolve DNS records for one or more domains across multiple public resolvers and compare what each resolver returned. Works for any domain — no vendor registry required. Reports records found (A/AAAA/CNAME/MX/TXT/NS), resolution latency per resolver, and a typed outcome per resolver and record type so "the domain does not exist" (nxdomain), "the resolver could not answer" (servfail), and "no record of this type" (nodata) stay distinguishable. Resolver disagreements are reported without asserting a cause: partial_resolution (some resolvers answered, others returned nothing) points at a real propagation or resolver problem, while value_variation (every resolver answered with different values) is the normal steady state for anycast and geo-steered domains. Pair with devops_check_certs when a domain resolves but TLS to it is failing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainsYesDomain names to query. Up to 10 per call.
resolversNoResolver IP addresses to query. Defaults to Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). Add custom resolvers to test resolver-specific behavior. Each must be an IP literal, not a hostname; resolvers in private, loopback, or cloud-metadata ranges are rejected unless DEVOPS_STATUS_ALLOW_PRIVATE_TARGETS=true.
timeout_msNoQuery timeout per domain+resolver combination in milliseconds. Defaults to the DEVOPS_STATUS_DNS_TIMEOUT_MS env var (3000 when unset).
record_typesNoDNS record types to resolve. Defaults to A, AAAA, MX, and TXT. Add NS to check nameserver delegation. Add CNAME when investigating redirect chains.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
resultsNoPer-domain DNS resolution results.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed6 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / anyOf
      Added value: +[
      +  {
      +    "not": {
      +      "required": [
      +        "error"
      +      ]
      +    },
      +    "required": [
      +      "results"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "error"
      +    ]
      +  }
      +]
    • addedOutput schema / properties / error
      Added value: +{
      +  "additionalProperties": {},
      +  "description": "Present when the call failed. Absent on success.",
      +  "properties": {
      +    "code": {
      +      "description": "JSON-RPC error code for this failure.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    },
      +    "data": {
      +      "additionalProperties": {},
      +      "properties": {
      +        "reason": {
      +          "description": "Machine-readable failure mode. Declared by this tool: `invalid_domain`: A domain string contains a protocol prefix or invalid format. `target_blocked`: A resolver is a private, loopback, or otherwise non-public address, or is not an IP literal at all. Other values are possible when a failure originates below the handler.",
      +          "examples": [
      +            "invalid_domain",
      +            "target_blocked"
      +          ],
      +          "type": "string"
      +        },
      +        "recovery": {
      +          "additionalProperties": {},
      +          "description": "Actionable next step for the caller.",
      +          "properties": {
      +            "hint": {
      +              "type": "string"
      +            }
      +          },
      +          "required": [
      +            "hint"
      +          ],
      +          "type": "object"
      +        },
      +        "retryable": {
      +          "description": "Whether retrying may succeed.",
      +          "type": "boolean"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "message": {
      +      "description": "Human-readable description of what went wrong.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "code",
      +    "message"
      +  ],
      +  "type": "object"
      +}
    • removedOutput schema / required
      Removed value: -[
      -  "results"
      -]
  2. Changed4 schema fields changed
    • changedOutput schema / properties / results / items / properties / records / description
      Previous value: -"Resolved records from a single resolver, keyed by record type (A, AAAA, CNAME, MX, TXT, NS). Taken from the primary resolver (first in \"resolvers\"), or from the first resolver that returned records when the primary returned none. Read \"records_source\" for which resolver these came from, and \"resolver_results\" for the full per-resolver picture."New value: +"Resolved records from a single resolver, keyed by record type (A, AAAA, CNAME, MX, TXT, NS). Taken from the primary resolver (first in \"resolvers\"), or from the first resolver that returned records when the primary returned none. Read \"records_source\" for which resolver these came from, and \"resolver_results\" for the full per-resolver picture. This is also the reference set the per-resolver answers are reported against: a resolver that returned exactly these values for a type names it in \"records_same_as_domain\" rather than repeating them."
    • changedOutput schema / properties / results / items / properties / resolver_results / items / properties / records / description
      Previous value: -"Records returned by this resolver, keyed by type."New value: +"Records returned by this resolver, keyed by type — carrying only the types whose values differ from the domain-level \"records\" set. A type this resolver answered identically is named in \"records_same_as_domain\" instead of repeated here. A requested type in neither place returned nothing from this resolver; \"status_by_type\" says why."
    • addedOutput schema / properties / results / items / properties / resolver_results / items / properties / records_same_as_domain
      Added value: +{
      +  "description": "Record types this resolver answered with exactly the domain-level \"records\" values, omitted from \"records\" above rather than duplicated. Read their values from the domain-level set. Resolvers agreeing is the common case, so this list is usually where most of the answer is.",
      +  "items": {
      +    "description": "A record type answered exactly as the domain-level set.",
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedOutput schema / properties / results / items / properties / resolver_results / items / required
      Previous value: -[
      -  "resolver",
      -  "latency_ms",
      -  "records",
      -  "status",
      -  "status_by_type",
      -  "error"
      -]New value: +[
      +  "resolver",
      +  "latency_ms",
      +  "records",
      +  "records_same_as_domain",
      +  "status",
      +  "status_by_type",
      +  "error"
      +]
  3. Changed17 schema fields changed
    • changedOutput schema / properties / results / items / properties / error / description
      Previous value: -"Overall error message if the domain could not be queried at all."New value: +"Set only when the domain could not be queried at all — every resolver failed and none returned records. Each failing resolver is named with its own outcome (\"8.8.8.8: SERVFAIL on A; 1.1.1.1: NXDOMAIN on A\") so a split result stays visible. Null when at least one resolver answered; per-resolver failures are still in \"resolver_results\" and \"flags\"."
    • changedOutput schema / properties / results / items / properties / flags / description
      Previous value: -"Human-readable observations: \"propagation mismatch on A records\", \"no MX records found\", \"CNAME detected — further records resolve via the CNAME target\", etc."New value: +"Human-readable observations that need attention: \"NXDOMAIN from 8.8.8.8, 1.1.1.1 on A, MX — the domain does not exist …\", \"Partial resolution on A records — 9.9.9.9 (nodata) returned nothing while 8.8.8.8 answered\", \"No MX records found\", \"CNAME detected — further records resolve via the CNAME target\". A value_variation disagreement is not flagged here — it is reported in \"propagation_discrepancies\" because it is normal for geo-steered domains."
    • changedOutput schema / properties / results / items / properties / propagation_discrepancies / description
      Previous value: -"Record types where resolvers returned different values. Empty when all resolvers agree."New value: +"Record types where resolvers returned different answers, each labelled by \"kind\". Empty when all resolvers agree."
    • changedOutput schema / properties / results / items / properties / propagation_discrepancies / items / description
      Previous value: -"A record type where resolvers returned different values."New value: +"A record type where resolvers returned different answers."
    • addedOutput schema / properties / results / items / properties / propagation_discrepancies / items / properties / kind
      Added value: +{
      +  "description": "What the disagreement is. \"partial_resolution\" = at least one resolver returned records and at least one returned nothing; this is the signal worth investigating (in-flight propagation, a broken resolver, or a partial delegation) — read \"status_by_resolver\" for why each empty resolver was empty. \"value_variation\" = every resolver answered but with different values; this is the expected steady state for anycast and geo-steered domains such as CDN-fronted hostnames, and is also consistent with an in-flight DNS change. Neither value asserts a cause on its own.",
      +  "enum": [
      +    "value_variation",
      +    "partial_resolution"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / properties / results / items / properties / propagation_discrepancies / items / properties / record_type / description
      Previous value: -"The DNS record type with differing values."New value: +"The DNS record type resolvers disagreed on."
    • changedOutput schema / properties / results / items / properties / propagation_discrepancies / items / properties / resolvers_agree / description
      Previous value: -"False when resolvers returned different values."New value: +"Always false — an entry only exists when resolvers disagreed."
    • addedOutput schema / properties / results / items / properties / propagation_discrepancies / items / properties / status_by_resolver
      Added value: +{
      +  "additionalProperties": {
      +    "enum": [
      +      "ok",
      +      "nodata",
      +      "nxdomain",
      +      "servfail",
      +      "refused",
      +      "timeout",
      +      "error"
      +    ],
      +    "type": "string"
      +  },
      +  "description": "Outcome for this record type per resolver IP address — explains an empty entry in \"values_by_resolver\" as nodata, nxdomain, servfail, timeout, refused, or error.",
      +  "propertyNames": {
      +    "type": "string"
      +  },
      +  "type": "object"
      +}
    • changedOutput schema / properties / results / items / properties / propagation_discrepancies / items / properties / values_by_resolver / description
      Previous value: -"Values reported per resolver IP address."New value: +"Values reported per resolver IP address. An empty array means that resolver returned no records of this type."
    • changedOutput schema / properties / results / items / properties / propagation_discrepancies / items / required
      Previous value: -[
      -  "record_type",
      -  "resolvers_agree",
      -  "values_by_resolver"
      -]New value: +[
      +  "record_type",
      +  "resolvers_agree",
      +  "kind",
      +  "values_by_resolver",
      +  "status_by_resolver"
      +]
    • changedOutput schema / properties / results / items / properties / records / description
      Previous value: -"Resolved records from the primary resolver (first in list). Keyed by record type (A, AAAA, CNAME, MX, TXT, NS)."New value: +"Resolved records from a single resolver, keyed by record type (A, AAAA, CNAME, MX, TXT, NS). Taken from the primary resolver (first in \"resolvers\"), or from the first resolver that returned records when the primary returned none. Read \"records_source\" for which resolver these came from, and \"resolver_results\" for the full per-resolver picture."
    • addedOutput schema / properties / results / items / properties / records_source
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Resolver IP whose answers populated \"records\", or null when no resolver was queried."
      +}
    • changedOutput schema / properties / results / items / properties / resolver_results / items / properties / error / description
      Previous value: -"Error message if this resolver failed, or null on success."New value: +"Failure summary for this resolver in the form \"SERVFAIL on A, MX\", or null when every requested type either resolved or returned nodata. Nodata is never reported as an error — it is a valid DNS answer."
    • addedOutput schema / properties / results / items / properties / resolver_results / items / properties / status
      Added value: +{
      +  "description": "Headline outcome for this resolver: \"ok\" when any requested record type resolved, otherwise the most actionable failure across the requested types (servfail, timeout, refused, error, nxdomain, nodata — in that order). Read \"status_by_type\" for the per-record-type detail.",
      +  "enum": [
      +    "ok",
      +    "nodata",
      +    "nxdomain",
      +    "servfail",
      +    "refused",
      +    "timeout",
      +    "error"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / results / items / properties / resolver_results / items / properties / status_by_type
      Added value: +{
      +  "additionalProperties": {
      +    "enum": [
      +      "ok",
      +      "nodata",
      +      "nxdomain",
      +      "servfail",
      +      "refused",
      +      "timeout",
      +      "error"
      +    ],
      +    "type": "string"
      +  },
      +  "description": "Outcome for each requested record type, keyed by type. \"ok\" = records returned; \"nodata\" = the domain exists but has no record of this type; \"nxdomain\" = the domain does not exist (check for a typo, an expired registration, or a missing delegation); \"servfail\" = the resolver could not complete the query, commonly a DNSSEC validation failure; \"refused\" = the resolver declined; \"timeout\" = no answer within timeout_ms; \"error\" = any other failure, described in \"error\".",
      +  "propertyNames": {
      +    "type": "string"
      +  },
      +  "type": "object"
      +}
    • changedOutput schema / properties / results / items / properties / resolver_results / items / required
      Previous value: -[
      -  "resolver",
      -  "latency_ms",
      -  "records",
      -  "error"
      -]New value: +[
      +  "resolver",
      +  "latency_ms",
      +  "records",
      +  "status",
      +  "status_by_type",
      +  "error"
      +]
    • changedOutput schema / properties / results / items / required
      Previous value: -[
      -  "domain",
      -  "records",
      -  "resolver_results",
      -  "propagation_discrepancies",
      -  "flags",
      -  "error"
      -]New value: +[
      +  "domain",
      +  "records",
      +  "records_source",
      +  "resolver_results",
      +  "propagation_discrepancies",
      +  "flags",
      +  "error"
      +]
  4. Changed2 schema fields changed
    • changedInput schema / properties / resolvers / description
      Previous value: -"Resolver IP addresses to query. Defaults to Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). Add custom resolvers to check internal DNS or test resolver-specific behavior."New value: +"Resolver IP addresses to query. Defaults to Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). Add custom resolvers to test resolver-specific behavior. Each must be an IP literal, not a hostname; resolvers in private, loopback, or cloud-metadata ranges are rejected unless DEVOPS_STATUS_ALLOW_PRIVATE_TARGETS=true."
    • changedInput schema / properties / resolvers / items / description
      Previous value: -"A resolver IP address (e.g., \"8.8.8.8\")."New value: +"A resolver IP literal — IPv4 (\"8.8.8.8\"), IPv6 (\"2001:4860:4860::8888\"), or either with a port (\"1.1.1.1:53\", \"[2001:4860:4860::8888]:53\"). A hostname is rejected."
  5. Changed1 schema field changed
    • changedInput schema / properties / timeout_ms / description
      Previous value: -"Query timeout per domain+resolver combination in milliseconds."New value: +"Query timeout per domain+resolver combination in milliseconds. Defaults to the DEVOPS_STATUS_DNS_TIMEOUT_MS env var (3000 when unset)."
  6. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety is covered. The description goes well beyond that by detailing output specifics: reports records found, resolution latency, and typed outcomes (nxdomain/servfail/nodata), plus explaining partial_resolution vs value_variation semantics. It also notes that resolver disagreements are reported without asserting cause. This is rich behavioral context that helps the agent set expectations.

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 moderately long but each sentence earns its place. It leads with the core action, then covers domain scope, output details, resolver-outcome semantics, and a sibling pairing. The structure is logical and front-loaded, with no redundant fluff.

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?

Given the tool's complexity (4 parameters, multiple resolvers, distinct outcomes), the description covers everything an agent needs: when to use it (any domain, no vendor registry), what it returns (records, latency, typed outcomes), how to interpret resolver disagreements, and a concrete pairing with devops_check_certs. The output schema exists but the description still adds value by explaining the meaning of outcomes, making the context complete.

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%, so every parameter (domains, resolvers, timeout_ms, record_types) is already documented in the schema with format details, defaults, and constraints. The description does not add parameter-specific meaning beyond the schema; it merely restates the record types in general and mentions the resolver comparison. This matches the baseline of 3 where the schema does the heavy lifting.

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 states a specific verb-resource combination ('Resolve DNS records ... across multiple public resolvers and compare what each resolver returned'), which clearly distinguishes it from sibling tools like devops_status_check or devops_check_certs. It also explicitly names a complementary sibling (devops_check_certs) and explains the scope ('Works for any domain — no vendor registry required'). The purpose is unmistakable.

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?

The description provides an explicit pairing condition: 'Pair with devops_check_certs when a domain resolves but TLS to it is failing.' It also states the tool works for any domain, implying no vendor prerequisites. While it doesn't enumerate exclusions against other siblings (e.g., devops_get_incidents), the one explicit alternative and the scope hint make when-to-use reasonably clear. It doesn't explicitly say when *not* to use it, so it's not a 5.

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.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct aspect of DevOps status monitoring: certificate health, DNS resolution, incident history, vendor discovery, current status, action suggestions, and stack monitoring. Even the overlapping status_check and watch_stack have clear differences (arbitrary targets vs saved stacks). No ambiguity.

Naming Consistency4/5

All tools share the devops_ prefix and mostly follow a verb_noun pattern (check_certs, check_dns, get_incidents, list_vendors, suggest_action, watch_stack). The exception is devops_status_check, which inverts to noun_verb, but it's still readable and doesn't cause confusion.

Tool Count5/5

7 tools is well within the 3-15 sweet spot for a domain-specific server. Each tool covers a necessary function with no redundancy or bloat, making the surface area easy to navigate.

Completeness4/5

The tool set covers the core lifecycle of DevOps status monitoring: discovery, health checks, incident lookup, certificate and DNS checks, and actionable recommendations. Minor gaps like a dedicated tool for viewing a single incident in isolation are mitigated by filtering in get_incidents. The stack management is a bonus that adds convenience.