Agent Preflight: OFAC, DNS, Email Auth, Domain, Email & URL

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses the return shape (clean JSON with TTLs, NXDOMAIN flag, DNSSEC-authenticated bit), input normalization (URL/email reduced to host), and critically the paid x402 flow requiring a first call for the PaymentRequired object then a retry with _meta["x402/payment"]. That is exactly the operational context annotations cannot convey.

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 verb+resource and packed densely with high-value details (record types, return shape, payment flow). Slightly redundant in re-listing enum values already in the schema, but no wasted 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?

No output schema exists, so the description carries the burden of describing return values (TTLs, NXDOMAIN flag, DNSSEC bit) and it does so. It also covers the non-obvious payment handshake, which is the riskiest part of invoking this tool, leaving nothing essential missing.

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

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

Schema coverage is 100%, so the schema already documents 'name' and the 'type' enum including the ALL default set. The description mostly restates the enum contents (SRV, PTR, DS, DNSKEY, HTTPS) rather than adding meaning, 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 (resolves) and resource (live DNS records for any domain or hostname) plus the resolver used (1.1.1.1) and the record types covered. An agent can distinguish it from siblings like email_auth_check or whois_domain_age 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?

Gives clear triggering contexts: verify a domain, find mail servers or nameservers, read TXT/SPF records. It does not, however, explicitly name sibling alternatives or state when NOT to use it (e.g. vs email_mx_verify for mail checks), so the routing guidance is contextual rather than complete.

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 annotations: the paid x402 flow ($0.01 USDC on Base), the required two-step call pattern with params._meta["x402/payment"], the 10-DNS-lookup SPF budget, and the exact shape of the returned grading data. The payment prerequisite in particular is behavior an agent cannot infer from readOnlyHint/idempotentHint alone.

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?

Information-dense and front-loaded: capability first, then grading output, then usage conditions, then payment mechanics. The final payment sentence is long and slightly run-on, but every clause carries operational value rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still specifies the return shape (A-F grade, 0-100 score, coded issue identifiers) and the unique payment handshake needed to actually get a result. Nothing essential for a correct first 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?

Schema description coverage is 100%, so both parameters are already fully documented, including the reduction of URLs/emails to a domain and the common DKIM selector list. The description's mention of 'your selector or 15 common ones' largely restates the schema, 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?

States a specific verb and resource ('checks a domain's email authentication') and enumerates exactly what is parsed: SPF, DMARC, DKIM keys and MX. It also names the concrete return artifacts (A-F grade, 0-100 score, coded issues), which clearly separates it from siblings like dns_lookup and email_mx_verify.

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 three explicit use cases (judging spoofability, debugging deliverability, vetting a sender/vendor domain), which is well above generic 'use this tool' filler. It does not, however, contrast itself with the nearest alternatives such as email_mx_verify or dns_lookup, so a routing decision still requires 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 cover safety (readOnly, idempotent, non-destructive, openWorld), but the description adds behavior the annotations cannot: no mail is sent and no SMTP connection is opened, the possible verdict values, the explicit epistemic limit (mailbox existence is not provable), the $0.01 USDC cost, and the two-step x402 payment retry flow. Cost and payment mechanics are exactly the kind of hidden behavior agents need disclosed.

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?

Information-dense with no filler: the check enumeration, verdict set, limitation, usage trigger, price, and payment handshake each occupy one clause. The usage cue and payment caveat are front-loaded in positions an agent will read before invoking.

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 verification tool with no output schema, the description supplies everything needed: what is checked, what verdicts come back, the confidence ceiling, when to use it, and the paid-invocation protocol. No return-shape documentation is needed because verdicts are already named inline.

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% (the schema documents it with an example and length bounds), so the schema does the heavy lifting. The description adds no syntax, normalization, or format guidance beyond what the schema already states, which matches the baseline for high-coverage schemas.

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 (checks) plus a fully enumerated resource scope: syntax, domain, MX records, A/AAAA fallback, RFC 7505 null MX, disposable list, role account and free provider. This is clearly distinguishable from siblings like dns_lookup (generic DNS) and email_auth_check (SPF/DKIM/DMARC), which the description implicitly excludes by scoping itself to MX-only verification.

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

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

Gives a concrete usage context ('use when an agent validates a signup, lead or contact email before using it') and a clear limitation boundary ('cannot prove the mailbox itself exists', 'no SMTP'). It does not name a sibling tool as an alternative nor say when to prefer email_auth_check, so it stops short of full when/when-not 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 establish that this is a read-only, idempotent, non-destructive, open-world call. The description adds crucial behavior beyond that: it is a paid tool costing $0.01 USDC on Base, requires a two-step x402 payment flow, and returns specific verdict 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?

Four dense sentences with zero waste: purpose is front-loaded, return values follow, then usage trigger, then payment mechanics. Every sentence earns its place and supports correct invocation.

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 supplies the return shape (sanctioned true/false, verdict, SDN entity name, sdnType, programs, publish date). It also covers cost, payment protocol, and usage context, so an agent has 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?

Schema coverage is 100%, so the schema already documents the sole address parameter, including format examples. The description still adds value by naming supported chains beyond the schema examples (XMR, every chain OFAC lists).

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 (screens) and resource (crypto wallet address) against a precisely named source (US Treasury OFAC SDN list), and enumerates supported chains. It is clearly distinguishable from all siblings, which cover DNS, email, URL, and whois checks, not sanctions screening.

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

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

Gives an explicit trigger: use when about to send funds to, pay, or accept funds from an unfamiliar wallet. It does not name alternatives or when-not cases, but no sibling tool overlaps with this function, so the guidance is contextually clear.

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 mark this read-only, idempotent, non-destructive, and open-world, but the description adds much more: a 10-hop cap, the fact that page bodies are never read, the full list of safety flags computed, the low/medium/high risk scale, and the two-step x402 payment handshake. That payment flow is the kind of operational detail annotations cannot express and would otherwise strand the agent on a PaymentRequired response.

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 outcome, then the flags, then the when-to-use, then cost and payment mechanics — a sensible ordering with no filler sentences. The flag enumeration and the payment retry sentence are dense, but each clause conveys information an agent actually needs before calling.

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, yet the description compensates by naming every returned element (final URL, status, chain, the nine flags, risk level), and it covers the non-obvious paid-invocation protocol. For a one-parameter tool, nothing needed to call it correctly or interpret the result 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 'url' parameter already documents the example, length bounds, https:// normalization, and refusal of private/loopback hosts. The description adds no parameter-level detail beyond what the schema already provides, 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 ('follows a URL's HTTP redirects hop by hop') and enumerates exactly what is returned: final URL, status, full chain, and named heuristic safety flags. It is unmistakably distinct from siblings like dns_lookup, whois_domain_age, and email_auth_check, which operate on domains or mail infrastructure rather than on a single link's hop chain.

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

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

Gives an explicit trigger ('Use before an agent clicks, fetches or forwards an unfamiliar or shortened link') and an explicit exclusion ('Not a malware-reputation lookup'), so the agent knows both when to reach for it and when to look elsewhere. The cost line ($0.01 USDC) also lets the agent weigh it against free sibling lookups.

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, and the description adds material context beyond them: unsupported TLDs return 400 uncharged, the $0.01 USDC cost, the x402 PaymentRequired handshake and retry with params._meta['x402/payment'], and the absence of personal contact data. These are exactly the operational facts an agent needs before invoking a paid, open-world tool.

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 what is returned, then usage, then error and payment behavior. Dense but every clause carries information; the payment-handshake sentence is verbose but necessary for correct invocation.

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, and it additionally covers the error case (400 for unsupported TLDs), the cost, and the two-step payment flow. An agent has 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?

Schema description coverage is 100% and the schema already explains normalization of URLs/hostnames/emails to a registrable domain plus the 'name' alias. The description adds nothing about the single domain parameter, so the baseline of 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 (looks up a domain in its registry's RDAP server) and enumerates the returned data fields (registration date, age, newlyRegistered, expiry, registrar, EPP status, nameservers, DNSSEC). It also distinguishes itself from siblings like dns_lookup by noting RDAP is the WHOIS successor and by returning registrar/registration metadata rather than DNS records.

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?

Explicitly states when to use it: judging whether a domain, sender or vendor is brand-new as a phishing/fraud signal. It does not name alternatives (e.g. dns_lookup or url_unshorten) or state when not to use it, but the triggering context is clear and actionable.

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