Email Auth Checker

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

Annotations only cover readOnlyHint and openWorldHint, so the description adds meaningful context: deterministic/non-AI behavior, the organizational-domain fallback when no record exists, and the x402 pricing model with five free calls per day per client. The cost and rate-limit disclosure is exactly the kind of operational detail annotations cannot carry, though failure modes (no record found, malformed record) are not described.

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 core action and scope, followed by the commercial terms. The enumerated field list is dense but earns its space as return-value disclosure. 'Deterministic, no AI' is mildly promotional but does convey a real behavioral property.

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 correctly compensates by listing the record components returned plus the RFC 7489 section governing external report authorization. Combined with the fallback and pricing disclosures, an agent has enough to call this correctly, though error/empty-result behavior is 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?

There is a single parameter with full schema description coverage, so the baseline is 3. The description's mention of falling back to the organizational domain slightly clarifies how the input domain is resolved, but adds no format, normalization, or validation details beyond the schema's example.

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 pair (finds and validates) and resource (a domain's DMARC record), then enumerates the exact fields extracted (policy, subdomain policy, pct, alignment modes, rua/ruf, external report authorization). This makes it clearly distinguishable in substance from spf_lookup_count and email_auth_report, though it never names or contrasts 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?

The description implies usage via the organizational-domain fallback and the pricing/free-tier note, which tells the agent this is a paid, per-call lookup. However, it gives no explicit when-to-use guidance, no prerequisites, and no steering toward or away from the sibling tools, leaving the selection decision largely 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 readOnlyHint and openWorldHint, but the description adds genuinely new operational context: deterministic/no-AI behavior, per-call cost ($0.002 USDC via x402 on Base), and a free-tier rate limit of 5 calls/day/client. Cost and rate-limit disclosure is exactly the kind of behavior structured annotations cannot carry.

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

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

Front-loaded with purpose, then the field list, then applicability, then pricing — a sensible priority order with no filler sentences. The field enumeration is dense but each item earns its place since 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?

With no output schema, the description compensates by enumerating return fields and even the derived status vocabulary (ok/expiring_soon/expired), plus cost and coverage limits. An agent has everything needed to decide to call it and to 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?

Only one parameter and schema description coverage is 100%, so the schema already fully documents `domain` (including an example). The description adds no format, normalization, or edge-case guidance (e.g., IDN, subdomains) beyond what the schema provides — baseline 3.

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 (domain registration data) and source (registry RDAP server via IANA bootstrap), then enumerates the exact returned fields: registrar, dates, EPP status, nameservers, DNSSEC. This is unmistakably distinct from the email-authentication siblings (dmarc_check, spf_lookup_count, email_auth_report), which operate on DNS TXT records rather than registry 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?

"Works for gTLDs and ccTLDs that publish RDAP" gives a clear applicability boundary that implicitly excludes non-RDAP TLDs, so an agent knows when this will fail. It stops short of naming alternatives or stating explicit exclusions (e.g., what to do for a TLD without RDAP coverage).

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 read-only and open-world, yet the description adds substantial behavioral context they don't: deterministic DNS-over-HTTPS, no AI, per-call pricing ($0.003 USDC via x402 on Base), and a free tier (first 5 calls/day/client). This pricing/rate-limit/payment detail is exactly the context an agent needs before invoking.

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 it is front-loaded with the resource and each clause (check list, determinism claim, pricing) carries information. It is tightly packed rather than padded, though the enumeration-heavy style is borderline crowded.

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 burden of conveying what comes back, and the enumerated check list plus the 'readiness verdict' gives a solid content overview. It stops short of describing the response format or structure, which is the one remaining gap for a report-style 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 baseline is 3, and the description exceeds it by explaining the default-vs-custom selector behavior: DKIM keys are probed at 'common selectors or your own via selectors='. That default behavior is not evident from the schema alone, adding real meaning.

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 ('Full email-auth report for a domain') and enumerates exactly which checks it covers (SPF, DMARC, DKIM, MX, MTA-STS, TLS-RPT, BIMI, bulk-sender verdict). The 'full report' framing plus the enumerated scope implicitly distinguishes it from the narrower siblings dmarc_check and spf_lookup_count.

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 'Full' and the check list imply this is the comprehensive umbrella option versus the single-check siblings, and the bulk-sender verdict hints at its intended use case. However, it never explicitly says when to prefer this over dmarc_check or spf_lookup_count, nor names any exclusion, so routing 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?

Annotations already declare readOnlyHint and openWorldHint, and the description adds real value on top: deterministic/no-AI behavior, RFC limits applied, presence of permerror causes and warnings, and the x402 USDC payment model with a 5-calls-per-day free tier. Only latency/timeout or failure-mode caveats are absent.

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 behavior, followed by return contents and cost. Dense but every sentence carries information an agent needs; the pricing sentence is slightly tangential but genuinely decision-relevant.

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 does summarize what comes back (per-term lookup costs, problems, warnings) and explains the counting rules. For a one-parameter, read-only tool this is essentially complete, though it omits any statement about error responses when a domain has no SPF record.

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 required 'domain' parameter with 100% schema description coverage and an example, so the schema already carries the semantics. The description adds nothing about accepted domain formats (bare domain vs URL vs trailing dot), 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 (expands recursively) and resource (SPF record + RFC 7208 lookup/void-lookup counts), including include/redirect traversal. This clearly separates it from the siblings dmarc_check, domain_expiry and email_auth_report, which cover different resources.

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 rather than stated: an agent can infer this is the tool for auditing SPF lookup limits, but the description never says when to prefer it over email_auth_report or how it relates to dmarc_check. No explicit when-not or prerequisite guidance is given.

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