how.is domain & IP intelligence

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

Adds substantial non-obvious behavior beyond the annotations: zero cost, a link-based user flow, an implicit key-creation side effect, and the exact 'Authorization: Bearer <key>' header the user must install, plus the security guarantee that the link never reveals the key. The one gap is repeat invocation — annotations declare idempotentHint=false, so a second call presumably mints another link/key, which the description never warns about.

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, front-loaded with the cost and the core action, then the edge case, then the security caveat. Every sentence carries information the agent needs to relay to the user.

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 input parameters, no output schema and no nested structures, the description carries the full burden and discharges it: it describes the return value (a link), the user action required, the fallback key-creation flow with the exact header syntax, and the security boundary. Sufficient for an agent to act and to instruct its user 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Nothing in the text conflicts with the empty 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 and resource ('add card credit to the key on this connection') and immediately clarifies that the actual credit-adding is done by the user via a returned link, not by the call itself. This differentiates it cleanly from the sibling lookup tools (domain_*, ip_lookup, etc.), which are all read-only information services.

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 description makes the situation in which to use it clear: when the user needs credit, and the no-key case has explicit handling instructions. It does not state when not to use it or name an alternative path, but no obvious sibling competes for this job.

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?

With annotations already declaring readOnly/idempotent/openWorld/non-destructive, the description adds real behavioral context the annotations cannot express: an hourly refresh cadence, the 7-day observation window, the exact response envelope (data.data with generated_at, networks, bots, fingerprints), the difference from the free tier (no fingerprints), and a metered price per call.

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?

One front-loaded paragraph that leads with scope and payload, then cadence, then response shape. It loses a little to promotional repetition — the free tier URL is mentioned twice and the monthly-plan link adds little for an agent.

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?

No output schema exists, so the description carries the return-value burden and does so at a summary level (top-level keys of data.data). Combined with pricing and cadence, an agent has everything needed to call it; only the sub-field structure of networks/bots/fingerprints is left unspecified.

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 the baseline is 4; there is nothing extra the description could reasonably add. Schema coverage is 100% and additionalProperties is false, so no ambiguity remains.

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 dns.pizza bot observatory) and enumerates exactly what is returned: networks (ASN), named crawlers, JA4 fingerprints and firewall rules over a 7-day window. That is enough to distinguish it from the singular bot_verify / bot_verify_batch siblings, though it never explicitly contrasts itself with them.

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: an agent can infer this is the bulk 'fetch all observed bot traffic' call rather than a single verification. The per-call price ($0.050) and the free-tier pointer are useful decision inputs, but there is no explicit when-to-use / when-not guidance or named alternative, which matters in a family containing bot_verify and bot_verify_batch.

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 readOnly/idempotent/openWorld/non-destructive, so the bar is lower, and the description goes further: it discloses the evidence sources (published IP lists, forward-confirmed reverse DNS, 7 days of observatory network and JA4 data), the $0.005 per-call cost, and the full verdict taxonomy. It stops short of stating rate limits or error behavior, but adds substantial beyond-schema context.

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 core question and outcome categories before pricing, sample payload, and return fields. The return-field enumeration is dense but justified given there is no output schema; a couple of clauses (the bot list) could be trimmed without loss.

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 fully by enumerating the returned fields (verdict, confidence, identified_as, checks, observatory) and the verdict enum. Combined with the free sample call, an agent has everything needed to invoke and interpret results.

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, but the description adds meaning by explaining that identity is judged on IP + user-agent and that JA4 is a TLS fingerprint feeding the observatory check — clarifying what each input contributes to the verdict rather than just restating types.

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 ('Verify a crawler's identity') and immediately enumerates the outcome space (real Googlebot/Bingbot/GPTBot, impostor, other bot, human). This is clearly distinguishable from siblings like bot_verify_batch and bot_observatory, which are bulk/observational variants.

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 description implies when the tool is relevant by framing it as a single-visitor identity check with the required inputs, but it never names bot_verify_batch or bot_observatory as alternatives or states when not to use it. The price note hints at per-call economics but not 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 cover safety (readOnly, idempotent, non-destructive), and the description adds genuinely non-obvious behavior: per-item billing at $0.005/item, a 100-item cap, and partial-failure semantics where each item yields either a verdict or an {ip, error}. It does not mention auth requirements or rate limits, so it falls short of fully rich disclosure.

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 capability and scope, then price, sample, and return shape—every sentence carries information an agent needs. The inline sample JSON is dense but justified, though the block would read better split into distinct lines rather than one paragraph.

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, and the description compensates fully by spelling out the response envelope: results[] with one verdict or {ip, error} per item, counts by verdict, and billing{items, unit_price_usd}. Combined with the item cap and error semantics, 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 description coverage is 100%, so the ip/ua/ja4 fields and per-field constraints are already documented in the schema. The description reinforces the shape (IP + UA, optional JA4) and supplies a concrete sample payload, adding modest value beyond the structured fields.

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 (verify visitors, IP + user-agent + optional JA4) with explicit batch scope (up to 100 in one call) and directly anchors itself to the sibling: 'the same verdicts as bot_verify, for a log excerpt or a firewall review.' An agent can distinguish it from bot_verify 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?

Names concrete usage scenarios (log excerpt, firewall review) and the batching rationale (one call, one payment, billed per item), which tells the agent when the batch form pays off. It stops short of an explicit rule like 'use bot_verify for single lookups,' so the exclusion is inferred 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 and non-destructive, and the description adds substantial context beyond that: a hard 50-match cap, a 'saturated' flag that signals truncation, per-call pricing ($0.020), a free sample invocation, and a clear statement that only derived matches are returned. This is exactly the operational detail 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 definition of a look-alike, then cost/sample, then return shape. The telegraphic return-field listing earns its space because there is no output schema. No filler sentences.

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 the return-shape burden and does so thoroughly (matches array fields, window_totals, variants_searched, saturated, note), plus cost and the derived-only constraint. An agent knows what it will get, what it costs, and when results are truncated.

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 each parameter already carries its own description, so the baseline is 3. The description reinforces the 14-day window and the notion of risk tiers, but adds no syntax, defaults, or interaction rules (e.g., what min_tier defaults to) beyond what the schema states.

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 (newly registered look-alike domains of a brand) and then enumerates the exact match classes: typo, look-alike-character spelling (paypa1), same name on another TLD, or brand+lure word. The example 'paypal-login' makes the scope unambiguous and clearly separates it from sibling tools like domain_available or domain_age.

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 clear operational context (14-day registration window, derived matches only) and an explicit negative boundary — 'never a raw list of new domains' — which steers the agent away from treating it as a zone dump. It does not name any alternative sibling tool or state exclusions versus them, so it falls short of a true when/when-not routing rule.

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?

The annotations already declare read-only, idempotent, open-world, non-destructive behavior. The description adds material context beyond those hints: pricing at $0.010 per call, no charge for unknown domains returning 404, and per-field source/confidence values.

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 front-loaded with the core question and returned-field categories, then adds pricing, a sample, and return shape. The return list is long but justified because there is no output schema; there is minor duplication between the prose field list and the Returns line.

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 Returns line is necessary and covers all major response categories. The description also discloses failure behavior, cost, and confidence/source metadata, making it complete for a one-parameter read-only lookup.

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 domain parameter is fully documented with a bare-domain example. The description supplies a sample invocation but adds no new syntax, format, or constraint 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?

The description states a specific lookup question, 'Who runs this site?', and enumerates the company facts returned, so the resource and scope are clear. It does not distinguish itself from sibling domain/company-intelligence tools such as domain_profile or domain_whois, which prevents 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 opening question implies when to use the tool, and the 'unknown domains answer 404 and are not charged' note covers a failure case. However, it never says when to choose this tool over alternatives like domain_profile, domain_whois, or brand_lookalikes, leaving sibling selection to inference.

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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description goes well beyond them: per-call cost ($0.005), a free sample invocation, fallback semantics (available=null when only DNS was checked, then likely_available), a source discriminator (rdap/dns), a confidence field, and an explicit caveat field. That is rich disclosure of cost, degradation behavior, and reliability.

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 core question, then mechanism, cost, sample, and return shape in compact order with no filler. The trailing 'Returns:' run-on is dense and slightly hard to parse, which keeps it short of a 5.

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 must carry return-value burden and does: it enumerates available, registered_on, suffix, source, confidence, price sub-fields, and caveat, plus the null fallback path. Cost, degradation, and output shape are all covered for a single-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?

There is a single parameter and schema coverage is 100%, with the schema already stating 'A bare domain name, e.g. example.com'. The description's free sample repeats that format rather than adding new constraints (no IDN/unicode guidance, no subdomain handling), so the schema does the heavy lifting and 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 question answered ('Is this domain name registered?') against a named mechanism (registry over RDAP), and adds the differentiating value of first-year/renewal pricing. This separates it from siblings like domain_whois or domain_age, which the RDAP mechanism and availability focus make distinguishable 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?

Usage is implied by the framing question and the price/caveat fields, but there is no explicit when-to-use versus when-not, and no sibling is named as an alternative (e.g. domain_whois for registrant data). An agent can infer the use case but must guess at the boundaries.

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 cover the read-only, idempotent safety profile, and the description adds real context on top: the historical coverage boundaries, the caveat that first_seen may equal coverage start, the cost of $0.010 per call, and a free sample invocation. That is exactly the supplementary information an agent needs before spending credits.

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 purpose question is front-loaded, followed by coverage, interpretation signals, pricing, and the return shape. The field enumeration is long but each element is load-bearing because no output schema exists; only the sample-JSON fragment is mildly extraneous.

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 fully carries the return contract: the top-level fields, the event object structure with its type enum, and the coverage block. Combined with documented cost and coverage history, 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already explains that only registered names directly under a TLD are valid (no subdomains, no ccTLDs). The description adds nothing about the domain parameter beyond that, 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?

The opening question names the exact resource and the exact events it reports: registry zone file appearance, disappearance, return, and nameserver changes. Nothing about it could be confused with siblings like domain_whois or domain_age, which cover registration and creation data rather than zone-file history.

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 gives clear usage context: coverage windows (daily since 2026-08-05, monthly 2013-2018), the investigative interpretation of a nameserver move (hijack/sale) or a brand-new name (phishing), and the per-call price. It stops short of explicitly routing to named alternatives such as domain_whois or domain_age, which keeps it out of 5 territory.

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?

Although annotations already cover read-only, open-world, idempotent, and non-destructive behavior, the description adds substantial context: robots.txt enforcement per user agent, risky-site content marking, refund if nothing can be read, per-call pricing, and return fields including preflight and screenshot. There is no contradiction 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.

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

Front-loads the purpose and includes a structured Returns list. The pricing, free sample, and exhaustive return fields are useful but make it denser than strictly necessary; still, there is little wasted text.

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?

No output schema exists, so the description carries the return-value burden and does so by listing the main fields and embedded preflight/screenshot objects. With annotations already covering safety and idempotency, this is complete enough for a three-parameter read 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 the schema already documents url, ua, and screenshot. The description adds only high-level mentions of screenshot-on-request and preflight verdict, not syntax or meaning beyond the schema, so the baseline 3 is 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?

States a specific verb ('Read') and resource ('web page') and says what it produces: clean markdown plus a preflight verdict and optional screenshot. This is specific enough to distinguish it from siblings like url_preflight and site_screenshot, even though alternatives are not explicitly named.

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 useful behavioral context such as robots.txt handling, untrusted-content flagging, refunds, and price, but does not explicitly say when to use this instead of url_preflight or site_screenshot. Usage is implied by 'read a web page' rather than by 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 cover the safety profile (readOnly, idempotent, openWorld), and the description goes well beyond by disclosing the 6000px height cap, the fixed 1280px width, per-call pricing, and the concrete return payload 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?

It is one dense sentence, but the descriptive core (what you get) is front-loaded and every clause carries distinct information (dimensions, cap, price, returns); the example JSON is slightly noisy but useful for the required url param.

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 enumerating the returned fields (image_base64, mime, width, height, final_url, http_status, title, note) is exactly the compensation needed, and cost plus size limits are covered for a read-only 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 already 100%, so the baseline is 3, but the description adds real meaning to 'full_page' by stating the 6000px cap and contrasting viewport versus full page, information the schema does not contain.

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 ('See a web page') plus the concrete output format (1280-wide JPEG) and scope (any public URL, viewport or full page), which cleanly separates it from siblings like site_status and page_watch that also touch URLs.

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 description gives no explicit when-to-use guidance or alternative routing among the many URL/domain siblings (site_status, page_watch, bot_observatory). The 'any public URL' phrasing implies a context but doesn't state when a screenshot is the right call versus a status or monitoring tool.

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.

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

Annotations already cover read-only/idempotent/non-destructive behavior, and the description adds substantial context beyond them: fail-closed semantics, verdict values, safe_to outcomes, risk reasons, x402 pricing, and not_checked fields. It also states the per-call price and gives a sample call, leaving little behavioral ambiguity.

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 purpose is front-loaded in the first sentence and the rest is dense with operational details rather than filler. It is longer than typical because it enumerates returns without an output schema, but the structure remains readable and mostly earns its length.

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 must explain return values, and it does so in detail: verdict, risk_score, safe_to flags, actions, reasons, domain_age_days, robots, http, x402, bot_policy, and not_checked. Combined with fail-closed guidance and a sample call, it is complete enough for an agent to invoke and interpret.

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 both parameters are already described in the input schema. The description reinforces that UA affects robots.txt and bot policy, but adds little parameter-specific meaning beyond what the schema provides, so baseline 3 is 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 verb and resource: check whether a URL is safe to fetch, read, sign in to, or pay. It clearly distinguishes this pre-flight risk assessment from sibling tools like read_url or site_status by emphasizing a single safety verdict before proceeding.

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 gives clear usage context: call before fetching/reading/signing in/paying, and explicitly says fails closed so 'unknown' means do not proceed. It does not name alternative sibling tools or exclusion cases, so it stops short of a 5.

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