Skip to main content
Glama
Sign In

InfraNest

by io.infranest
OverviewDiscussionsAdmin

Search DNS records across all zones

search_dns
Read-onlyIdempotent

Finds DNS records in any of your zones that match the q query parameter, by name, value or address, grouped by zone with the reason each one matched. A query shorter than two characters returns nothing with too_short set; at most 100 records are returned, with truncated set when there were more. Searches every zone at once for a hostname, value or IP address, e.g. which records point at 192.0.2.10. For one zone's full list use list_dns_records; for everything about one hostname, live DNS included, check_dns_name.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_dns"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryNoA name, value or IP address to look for (at least 2 characters).
organization_idNoThe organization to read. Leave it out when the token reaches only one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile, but the description adds real behavioral detail beyond them: the two-character minimum returning empty with too_short set, the 100-record cap with truncated set, zone grouping, and per-record match reasons. These are exactly the edge behaviors an agent needs to interpret an empty or partial result correctly.

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 purpose, then failure modes, then sibling routing — a clean order. The only waste is mild overlap between the first sentence's 'by name, value or address' and the third sentence's 'for a hostname, value or IP address', though the example justifies most of the repetition.

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?

No output schema exists, yet the description still explains the return shape (grouped by zone, match reasons, truncated flag) and the empty-result signal. Combined with full parameter coverage and sibling routing, an agent has everything needed to call and interpret this correctly.

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 the baseline is 3. The description earns above baseline by clarifying that q matches on name, value, or address and giving a concrete example (which records point at 192.0.2.10), plus reiterating the two-character floor that affects call validity.

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?

Opens with a specific verb and resource: finds DNS records in any of your zones, matched by name, value or address, grouped by zone with match reasons. It is unambiguously distinct from list_dns_records (one zone's full list) and check_dns_name (single hostname lookup) without needing the schema.

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

Usage Guidelines5/5

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

Explicitly names both alternatives and the condition that selects each: list_dns_records for one zone's full list, check_dns_name for everything about one hostname including live DNS. It also states the intended use case for this tool (cross-zone search by hostname, value, or IP).

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

All InfraNest toolsInspect
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