wildcard_dns_analysisProbe up to five random authorized labels under a domain to identify wildcard DNS behavior, helping separate real hosts from catch-all records.
Resolve up to five random, authorized labels beneath a domain to identify wildcard DNS behavior.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| probe_count | No |
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| probes | Yes | ||
| wildcard_detected | Yes |
Changes observed during successful MCP inspections.
v2.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and network-reaching profile is covered elsewhere. The description adds genuine context beyond that: it issues live DNS resolutions of randomized labels and is bounded to five probes. It does not mention rate limits, failure/timeout behavior, or how a negative result should be interpreted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 14-word sentence that front-loads the mechanism and closes with the outcome, with no filler or redundant restatement of the title. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 2-parameter tool with a full output schema and annotations covering safety and open-world behavior, the description supplies the one thing structured data cannot: what the tool actually does on the wire. Return-value explanation is legitimately unnecessary here, though domain-format and authorization details remain thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameter burden, and it only partially does: "up to five" conveys probe_count's maximum, but not its default of 3 or its minimum of 2. For "domain" it says only "beneath a domain" with no format or example (e.g., registrable domain vs. full hostname), and "authorized" is left undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (resolve), the resource it acts on (random labels beneath a domain), and the goal (identify wildcard DNS behavior), so an agent can tell it apart from dns_enumeration or dangling_dns_analysis conceptually. It stops short of naming any sibling or contrasting its scope with them, so it is clear but not sibling-differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied via the mechanism: you would call this when you need to determine whether a domain answers arbitrary subdomains. There is no explicit when-to-use statement, no exclusions, and no pointer to dns_enumeration/dangling_dns_analysis as alternatives. The word "authorized" hints at a permission prerequisite but never explains it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.