Skip to main content
Glama

Opsphere — DevOps & SRE Intelligence

DNS Lookup (multi-resolver)

dns_lookup
Read-only

Lookup a hostname against multiple resolvers (8.8.8.8, 1.1.1.1, system). Returns A, AAAA, CNAME, and/or NS records with status (NOERROR, SERVFAIL, NXDOMAIN) per resolver. Use recordTypes ["NS","CNAME"] to confirm public nameserver delegation and detect a legacy alias during DNS cutovers.

Input Schema

NameRequiredDescriptionDefault
hostnameYesHostname to resolve (e.g. www.your-tenant.com)
resolversNoPublic resolver IP literals or exact "system" for the OS resolver; private, local and hostname resolvers are rejected
context_idNoOptional explicit Connection Hub work context (ctx_*). Omit to use the conversation's active workspace; global Hub tools ignore it.
recordTypesNoDNS record types to query (default A only; use NS for delegation checks)

Output Schema

NameRequiredDescriptionDefault
okYes
dataYes
contractVersionYes
dataSchemaVersionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / dataSchemaVersion
      Added value: +{
      +  "const": 1,
      +  "type": "number"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "contractVersion",
      -  "ok",
      -  "data"
      -]New value: +[
      +  "contractVersion",
      +  "dataSchemaVersion",
      +  "ok",
      +  "data"
      +]
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavior beyond that: it queries multiple resolvers and returns a status (NOERROR, SERVFAIL, NXDOMAIN) per resolver, which tells the agent to expect divergent per-resolver results. The return record-type list overlaps somewhat with the output schema.

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?

Three sentences, front-loaded with the core action and resolver scope, followed by return info and a targeted usage tip. Every sentence carries weight with minimal padding, though the return-format sentence partly duplicates the output schema.

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?

For a 4-param tool with an output schema and annotations, the description covers purpose, per-resolver return semantics, and a key usage scenario. It does not clarify why one would pick this over azure_dns_lookup or dnssec_check, a minor gap against the large sibling set.

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 baseline is 3. The description adds real semantic value to recordTypes by explaining what NS/CNAME queries are for (delegation checks, legacy alias detection), rising above the schema-only 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 (lookup) and resource (hostname) plus scope (multiple resolvers) and the record types returned. An agent knows exactly what it does, but it does not explicitly distinguish itself from near-siblings like azure_dns_lookup or dnssec_check.

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?

Gives a concrete when-to-use scenario: 'Use recordTypes [NS,CNAME] to confirm public nameserver delegation and detect a legacy alias during DNS cutovers.' This is clear context, but it offers no exclusions or routing advice against the sibling DNS tools (azure_dns_lookup, dnssec_check).

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