VerifyPulse: email deliverability checks

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

With no annotations, the description carries the full burden and does well: it discloses that DKIM verification only works when the body is included, that SPF/DMARC policy and receiving-server records are consulted, and that the tool is free. It omits rate limits, whether input is retained, and any failure modes.

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 cost and purpose, then the checks, then the return shape. Every clause carries information an agent needs; no filler or restatement of the tool name.

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 input forms, the checks performed, the headers-versus-body caveat, and the shape of the result ('reasons in plain words'). Nothing essential for 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?

Schema coverage is already 100%, so the baseline is 3, but the description adds real semantic value: it explains the two acceptable input forms and the consequence of each (headers-only degrades DKIM verification). That is meaning the schema description does not convey.

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: explain why a message passed or failed authentication or landed in spam. It enumerates exactly what is examined (DKIM, SPF authorization, DMARC alignment/policy, receiving-server records, per-hop delays), which clearly separates it from siblings like verify_email or check_blocklists.

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 diagnostic trigger is clear: use it when you need to know why a message was rejected or spam-filtered, and it tells you the input can be the raw message or headers only. However, it never names an alternative tool (e.g. verify_email) 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?

With no annotations, the description carries the burden and does so reasonably: it discloses the free-tier quota, that MTA-STS policy is checked against the MX hosts (a real DNS-lookup behavior), and that the response includes a reusable snapshot. It stops short of stating read-only/safety posture, error handling for invalid domains, or latency despite multiple DNS lookups.

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 dense sentence with no filler, and the cost/limit constraint is front-loaded before the capability list. The long enumeration of output fields is informative rather than padding, 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?

No output schema and no annotations exist, so the description must cover both purpose and return shape — it enumerates every returned field and the snapshot for reuse. Quota, batching, and downstream chaining are all present; nothing essential for a correct call 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?

Only one parameter and schema coverage is 100%; the schema already says 'Up to 3 domains'. The description's 'Free for up to 3 domains per call' repeats the same constraint without adding format, normalization, or duplicate-handling guidance, 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?

Uses a specific verb (audit) plus resource (sending domains) and enumerates exactly what the result contains: grade, SPF lookup count, DMARC policy, DKIM status, MTA-STS, TLS-RPT, BIMI and fixes. It also distinguishes itself from the sibling monitor_sending_domains by positioning its output as a snapshot to hand off later.

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?

'Free for up to 3 domains per call' signals this is the batched, one-shot audit path and implies larger lists must be chunked. The handoff 'snapshot to pass to monitor_sending_domains later' gives a clear workflow position, though no explicit when-not-to-use or comparison against inspect_domain_dns is 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?

With no annotations, the description carries the full burden and does well: it discloses cost ('Free'), the exact query scope, the deliberate exclusions (subscription-gated lists), and that domain inputs trigger MX and A resolution. It does not mention rate limits, error behavior, or response shape beyond 'the result says which lists were checked'.

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 tight sentences with no filler; the cost signal and the scope/exclusion information are front-loaded. The leading 'Free.' fragment is slightly abrupt but earns its place in a paid-API context (cf. get_x402_payment_endpoints).

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 covers what it checks, what it skips, and why. Only the shape of the result (per-list verdicts vs. a summary flag) is left underspecified.

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 single parameter is documented, but the description adds real meaning beyond 'IPv4 address or domain': it explains that a domain's MX and A records are resolved and each checked against the 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 check (blocklist listing status) against a named resource (SpamCop and PSBL) for named input types (IPv4 or a domain's MX/A addresses). This is clearly distinct from siblings like inspect_domain_dns or check_tls_certificate, though no sibling is named 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?

Usage is implied by the purpose, and the description usefully states which lists are out of scope (Spamhaus, Barracuda require subscriptions), which helps an agent decide whether this tool suffices. However, no alternative tool is named and there is no explicit 'use this when...' framing.

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 no annotations, the description carries the burden, and it does disclose one real behavioral trait — the check is 'Free' — plus the hard scope limit of port 443. It does not say whether the call is a live network lookup, what happens on connection failure or timeout, or whether a validation failure is returned as data rather than an error, which matters for a network probe.

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 front-loads the resource and then the returned fields; the one-word 'Free.' sentence earns its place as a cost signal. Nothing is padded.

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 describe return values, and it does so compactly (validates, issuer, names covered, expiry, days left). The remaining gap is failure/error behavior for unreachable or non-TLS hosts, which is minor for a simple one-parameter 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 coverage is 100% and there is only one parameter, so the schema already documents 'host' including a format example. The description adds only the implicit constraint that the host is probed on port 443; it adds no format or edge-case guidance 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 names the concrete resource (the TLS certificate served on port 443) and enumerates what is reported: validation result, issuer, covered names, expiry and days left. That is far more specific than a tautology and clearly separates it from siblings like check_blocklists or inspect_domain_dns, though the verb itself is implicit rather than stated.

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 it should call this when it needs certificate/expiry data for a host. There is no explicit when-to-use, no note about what it does not cover (e.g. non-443 ports, STARTTLS on mail servers, which several email-focused siblings might imply), and no named alternative.

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 zero annotations the description carries the full burden. It helpfully discloses that the lookup is free and registry-sourced and interprets the new-registration flag as a fraud signal, but says nothing about failure modes (unregistered or invalid domains), rate limits, or whether results are cached — material gaps for a read-only external lookup.

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, no waste. 'Free.' is front-loaded as the first thing an agent needs to know, followed by the returned field list and then the interpretation of the risk flags.

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 enumerating the returned fields and explaining what the flags mean. Only the absence of error/edge-case behavior and cost/rate context keeps it from being fully 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?

There is a single parameter at 100% schema description coverage ('Domain, for example stripe.com'), so the schema already fully documents it. The description adds no constraint on format (apex vs subdomain, IDN, trailing dot), so 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 the exact resource (RDAP registration data for one domain) and enumerates the returned fields: registration date and age, expiry, registrar, status codes, nameservers, DNSSEC. That is specific enough to separate it from the DNS-oriented sibling inspect_domain_dns 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?

Usage is implied rather than stated: 'a strong spam and fraud signal' suggests due-diligence and abuse-triage scenarios, and 'about to expire' hints at renewal monitoring. But there is no explicit when-to-use/when-not, no prerequisites, and no named alternative among the ten 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?

With no annotations, the description carries the full burden and does disclose meaningful traits: it is 'Free' (cost), it performs DNS resolution of includes, and it returns records to publish rather than mutating DNS itself, implying a read-only operation. It omits failure behavior (missing/invalid SPF) and any rate limits, 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 tight sentences with zero filler; the cost note and the core action are front-loaded, and the trigger condition closes the description. Every sentence earns its place.

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 supplies purpose, trigger condition, and the nature of the return value ('TXT records to publish'). 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% and the schema documents the single 'domain' parameter, so the baseline is 3. The description's phrase 'a domain's SPF record' is consistent with the schema but adds no format or validation detail beyond it.

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 transformation (replace SPF includes with resolved IP ranges) plus the concrete output (TXT records to publish). This is clearly distinguishable from siblings like inspect_domain_dns or audit_sending_domains, which inspect rather than rewrite.

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 condition: 'Use it when an SPF record is at or over the 10-lookup limit.' It does not name alternatives (e.g., inspect_domain_dns to first count lookups) or state when not to use it, but the when-to-use context 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?

With zero annotations the description carries the burden and does it well: it discloses the paid gate, exact price and rails ($0.25 USDC on Base, or 250 credits via api_key), the free-preview fallback, and that records come ordered with a reason each. It stops short of stating whether anything is written to DNS or any rate limits.

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 front-loaded sentences, each earning its place: what it fixes, what it returns, how payment works. The parenthetical pricing detail is dense but necessary; nothing is redundant.

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 correctly specifies the return shape and ordering plus the payment/free-advice semantics, leaving little ambiguity for a two-parameter read tool. Lacks only side-effect confirmation and any failure-mode guidance.

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 documented in the schema, including that api_key pays 250 credits instead of x402. The description largely restates that, adding no new format or constraint detail, so 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?

Specific verb+resource: 'Fix a domain whose email goes to spam or fails SPF, DKIM or DMARC', with the return payload spelled out (host, type, value). It implicitly separates itself from analysis/inspection siblings ('fix' vs 'analyze'/'inspect'), but never names one outright.

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 trigger condition is explicit (spam placement or failing SPF/DKIM/DMARC), and the payment branches are given rules (no payment = free preview; no records needed = free advice). No exclusion against pick-one alternatives like analyze_email_authentication or flatten_spf.

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?

No annotations are provided, so the description carries the full burden. It discloses what the call returns (paid endpoints, USDC prices on Base, free endpoints) but says nothing about authentication, rate limits, caching, or whether the catalog is static or live; "List" only weakly implies read-only.

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 sentence, no filler, and the payload (paid endpoints and their prices) is front-loaded ahead of the secondary free-endpoint mention. Every clause earns its place.

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 no parameters, the description must convey the return shape, and it does: paid endpoints plus prices in a named currency/chain, and free endpoints. What is missing is only ancillary behavior (auth, freshness), which is minor for a static-catalog listing 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless schema is 4. The description consumes no space on parameters it does not have.

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?

"List the paid HTTP endpoints, their prices in USDC on Base, and the free endpoints" gives a specific verb (List) plus a precisely scoped resource, and even names the fields returned (prices, currency, chain). It is unmistakably distinct from the email/DNS siblings (verify_email, flatten_spf, inspect_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 intent to enumerate endpoints is implied by "List," so an agent can infer when to reach for it, but there is no explicit when-to-use statement, no exclusions, and no mention of alternatives or prerequisites. Adequate but with clear gaps.

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 no annotations, the description carries the burden and does well: it discloses cost ('Free'), the exact audit scope, the DNS lookup limit of 10 and that a true count is computed, and that a grade plus fixes are returned. It stops short of stating rate limits, permissions, or that the operation is read-only.

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 tightly packed sentences with no waste: scope and cost are front-loaded, then the checklist of checks and the return value. Every clause earns its place.

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, but the description compensates by naming the return ('a grade and the fixes to make') and detailing every check performed. With full param coverage and complete audit scope, the definition is close to self-sufficient.

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 already documented with an example in the schema. The description adds no format or syntax detail beyond what the schema provides, so a 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 ('Audit one sending domain') and enumerates the exact checks performed: MX hosts, SPF with includes expanded, DMARC policy with inheritance, and published DKIM keys. The singular 'one sending domain' implicitly differentiates it from the plural sibling audit_sending_domains.

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?

'Free' hints at cost context and the single-domain scope implies when it applies, but there is no explicit when-to-use versus audit_sending_domains, flatten_spf, or verify_email, and no when-not guidance. Usage is inferable but not 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?

No annotations exist, so the description must carry the behavioral burden, and it does disclose the important traits: stateless server (stores nothing), baseline behavior on first call, and a per-call volume constraint of 3 domains. Missing is what actually happens when more than 3 domains are passed (hard error vs. paid tier) and whether the operation is strictly read-only. Still well above the bar for an unannotated 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?

Four tight sentences with no filler. The only ordering nit is that the pricing/limit note leads before the tool's actual purpose is stated, so an agent's first read is a billing constraint rather than what the tool does.

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-value explanation and does so adequately: a baseline on the first call, snapshots for later calls, and a change report thereafter. The shape of the diff itself (per record type, per domain) is implied but not specified, which is a minor gap for an agent parsing 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 3 is the baseline, but the description adds a non-obvious mapping: the `snapshots` object from the response becomes the `previous` input, and it must be omitted on run one. That round-trip relationship is not derivable from the schema alone. The 3-domain limit is restated but the >3 case is not clarified.

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: reports DNS/email-auth record changes (SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT, BIMI) since a previous run. The record-type enumeration makes the scope unambiguous. It does not explicitly differentiate itself from siblings audit_sending_domains or watch_sending_domains, so an agent still needs to infer how this differs from a plain audit or a watcher.

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 concrete operational flow: pass the previous call's `snapshots` object as `previous`, and the first run returns a baseline with no changes. That tells the agent how to sequence repeated calls. It stops short of stating when to pick this over audit_sending_domains or watch_sending_domains, which is the one remaining routing gap.

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 no annotations at all, the description must carry the full behavioral burden, and it does well on cost (one credit or $0.01 USDC on Base per call), authentication (vp_ API key or a Base tx hash, with the /v1/agent/provision endpoint yielding 100 free credits) and on the key limitation that only the domain is validated. It says nothing about response shape, error or invalid-input behavior, or rate limits.

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 compact sentences, front-loaded with what is checked, then scope caveat, then pricing and auth. Dense and mostly waste-free, though the provisioning endpoint detail is a slight detour from the tool's own behavior.

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 effectively previews the return content by enumerating the signals reported (syntax, domain acceptance, typo, disposable, shared mailbox). Pricing and auth are complete; only the precise response format and failure modes are left implicit, which is acceptable but not exhaustive.

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 are already documented, and the description correctly reinforces that api_key may be either a vp_ key or a 0x transaction hash by tying it to the credit-versus-x402 pricing. The email parameter itself gains no extra semantics beyond the schema 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?

States a specific verb (check) and resource (an email address) and enumerates exactly what is examined: syntax, domain mail acceptance, typo suggestion, disposable and shared-mailbox flags. The clause 'Checks the domain, not the individual inbox' cleanly separates it from the sibling domain-level tools such as inspect_domain_dns and audit_sending_domains.

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 condition for use (email-level verification) and an explicit scope warning that the individual inbox is not checked, which stops an agent from over-trusting a pass. It also documents the two payment paths, but never names a sibling tool as an alternative or states when not to call 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?

With no annotations, the description carries the full burden and does so: it discloses the side effect (registers a persistent watch that POSTs JSON to the webhook), the pricing model and free-tier expiry (3 domains, renew every 30 days), the two payment paths (x402 payment in params._meta or api_key credits), and that a token is returned.

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 core action before the payment mechanics, and every clause carries information. It is dense, running several concepts into one long sentence, but nothing is genuinely wasted for a tool this involved.

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?

Covers registration, alert delivery, pricing, the two payment routes, and that a token is returned to list/delete the watch. The main remaining gap is the shape of the webhook JSON payload, which matters for someone wiring up the endpoint, but the operational essentials are present.

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 all four parameters are already documented in the schema; that establishes a baseline of 3. The description does add the pass economics ($2 for up to 50 domains) and the x402/payment payment field, but those are largely restatements of what api_key and guard_pass already say.

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?

Opens with 'Hosted monitoring' and states a concrete verb+resource: registering domains for a daily server-side check of a named record set (SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT, BIMI). It is clear what the tool does, but it never distinguishes itself from the sibling monitor_sending_domains or audit_sending_domains, which an agent could easily confuse it with.

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 usage condition (register when you want daily server-side checks with webhook change alerts) and an explicit branching rule: free for up to 3 domains, call without a pass for 4-20 domains to receive an x402 payment request. No guidance is given on when to prefer this over the sibling monitoring/audit tools, so the alternatives axis is missing.

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