ScrapeMole Domains

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses the lookup mechanism (authoritative RDAP, DNS-delegation fallback for RDAP-less TLDs), the result taxonomy (registered/available/likely-available/unknown), extra return fields for taken names, and the full paid flow: x402 USDC on Base at $0.004 per successful call, with a PaymentRequired object if called unpaid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single dense sentence, but the usage trigger is front-loaded and each clause carries distinct information (limit, data source, fallback, result states, pricing). The payment clause trails, which is slightly less ideal ordering for a budget-constrained agent, but nothing is wasted.

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, yet the description enumerates the per-name result statuses and the extra fields returned for registered domains, and it explains the payment prerequisite. An agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 100% and the parameter is self-documented, so the baseline of 3 is met. The description adds useful semantics the schema alone implies less clearly: the 10-name maximum applies per call and inputs are comma-separated domain names.

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 — bulk domain availability checks — and scopes it precisely (up to 10 names, registry RDAP with DNS fallback). This is clearly distinguishable from siblings like dns, rdap, ssl and subdomains, which each do one other thing.

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?

Opens with an explicit trigger — 'Use when naming a product, company or project and you need to know which domains are free' — so the calling context is unambiguous. It does not, however, name a sibling alternative (e.g. use rdap for a single-domain deep lookup), so routing between it and the other domain tools is left 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?

With annotations covering safety (readOnly, idempotent, openWorld), the description still adds substantial non-obvious behavior: the DoH resolvers used and fallback order, that TTL/response code/DNSSEC validation are returned, the 8-type ceiling, and the entire payment model (x402 USDC on Base, $0.001 per successful call, PaymentRequired object when unpaid). The payment disclosure is critical and appears nowhere in 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?

The tool's purpose and scope are front-loaded in the first clause, and the two trailing clauses (type limit, payment) are dense but each carries information an agent needs. It is slightly compressed into one long sentence, which makes it heavier to parse than a split structure would be.

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?

Since there is no output schema, the description carries the return-value burden and does so explicitly (answers with TTL, response code NOERROR/NXDOMAIN, DNSSEC validation). Combined with the payment mechanics, an agent has everything needed to call and interpret the 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 both parameters (name, type) are already documented with examples and the supported type list. The description restates the resolution behavior and the 'up to 8 types' limit, both of which the schema already conveys, so it adds little parameter-level meaning beyond the 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?

The description opens with a specific condition and verb/resource ('resolves the current DNS records of a domain or hostname') and names the mechanism (DNS-over-HTTPS via Cloudflare/Google), which cleanly separates it from sibling tools like ssl, subdomains, rdap, and email_security. An agent can identify this as the raw DNS-record tool 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?

It gives a clear trigger ('Use when you need the current DNS records of a domain or hostname') and a usage constraint ('Up to 8 types per call'). It does not explicitly name alternatives or state when-not to use it versus the other ScrapeMole domain tools, 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.

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), and the description goes well beyond them: it discloses the grading output, and critically the payment model (x402 USDC on Base, $0.003 per successful call, and that an unpaid call returns a PaymentRequired object). Cost and payment-failure behavior are exactly the kind of context an agent cannot infer from 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?

Two sentences, front-loaded with the usage trigger before the record enumeration and the output/payment notes. The long comma-separated record list is dense but each item is informative; it is slightly heavy but nothing is wasted 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?

For a one-parameter tool with no output schema, the description supplies everything needed: the trigger condition, the full scope of inspection, the return shape (grade, score, issues), and the payment requirement. Nothing material to a correct invocation 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?

There is a single parameter and schema description coverage is 100%, so the schema already fully documents 'domain' with an example. The description adds no syntax, format, or constraint detail beyond what the schema provides, which is the expected baseline for a fully-covered single-param tool.

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?

Names a specific verb and resource ('check whether a domain is protected against email spoofing') and enumerates exactly which records are inspected (MX, SPF, DMARC, DKIM, MTA-STS, TLS-RPT, BIMI) plus the output shape (grade A-F, score, issue list). This cleanly separates it from siblings like dns, rdap, ssl, and availability, which share the domain resource but not the audit scope.

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

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

Opens with an explicit trigger: 'Use when you need to check whether a domain is protected against email spoofing or set up for deliverability.' That is a clear when-to-use statement, though it never explicitly says when NOT to use it versus the sibling dns or ssl tools that also touch related records.

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?

Adds substantial context beyond the readOnly/openWorld/idempotent annotations: registrant personal data is never returned, an unregistered domain yields 404 and is not charged, and the tool is paid via x402 USDC on Base at $0.002 per successful call, with a PaymentRequired object returned if called without payment. These are exactly the operational facts an agent needs before invoking it.

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?

Dense but efficient: the use-case trigger leads, followed by returned fields, privacy, error/charging behavior and payment terms. Slightly run-on with several clauses stacked, but every sentence 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?

No output schema exists, yet the description enumerates the returned fields (registrar, dates, EPP status, nameservers, DNSSEC), plus privacy, 404/charging behavior and payment mechanics. An agent has everything needed to call 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?

Only one parameter and schema description coverage is 100%, so the schema already defines 'domain' with an example. The description adds no syntax or format detail 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?

States a specific verb and resource: queries the authoritative registry RDAP server (the modern WHOIS) found via IANA bootstrap, and enumerates exactly what it returns (registrar, creation/expiry dates, EPP status, nameservers, DNSSEC). This is cleanly separable from the sibling tools availability, dns, email_security, ssl and subdomains, which cover different 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?

Front-loads an explicit trigger, 'Use when you need to know who registered a domain...', which is a clear condition for selecting this tool. It does not name alternatives or state when not to use it (e.g. vs availability for registration status), so it stops short of full routing guidance.

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

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

Goes well beyond the readOnly/idempotent/openWorld annotations: it explains that answers are returned even for invalid certificates, that unreachable hosts are not charged, the Cloudflare Workers limitation with live:false plus Certificate Transparency fallback and trusted:null, and the x402 USDC payment model with a PaymentRequired object.

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 usage trigger, then behavior, return fields, fallback path and pricing in a dense sequence. It is long and somewhat run-on, but nearly every clause adds operational value an agent needs.

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 enumerates the returned fields (trust status, error codes, validity dates, subject, issuer, SAN, key type, protocol, cipher, ALPN, chain) and documents the degraded live:false response path, so an agent knows both what it gets and when results differ.

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 host and port are already documented in the schema; the description adds only the SNI mechanism and confirms the host/port shape implicitly. Baseline 3 is appropriate since 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?

States a specific verb and resource: it opens a live TLS connection to a host and reports certificate trust, hostname match, validity, chain and TLS parameters. It is clearly distinguishable from siblings like dns, rdap, availability and subdomains, which address different domain concerns.

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?

Opens with an explicit trigger ('Use when you need to know whether a website or mail server has a valid HTTPS certificate or when it expires') and covers the mail-server case that overlaps with email_security. It does not name a sibling to route away from, but the selection condition is unambiguous.

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?

Goes well beyond the readOnly/idempotent/openWorld annotations: it discloses deduplication, the returned attributes (wildcard flag, first-seen, expiry, issuer), primary source crt.sh with Cert Spotter fallback, and that the response names the source. It also documents the paid x402 USDC flow and the PaymentRequired object, which is critical invocation behavior.

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 use case, then the data scope, then sourcing, then the payment model, in a compact sequence. Every clause carries distinct information (return fields, fallback source, pricing, PaymentRequired behavior) with 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 and provenance. Combined with the payment/unauthenticated-call path and the explicit data-source limitation, an agent has everything needed to call 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%, so both `domain` and `limit` are already documented in the schema with acceptable format guidance ('example.com', 1-5000). The description adds no input-syntax detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('lists every hostname under a domain') plus the exact data source condition (unexpired publicly-logged TLS certificates). This clearly separates it from the sibling `dns`, `ssl`, and `rdap` tools, which cover different record types.

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

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

Gives explicit use cases ('attack-surface mapping, asset inventory or competitive research') and rules out a near alternative ('Only names in public certificates, no DNS brute force'), which usefully steers agents away from brute-force enumeration. It does not name a sibling tool by name as the fallback choice, 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.