how.is domain & IP intelligence

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), but the description adds genuinely useful context beyond them: the 7-day observation window, hourly refresh cadence, partner-tier requirement, and per-call price. Return shape is sketched but no detail on freshness lag, payload size, or throttling.

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 resource and scope, then tier/pricing, then return shape. Every sentence carries distinct information an agent needs before spending a call.

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 parameters and no output schema, the description must carry the return-value burden, and it does name the top-level fields. The nesting of networks/bots/fingerprints is only gestured at, so an agent knows the shape but not the element structure.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description instead describes the response contents (generated_at, networks, bots, fingerprints), which is appropriate for a parameterless feed.

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 defines a very specific dataset: ASN-level networks, named crawlers, JA4 TLS fingerprints and firewall rules observed over the last 7 days, refreshed hourly. It is clearly a data-retrieval feed and could not be confused with domain_whois or site_status, though it never explicitly contrasts itself with any sibling by name.

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 routes the agent well by naming the free alternative (https://dns.pizza/bots) and stating exactly what that tier lacks ('same shape without fingerprints'), which implies when this paid partner tier is required. There is no explicit when-not-to-use guidance, but the tier/cost tradeoff is spelled out.

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 the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description adds genuinely useful context beyond them: the per-call price ($0.005) and a concrete sample input, which help the agent budget and format calls.

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?

Purpose is front-loaded in the first clause, followed by tightly packed pricing, sample, and return-value lists. Dense but each element earns its place; 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 no output schema, the description compensates by enumerating the returned fields (created, age_days, age_years, newly_registered, expires, registrar, source). Combined with full schema coverage and annotations, an agent has nearly everything needed to call it 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?

There is a single parameter and schema description coverage is 100%, so the schema already defines 'domain' fully. The description's sample payload corroborates the format but adds no new constraints, making the baseline 3 appropriate.

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 resource (a domain's age) plus the concrete outputs (registration date, age in days/years, newly-registered flag), so an agent knows exactly what it gets. It does not differentiate itself from closely-named siblings like domain_whois or domain_profile, which also touch registration data.

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: noting that a newly-registered status is 'a common phishing signal' hints at when this check is valuable, but the description never says when to pick this over domain_whois or domain_profile, nor any exclusions.

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 establish read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context beyond that: pricing per call, a sample request, and the return fields, though it does not cover rate limits or latency.

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 short and front-loaded with the core purpose, followed by pricing, a sample, and return fields. Every sentence contributes useful 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?

For a single-parameter lookup tool with no output schema, the description provides sufficient completeness by naming the return fields and pricing. Annotations cover the safety profile, so no critical context 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?

The only parameter has 100% schema coverage and is documented as a bare domain name. The description repeats a sample domain but adds no additional semantics 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 description states a specific check: whether IP addresses behind a domain appear on spam and abuse blocklists. This clearly differentiates it from sibling domain lookup tools such as domain_whois or domain_dns.

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 purpose implies when to use it, but the description does not explicitly state when to choose it over alternatives or when it is not appropriate. Usage is inferable from the name and purpose but not guided.

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/idempotent/non-destructive/open-world, so the safety profile is covered. The description adds genuinely new context: a per-call price ($0.005), the resolve-timing behavior, and the shape of the returned payload. Auth requirements and rate limits remain unstated.

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-loads the record types, then tacks on cost, sample, and return shape in compact clauses. Every element earns its place, though the sentence fragments read slightly telegraphically.

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 usefully explains the return path (data.data.records keyed by type, plus data.data.responseTime) and discloses cost. The main gap is routing guidance versus sibling DNS tools, but for a simple single-parameter lookup it is largely complete.

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% for the single 'domain' parameter, and the description's sample ({"domain": "example.com"}) merely restates what the schema already documents. Baseline 3 applies since the schema carries the parameter semantics.

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 the specific resource (DNS records for a domain) and enumerates the record types covered (A, AAAA, MX, NS, TXT), so an agent knows exactly what it retrieves. It does not, however, explicitly differentiate itself from close siblings like domain_dnssec or domain_email_auth, which also surface DNS-derived data.

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?

No when-to-use guidance and no exclusions relative to the many sibling domain_* tools. Pricing and a sample call are present, but nothing tells the agent when this tool is the right choice over domain_dnssec, domain_email_auth, or domain_whois.

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, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the $0.005 per-call price, a free sample, and the fact that failures surface as errors/warnings/recommendations rather than raw exceptions. That is useful cost and output-shape disclosure beyond structured data.

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: purpose, pricing/sample, then return fields. Everything is front-loaded and nothing is padded. The return-field list is slightly machine-y but earns its place given there is no output 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?

For a single-parameter, read-only lookup with no output schema, the description is nearly complete: it covers purpose, cost, a sample call, and the returned fields. The only real gap is the absence of guidance on when this beats the overlapping domain_dns/security siblings.

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?

There is one parameter with 100% schema description coverage, so the schema already documents that 'domain' is a bare domain name with a 253-char cap. The description's sample value {'domain': 'example.com'} illustrates usage but adds no syntax or constraint detail beyond the schema. 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: it reports whether DNSSEC is signed and validates for a domain. That is clearly distinct from domain_dns, domain_tls, or domain_email_auth, though the description never explicitly contrasts with those siblings. The purpose is unambiguous on its own.

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 context is only implied by the topic (DNSSEC posture checks). There is no statement of when to prefer this over domain_dns, domain_security_score, or domain_email_auth, and no prerequisites or exclusions. An agent can infer the use case but gets no 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 establish readOnly=true, idempotent=true, openWorld=true and destructive=false, so the safety profile is covered. The description adds genuinely non-structured context: a per-call price ($0.005) and the returned field set. It still says nothing about rate limits or result freshness, keeping it short of 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 short sentences, front-loaded with what the tool returns, then cost, then a copy-pasteable sample. Every clause carries information an agent can act on; nothing is 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?

There is no output schema, so the description compensates by enumerating the return fields (spf, dkim, dmarc, mx, overallScore, overallStatus, recommendations), plus cost and a valid sample invocation. For a one-parameter read tool this covers everything needed to invoke it 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 parameter is already documented as 'a bare domain name, e.g. example.com'. The description's sample payload {'domain': 'example.com'} merely restates that format, so it adds little beyond what the schema 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?

The description names a concrete resource set — SPF, DKIM, DMARC records plus overall domain email 'posture' — which is specific enough to separate it from domain_dns, domain_dnssec and domain_security_score. It lacks an explicit verb and never names a sibling it is distinct from, so it stops short of a 5.

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?

There is no when-to-use guidance, no prerequisites, and no reference to any alternative tool. The pricing line and sample call give operational detail but do not tell the agent when this tool is the right choice versus the other twelve domain_* siblings.

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, idempotent, openWorld and non-destructive, so the safety bar is met. The description adds genuinely new context: per-call pricing, a free sample invocation, the section-level return structure, and that data.errors names failed sections and data.billing reports what was delivered — useful partial-failure semantics absent from the structured fields.

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 the capability, followed by coverage list, price, sample, and return shape — every clause carries information an agent needs to decide and call. 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?

With no output schema present, the description steps in to describe the return envelope (data.sections.*, data.errors, data.billing) and the cost model. For a single-param read-only bundle, nothing needed to call it correctly 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% and there is a single parameter, so the schema already documents 'domain'. The description reinforces the expected input format via the free sample {"domain": "example.com"}, matching the schema's bare-domain guidance without adding format subtleties.

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 resource and scope — 'Everything about a domain in one call' — then enumerates the exact sections bundled (DNS, WHOIS, TLS, DNSSEC, email auth, security score, blacklist, IP). The enumeration makes clear this is a bundle superset of the single-purpose siblings like domain_dns and domain_whois.

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 'one call' framing and the $0.025 price imply a cost/coverage tradeoff against the cheaper single-section siblings, but the description never explicitly says when to prefer this over domain_dns or domain_whois. Usage is implied rather than stated.

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 read-only, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds genuinely new operational context beyond annotations: a per-call price of $0.005, a free sample payload, and the shape of the returned data. Rate/pricing disclosure is exactly the kind of extra context that earns credit here.

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 the purpose, then pricing, then an example and the return shape — dense but zero filler sentences. The inline JSON fragments are slightly harder to scan than prose, but 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?

With no output schema, the description usefully enumerates the return fields (grade, overallScore, maxPossibleScore, categories[]), which is what an agent needs to decide whether the call answers its question. It stops short of explaining how categories are structured or what the grade scale is, which keeps it from a 5.

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% for the single 'domain' parameter (bare domain name, maxLength 253), so the schema already does the work. The description's example {"domain": "example.com"} reinforces but does not extend the schema's own example. 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 resource and output: a letter grade and point score for a domain's security posture, plus the scored items behind it. This is distinguishable from narrow siblings like domain_tls or domain_dnssec because it is an aggregate posture grade, though the description never names those siblings explicitly.

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?

No when-to-use guidance, no prerequisites, and no routing to or away from alternatives (domain_tls, domain_dnssec, domain_blacklist). The agent must infer from the name alone that this is an aggregate scoring call rather than a component-level check.

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, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely new behavioral context not in the annotations: the $0.005 per-call cost and the full shape of the returned certificate fields, which tells the agent what data it can rely on.

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 the purpose, then pricing, then a sample request and the return-field list. It is a single dense block rather than cleanly separated sentences, but no sentence is wasted and the most important information comes first.

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 enumerates the returned fields, and the single fully-documented parameter completes the input story. It omits error behavior (invalid domain, no TLS listener, expired cert) and any timeout/latency expectation, which would be useful for a live network check.

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 documents the sole parameter ('A bare domain name, e.g. example.com'). The description's sample call restates that same example without adding format constraints (no-URL, no-IP?) beyond what the schema says, so this is baseline.

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 resource (the TLS certificate for a domain) and enumerates the exact attributes it covers: validity, issuer, protocol, days until expiry. This is clearly distinguishable from the other domain_* siblings (dns, whois, dnssec, email_auth) without opening any 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?

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance; an agent must infer from the name that this is the TLS-certificate lookup versus domain_dns or domain_whois. The pricing line and free sample are cost/request mechanics, not usage routing.

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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description adds genuinely new behavioral context: price per call ($0.020), a free sample invocation, and — importantly — disclosure of degraded results via the 'inconclusive' verdict and 'not_checked[]' field when checks cannot run. It does not discuss rate limits or latency, but the partial-failure disclosure is the kind of trait annotations cannot express.

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 the decision question, then the verdict vocabulary, then pricing/sample, then the return fields — a sensible order with no filler. The inline Returns list is dense but earns its place because no output schema exists; the free-sample snippet is the weakest element but still briefly useful.

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 and a single fully-documented parameter, the description carries the return-value burden and does so thoroughly: verdict enum, 0-100 risk_score, reasons shape, age_days, blocklist listings, unanswered blocklists, https_valid, and not_checked. Pricing and a sample call are also present, so an agent has everything needed to invoke and interpret the result.

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 there is a single parameter, so the schema already documents 'domain' as a bare domain name with maxLength 253. The description's sample payload reinforces the expected shape but adds no syntax or normalization guidance (e.g., scheme, subdomain, trailing dot) beyond what the schema states. 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?

The description frames a concrete decision ('Should an agent click, sign in to, or pay this domain?') and states the resource: a risk score, a three-valued verdict, and plain-English reasons. The composite scope (domain age + blocklists + HTTPS cert) implicitly separates it from single-signal siblings like domain_age, domain_blacklist and domain_tls, but it never explicitly distinguishes itself from the possibly-overlapping domain_security_score, so sibling differentiation is left to inference.

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 opening question gives a clear decision context in which this tool is the right call, which is stronger guidance than most definitions offer. It stops short of explicit when-not guidance or naming an alternative tool, so an agent must infer that single-signal siblings are for drilling into individual factors.

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, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: a per-call price ($0.005) and the shape of the returned payload. It stops short of describing error behavior or failure modes for unregistered domains.

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-loads the returned fields, then cost, sample, and a return-path note. The closing 'Returns:' clause restates the field list from the opening sentence, which is mild redundancy, but the whole description is short and each element is scannable.

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 usefully summarizes the return payload and its nesting path, and adds pricing. For a one-parameter read-only lookup this is nearly sufficient; only error/empty-result behavior for invalid or unregistered domains is unaddressed.

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 parameter is fully documented as a bare domain name with an example. The description's sample payload repeats the schema's example rather than adding format nuance. Baseline 3 applies when the schema carries the parameter burden.

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 names a specific resource (the parsed WHOIS/RDAP record for a domain) and enumerates the fields returned: registrar, creation/expiry dates, nameservers, status codes. That is a concrete verbless-but-specific lookup. It does not, however, differentiate itself from siblings like domain_age or domain_profile, which apparently surface overlapping registration data.

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?

There is no statement of when to call this versus domain_age, domain_profile, or domain_dns, which all touch adjacent domain-attribute territory. The only auxiliary information is pricing and a sample invocation, neither of which tells the agent when this tool is the right choice.

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, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful non-schema context: per-call price ($0.005), a concrete free-sample request, and the shape of the returned payload. It does not mention rate limits or latency, keeping it short of 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?

Four tight, front-loaded sentences: purpose, price, sample request, return fields. Every sentence earns its place and nothing is 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 compensates by enumerating the returned fields, and it discloses cost and a sample invocation. For a single-parameter read tool this is nearly complete; only explicit when-to-use guidance 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 description coverage is 100% and the single 'ip' parameter is documented in-schema as an IPv4 or IPv6 address. The description adds no format or syntax detail beyond that, so the baseline of 3 for full schema coverage 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?

The description names the exact resource and the full set of returned attributes (ASN, company, geolocation, privacy flags, abuse contact) for an IP address, so the agent knows precisely what the tool produces. It does not explicitly contrast itself with the domain-oriented siblings, but the resource scope ('an IP address') inherently separates it from domain_* 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?

No statement of when to use this tool versus alternatives, and no prerequisites or exclusions. The pricing and free-sample notes are cost/onboarding information, not usage guidance, so the agent is left to infer applicability on its own.

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 flag an open-world, non-idempotent, state-mutating call, and the description goes further with the concrete details an agent needs: baseline persistence across calls, the 2% change threshold, and the $0.005 per-call cost. Since no output schema exists, listing returned fields (baseline, changed, change_pct, added, removed, last_change_ts) is a real addition.

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 question ('Has this page changed...?') followed by tightly packed operational facts — baseline mechanic, threshold, price, sample, return fields. No filler sentences; each clause conveys distinct 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?

For a single-parameter tool with no output schema, the description covers the usage model, cost, threshold, and return shape. The one remaining ambiguity is the scope of 'your last call' — how baselines are keyed/identified across sessions is not stated.

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?

One parameter at 100% schema coverage, where the schema already documents 'an http(s):// URL on the public internet'. The description's only extra signal is a free-sample URL example, so it adds marginal meaning over structured data — 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 ('has this page changed') and the returned artifact ('text diff'), which cleanly separates it from availability-oriented siblings like site_status. An agent immediately knows this is stateful change detection, not a point-in-time fetch.

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 call-sequence model is explicit: the first call stores a baseline, later calls return a diff against it. That tells the agent when and how to invoke it correctly, though it never contrasts itself with siblings (e.g., domain_profile or site_status) or states when not to use it.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description earns credit for adding genuinely new operational context: a per-call price of $0.005, a free sample payload, and a live (not cached) execution model. It omits auth requirements and error/timeout behavior, so it is strong but not exhaustive.

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 dense sentences, front-loaded with what the tool measures, then price, then a copy-pasteable sample, then the return shape. No sentence is filler; the terse field list is efficient rather than sloppy.

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 carries return-value disclosure itself and does so by naming the keying (by URL) and the entry fields (ok, code, ms, dns_ms, ip, ttl, ns, cert_days, server, ts), plus cost and an example call. Missing only edge-case behavior (failures, redirects, rate limits) for a tool with a cost and network dependency.

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% with a single 'sites' array parameter, so the baseline is 3. The description marginally helps by saying 'one or more URLs' and providing a literal sample ('{"sites": ["https://example.com"]}'), but it omits the schema's maxItems=10 cap, adding little 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?

States a specific verb+resource combination — a live check of one or more URLs — and enumerates the concrete measurements returned (HTTP status, latency, DNS resolve time, resolved IP, TTL, nameservers, TLS days). It overlaps substantively with siblings like domain_dns, domain_tls and page_watch but never names or distinguishes itself from them, so it stops short of a 5.

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 word 'Live' implies the tool is for real-time rather than cached/historical checks, and the per-call price signals a cost-consciousness framing, but there is no explicit when-to-use statement and no named alternative (e.g. domain_dns, page_watch) for the closely related checks. Usage is implied rather than stated.

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