DNSai Free DNS Tools

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the fan-out behavior: for a domain it resolves and checks the domain itself, its A-record IP, and its MX IPs, and each verdict names the IP and its role. That is material context an agent cannot infer from annotations or schema. It stops short of noting rate limits, latency, or partial-failure behavior when some lookups fail.

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?

Three sentences, front-loaded with the core action and provider list, then the domain fan-out behavior, then the return shape. Every sentence carries information; no filler.

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?

With one fully documented parameter, existing annotations, and an output schema covering return values, an agent has everything needed to call this correctly; the description supplies the only non-obvious piece, the multi-IP verdict semantics.

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 coverage is 100% and the single parameter is well documented, so baseline is 3. The description adds value by emphasizing a single target per call ('ONE domain or IP'), implying lists or comma-separated input are not accepted, which the schema does not state.

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?

States a specific verb and resource (check one domain or IP against named email blacklists/RBLs) and enumerates the actual providers, which immediately separates it from siblings like dns_lookup, dmarc_check, and spf_analyze. The 'ONE target per call' constraint further pins down its scope.

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?

Clear context for when this is the right tool (reputation listing checks rather than DNS or authentication-record analysis) and an explicit usage constraint ('One target per call'). It does not, however, name a sibling alternative or state what it is not for (e.g., investigating DNS records generally).

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds genuinely new context by warning that private selectors won't be surfaced and that "none found" is not proof of "no DKIM". It doesn't mention rate limits or how many selectors are typically probed, but the key interpretive caveat is present.

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?

Four short sentences, each doing distinct work: purpose/returns, trigger conditions, a false-negative caveat, and a scope constraint. Purpose is front-loaded and nothing is padded.

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?

An output schema exists, so the description needn't document return shape, and it still gives a one-line summary. Combined with the false-negative caveat and the single-domain constraint, an agent has everything needed to call it and interpret results correctly.

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 coverage is 100% and the schema already states "The single domain to check, e.g. 'acme.com'". The description's "One domain per call" restates that constraint rather than adding new semantics, so baseline 3 applies.

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?

States a specific verb+resource ("Discover the DKIM signing keys published for ONE domain") and even summarizes the return payload (keys, mapped mail providers, selectors). The DKIM focus makes it trivially separable from siblings like dmarc_check, spf_analyze, and dns_lookup.

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?

Gives concrete triggering phrasing ("Use when the user asks about DKIM, signing keys, or 'does this domain sign its mail?'"), which is strong when-to-use guidance. It does not name alternative tools or state when to prefer dmarc_check/spf_analyze instead, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real value beyond them by naming the parsed fields (presence, p= value, raw record) and stating the single-domain-per-call constraint. It does not mention behavior when no DMARC record exists or any rate/lookup limits, which is the remaining gap.

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?

Three tight sentences, front-loaded with the verb+resource, then usage examples, then the routing alternative. Every clause carries routing or scoping information; nothing is redundant padding.

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?

With an output schema present, the description needn't explain return values, and annotations cover the read-only nature. The one-domain constraint and the alternative-tool routing make it essentially callable as-is; only absent-record / error behavior is left unstated, which is a minor omission for a simple lookup tool.

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 coverage is 100% and the single domain parameter is fully documented in the schema with an example. The description's only addition is the repeated emphasis on 'ONE domain per call,' which reinforces cardinality but adds little beyond what the schema already provides; baseline 3 applies.

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?

States a specific verb pair (fetch and parse) and resource (DMARC policy) with an explicit scope of ONE domain, plus what is returned (presence, p= policy, raw record). An agent can immediately distinguish this from email_security_check or dkim_discover without opening a schema.

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?

Gives concrete when-to-use examples in quotes ("does this domain have DMARC", "is it p=reject/quarantine/none") and names the alternative email_security_check with the exact condition that selects it (full graded SPF+DMARC+MX posture). It also adds a cardinality constraint: one domain per call.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantial behavior: the default "common" view's exact coverage, that unqueried types surface under not_queried and must be requested explicitly, that results are untruncated by default with ASN/geolocation/TTLs, and that data comes live from public resolvers. It also tells the agent to relay records verbatim rather than paraphrase — a presentation rule not encoded anywhere else.

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?

Front-loaded with purpose, then default behavior, then usage boundaries, then an example — a sensible ordering. It is dense but every clause carries information; the parenthetical record list and repeated "COMPLETE/untruncated" emphasis are slightly redundant but justified as guardrails against summarization.

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?

For a 4-parameter, fully-documented read-only lookup with an output schema, the description covers scope, defaults, exclusions, presentation expectations, and a bulk escape hatch. Nothing an agent needs in order to call it correctly or interpret the default output is missing.

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 coverage is 100%, so baseline is 3; the description goes beyond by explaining the semantic difference between type="common" and an explicit single type (full untruncated set), and between detail="full" vs "concise" (curated view, summarized TXT sets). The resolver parameter is left to the schema, and a worked example reinforces the type parameter, keeping it just short of a 5.

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?

States a specific verb and resource ("Look up live DNS records for ONE domain") and immediately scopes it to a single domain. It explicitly contrasts itself with the sibling email_security_check and names the bulk-API alternative, so an agent can distinguish it from every sibling without opening a schema.

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?

Gives an explicit trigger ("whenever the user asks about a domain's DNS records, name servers, IP addresses, or dig/nslookup-style questions"), an explicit exclusion ("Do NOT use this to grade email security... call email_security_check"), and a fallback for bulk lists. Both when and when-not are covered with named alternatives.

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

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

Beyond the read-only annotation, the description dictates key behavioral traits: it returns a 'graded verdict with prioritized fixes' and specifies how the output changes based on the 'detail' parameter being 'full' versus 'concise.' This adds significant operational context to the tool's execution.

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?

The description is dense but extremely efficient. It front-loads the primary value proposition and uses the remaining space to logically structure the differentiation from siblings and the parameter impact, without being verbose.

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 the complexity of email security checks (multiple protocol checks, grading, and output toggles), the description is extremely complete. It provides all necessary context for an agent to determine if this is the correct tool to call and how to configure it.

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?

With 100% schema coverage, the description's job is to elaborate. It successfully adds meaning by defining the output difference between the 'full' and 'concise' detail options, helping the agent understand the scope of the returned data for each setting.

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 clearly defines the tool's purpose: to answer if a domain is properly secured. It enumerates the checks performed (MX, SPF, DMARC, provider detection) and explicitly differentiates its function from a 'plain DNS resolver.'

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?

It provides comprehensive usage guidelines by specifying when to use the tool (e.g., 'when the user asks about email deliverability' or 'is email set up correctly') and providing explicit alternatives to avoid (e.g., 'dns_lookup, spf_analyze or dmarc_check'). It also points to 'dkim_discover' for DKIM specific keys.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely new behavioral fact — it "runs the lookup" rather than just reading a cached document, and returns "the data plus a summary" — but says nothing about latency, failure behavior for a stale or malformed id, or whether the id namespace is shared across check types.

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?

Two short sentences, front-loaded with the action and the resource, with no filler. The trailing "plus a summary" is slightly vague but still carries information rather than padding.

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?

For a one-parameter retrieval tool with annotations and no output schema, the description covers what it takes and roughly what it returns. It stops short of telling an agent how to recover when an id is invalid or whether the lookup can be slow, which are the remaining gaps an agent would want before calling.

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 100% and the single id parameter already carries a concrete example ("email_security_check:acme.com"). The description only reinforces provenance ("from search") and adds no format, casing, or namespacing detail beyond the schema, so the baseline 3 applies.

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?

"Fetch a DNSai result document by id" states a specific verb and resource, and the parenthetical "(from search)" ties it to the sibling that produces the id. It is distinguishable from search and from the raw DNS tools (dns_lookup, whois_lookup) because it retrieves a stored result document rather than running a new query type.

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?

The phrase "by id (from search)" implies the workflow — call search first, then fetch — which is real guidance, but it is implied rather than stated. There is no explicit when-to-use/when-not statement or named alternative (e.g., what to do if you only have a domain and not an id).

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

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

Beyond the annotations (openWorld, non-idempotent, non-destructive), it discloses the full flow: an email verification link is sent, the key arrives only after the click, no password or signup is required, and the key has a dk_free_ prefix used as a Bearer token. That is exactly the context annotations cannot carry.

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?

Four tight sentences: benefit first, mechanics second, invocation timing third, post-verification usage last. No filler and nothing repeated from the schema or annotations.

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?

With no output schema, the description correctly explains that the key is not returned synchronously but emailed after verification, which is the single most important thing an agent needs to set expectations. Nothing material is missing for a one-parameter tool.

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 coverage is 100%, so baseline would be 3; the description still adds meaning by explaining that the email is used to send a verification link, not merely as an identifier. Minor gain, hence 4 rather than 5.

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?

States a specific verb and resource ('Get a FREE DNSai API key') plus the concrete effect (raises daily limit to 100 lookups/day). This is unmistakably different from every sibling, which are all read-only lookup/analysis tools.

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?

Gives explicit triggers: call as soon as the user supplies an email, and proactively when a lookup response carries an upgrade nudge or the anonymous limit is hit. It also implicitly excludes passive use by tying invocation to those signals.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description goes beyond them by disclosing the return shape (id, title, url) despite no output schema, and by defining the id→fetch handoff. It doesn't mention whether DNSai requires an API key (request_api_key is a sibling) or how many results come back.

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?

Two sentences, both front-loaded with the essential information — what is searched and what comes back — with no filler or restatement of the name.

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?

For a one-parameter, no-output-schema tool, the description supplies the otherwise-missing return shape and the follow-up path, which is what an agent needs to chain calls correctly. Auth requirements and result volume remain unstated.

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 coverage is 100% and the single query parameter is fully documented there, including that it accepts natural language or a bare domain. The description only echoes the domain case and slightly narrows the schema's stated flexibility, so it adds marginal value beyond the schema.

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 definition gives a specific verb+resource ("Search DNSai for a domain") and immediately enumerates the content covered — DNS records, email-security posture, DMARC, WHOIS — which positions it as the aggregate entry point among the granular siblings (dns_lookup, dmarc_check, whois_lookup). It stops short of explicitly contrasting itself with those siblings, but the scope statement does most of that work.

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?

The two-step workflow is made explicit: search by domain to get result items, then "pass a result id to fetch for the full data." That is real routing guidance toward the fetch sibling. What's absent is when to prefer the focused tools (dkim_discover, spf_analyze) over this broader search.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds behavioral substance by naming the exact analysis performed (include tree + lookup-count verdict against the RFC limit) and the single-domain-per-call constraint. It stops short of mentioning cost, latency, or that live DNS queries back the result — the one piece of open-world behavior worth flagging.

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?

Three short sentences, front-loaded with the core action and scope, followed by the routing rule and then the cardinality constraint. Every sentence carries distinct information; nothing is repeated from the title or schema.

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?

With an output schema present the description needn't explain return values, and with annotations present it needn't re-explain safety. What remains — what is analyzed, when to use it, what to use instead, and how many domains per call — is all covered.

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 coverage is 100% and the single `domain` parameter is fully documented with an example in the schema itself. The description reinforces the key semantic that exactly one domain may be passed, which is the only real failure mode, but adds no format or validation detail beyond that.

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?

States a specific verb and resource (analyze a domain's SPF record) plus the concrete outputs: include tree, RFC 10-DNS-lookup-limit verdict, and the `all` qualifier. It explicitly carves itself apart from the sibling email_security_check, so an agent can route without opening either schema.

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?

Gives an explicit when-to-use condition ('only when the question is specifically about SPF') and names the correct alternative for the adjacent case ('overall is email secure grade, use email_security_check instead'). The 'one domain per call' line also rules out a misuse pattern.

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

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

Annotations already declare readOnly and closed-world, so the safety profile is covered; the description adds the meaningful behavioral fact that no DNS lookup occurs, which is exactly the distinction an agent needs. It also previews the response shape (valid/invalid, score, grade, parsed breakdown), though that partly duplicates the existing 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the scope constraint and followed by the trigger condition. No filler or repetition.

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?

For a two-param read-only validator with an output schema, the description covers what it does, what it doesn't do (DNS), and when to reach for it. The only gap is not explicitly contrasting with DNS-based sibling tools.

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 coverage is 100%, so both the record string and the spf/dmarc/auto enum are fully documented in the schema. The description adds nothing about the type parameter or auto-detection behavior, so the baseline 3 applies.

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?

States a precise verb (Validate) and resource (SPF/DMARC record string) and immediately bounds scope to SYNTAX with 'no DNS lookup'. This distinguishes it from DNS-performing siblings like spf_analyze and dmarc_check 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.

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

Gives a concrete trigger: 'Use when the user pastes an SPF/DMARC record and asks "is this correct?"'. That is clear usage context, but it never names the alternative DNS-based tools (spf_analyze, dmarc_check) that an agent might otherwise pick, so routing is implied rather than explicit.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds a genuine behavioral caveat — data is returned 'publicly published ... as-is' — which warns the agent that fields may be redacted or missing; it does not mention registry coverage gaps or throttling, keeping it below a 5.

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?

Three compact sentences: what it returns, the fidelity caveat, the intent triggers, and the cardinality constraint. Nothing is redundant and the resource definition is front-loaded.

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?

A read-only, one-parameter lookup with a full output schema and safety annotations leaves little for the description to carry. Scope, data fidelity, and intended queries are all covered; return values need not be explained because an output schema exists.

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 coverage is 100% with a single well-documented parameter including examples ("acme.com", "8.8.8.8"). The description only reinforces the cardinality ('One target per call') and adds no syntax or format detail beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource (WHOIS/RDAP registration data) plus the fields returned (registrar, status, creation/expiry, name servers) and the scope constraint (ONE domain or IP). An agent can distinguish it from dns_lookup or validate without opening either schema.

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?

Gives concrete trigger phrases — "who owns", "when does it expire", "registrar", "when was it registered" — which map user intent to this tool. It does not explicitly name the alternative (dns_lookup) or state when NOT to use it, so it falls short of full routing guidance.

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