Opsphere — DevOps & SRE Intelligence

Azure DNS Lookup

azure_dns_lookup

Read-only

Queries Azure DNS zones and record sets. Without zone: lists all DNS zones in the subscription. With zone: lists all record sets (or filter by recordType / hostname). Supports both public and private DNS zones.

Input Schema

Name	Required	Description
`zone`	No	DNS zone name (e.g. example.com). Omit to list all zones.
`hostname`	No	Hostname to look up within the zone (e.g. api.example.com)
`context_id`	No	Optional explicit Connection Hub work context (ctx_*). Omit to use the conversation's active workspace; global Hub tools ignore it.
`recordType`	No	DNS record type filter (default: all types)
`privateZone`	No	If true, queries Azure Private DNS zones instead of public (default: false)
`resourceGroup`	No	Resource group containing the zone (optional, auto-detected when possible)
`azure_tenant_id`	No	Azure tenant ID (optional — defaults to AZURE_TENANT_ID from tenant config)

Output Schema

Name	Required	Description	Default
`ok`	Yes
`data`	Yes
`contractVersion`	Yes
`dataSchemaVersion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedOct 26, 2026

removedOutput schema / properties / data / properties / format

Removed value: -{
-  "enum": [
-    "plain",
-    "markdown",
-    "json"
-  ],
-  "type": "string"
-}

addedOutput schema / properties / data / properties / gaps

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / data / properties / hostname
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / data / properties / partial
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / data / properties / records

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "type": {
+        "type": "string"
+      },
+      "value": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "type",
+      "value"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

removedOutput schema / properties / data / properties / text
```
Removed value: -{
-  "type": "string"
-}
```

addedOutput schema / properties / data / properties / warnings

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / properties / data / required

Previous value: -[
-  "text"
-]New value: +[
+  "hostname",
+  "records",
+  "partial",
+  "warnings",
+  "gaps"
+]

addedOutput schema / properties / dataSchemaVersion

Added value: +{
+  "const": 2,
+  "type": "number"
+}

changedOutput schema / required

Previous value: -[
-  "contractVersion",
-  "ok",
-  "data"
-]New value: +[
+  "contractVersion",
+  "dataSchemaVersion",
+  "ok",
+  "data"
+]

First observedOct 15, 2026

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 the safety profile is covered. The description adds real behavioral context beyond that: the two output modes driven by presence/absence of zone, and the public/private zone distinction. Missing auth/rate-limit notes, but strong for a read tool with annotations.

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?

Three tight sentences, front-loaded with the core action, then the two modes, then a scoping note. No filler; every clause carries information.

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 an output schema and full schema coverage, the description needn't explain return values. It adequately covers purpose, modes, and zone types. A minor gap is not clarifying the relationship to the generic dns_lookup/cf_dns_records siblings.

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 coverage is 100%, so all seven parameters are already documented in the schema. The description reinforces how zone (optional) flips behavior between listing zones and listing record sets, and mentions recordType/hostname filtering, but adds little beyond what the schema's own descriptions provide. Baseline 3 is appropriate.

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+resource (queries Azure DNS zones and record sets) and scopes it to Azure, which distinguishes it from cf_dns_records and dns_lookup implicitly. However, it never names those siblings explicitly, so the differentiation relies on the agent inferring 'Azure' means not-Cloudflare/not-generic.

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?

Provides explicit conditional branching: without zone -> list zones, with zone -> list record sets (optionally filtered). This is genuine when-to-use guidance for the tool's own modes. It stops short of routing the agent away from the generic dns_lookup or cf_dns_records siblings.

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

All Opsphere — DevOps & SRE Intelligence tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?