OrionCMD Checks

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

Annotations cover the read-only/idempotent/no-destruction profile, and the description adds substantial extra context: DNS resolution is performed on each domain and the resolved IPv4 is also matched, the feed is 30-day high-confidence IOC, no ransomware lookups, a stale feed returns an error, and billing terms ($0.50 USDC per call, not charged on stale/invalid/upstream failure, payment in _meta['x402/payment']).

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 appropriately sized: three sentences covering scope, sibling routing, feed behavior, and billing. Slightly packed with billing/wrapper details, but every clause earns its place and the core capability is front-loaded.

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-param, no-output-schema tool, the description covers scope, limits, sibling alternatives, resolution behavior, feed freshness, failure modes, and payment mechanics. An agent has everything needed to invoke it correctly and interpret billing consequences.

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 items as 'Up to 100 domains/IPv4, comma or newline separated' with maxLength 20000. The description repeats the 'up to 100 domains or IPv4' limit but adds no new syntax or format detail. Baseline 3 is appropriate when schema does the heavy lifting.

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+scope: 'Check up to 100 domains or IPv4 addresses at once against ThreatCluster's high-confidence 30-day IOC feed.' It explicitly distinguishes itself from the sibling threat_check ('use threat_check for one domain'). An agent can route between the two 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?

Explicit when-to-use (bulk domains/IPs) and when-not (single domain -> threat_check; ransomware claims not supported). Also states that stale feed and invalid input return errors with no charge, giving clear operational 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?

Goes well beyond the annotations by disclosing the data source (public Certificate Transparency logs via Cert Spotter with crt.sh fallback, not the live connection), the resulting caveat that a brand-new cert may not appear yet, the resource footprint (one HTTPS request plus one CT query, 1-5 s), and the billing model ($0.01 USDC via x402, payment in _meta['x402/payment'], errors not charged). This is exactly the operational context 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?

Four sentences, each carrying distinct load: purpose/outputs, sibling routing, data-source caveat, and cost/latency/error behavior. Scope and primary behavior are front-loaded ahead of the caveats, 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 carries the return-value burden and does so by naming the fields returned. For a read-only, single-parameter probe it also covers timing, cost, failure semantics, and the data-source limitation that affects interpretation of 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 description coverage is 100% for the single 'domain' parameter, so the schema already documents accepted formats (hostname or URL). The description's 'one hostname' phrasing reinforces single-target scope but adds no syntax or format detail beyond what the schema provides, 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?

States a specific verb+resource ('Check the TLS certificate of one hostname') and enumerates the exact output fields (issuer, validity dates, days left, % of lifetime used, renewal-stall flag, HTTPS probe). It explicitly distinguishes itself from sibling tools site_health and domain_grade, so an agent can route 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?

Gives an explicit when-to-use ('when you only need certificate health') paired with the alternatives and the condition that selects each: site_health for cert + DNS + expiry together, domain_grade for a scored A-F result. Nothing 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 cover readOnly/idempotent/openWorld, but the description adds substantial context beyond them: the upstream resolver (Cloudflare DoH at 1.1.1.1), that nothing is stored, the $0.01 USDC x402 cost with the payment field location, and that invalid input or upstream failure is uncharged. This is exactly the behavioral detail 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?

Three dense sentences with no filler: capability, routing to the sibling, then execution/cost semantics. Front-loaded with the primary purpose and 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 still communicates what is returned ('plain-English findings' plus the enumerated record types) and the full execution profile. Nothing an agent needs to invoke 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?

Only one parameter and schema description coverage is 100%, so the schema already fully documents 'domain' with examples. The description adds no additional syntax or format guidance beyond what the schema provides, 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?

States a specific verb ('Look up the live DNS') plus the exact resource scope, enumerating the record types returned (NS, A/AAAA/CNAME, MX, SPF, DMARC, CAA, DNSSEC). It explicitly distinguishes itself from the sibling check_email_auth, so an agent can route correctly.

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 two concrete use cases ('DNS inventory' and 'debug resolution') and names the alternative tool with the condition that selects it ('for a deeper SPF/DMARC/DKIM/MTA-STS review'). Explicit when-to-use and when-to-use-something-else.

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/non-destructive, but the description adds material context the annotations cannot: the $0.01 USDC x402 cost, where the payment goes (_meta["x402/payment"]), and the billing rule that invalid input or upstream failure returns an error without charge. It also discloses the found=false outcome for TLDs lacking RDAP, which shapes how the agent must interpret results.

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: what it returns, how it differs from check_cert, and payment/edge-case behavior. Each sentence is load-bearing and the primary purpose is front-loaded before the cost and edge-case details.

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 burden and does so by naming the result fields plus the found=false sentinel. Payment mechanics and error/charging behavior round out everything an agent needs 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% and the single 'domain' parameter already documents accepted forms (hostname or URL with example). The description adds no further syntax, normalization, or validation 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?

Specifies the verb (check), the resource (domain registration expiry), and enumerates the returned fields — registrar, dates, days left, EPP status, nameservers — so the agent knows exactly what it gets. It also explicitly separates itself from check_cert, avoiding the most likely sibling confusion.

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?

States the use case (renewal risk on the registered domain), names the alternative for the adjacent case (check_cert for certificates), and covers the important negative case where a TLD publishes no RDAP service and found=false explains why. When-to-use, when-not, and the sibling alternative are all present.

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, open world), and the description adds materially more: live DNS via Cloudflare DoH, no email is sent, the $0.01 USDC x402 charge with the exact _meta payment key, and that failed/invalid calls are not charged. It also discloses a real limitation — DKIM is only probed on common selectors, so 'not found' is not proof of absence.

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 purpose, then checks, then usage trigger, then caveats, then cost/failure semantics. Dense but every clause carries information an agent needs — 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?

No output schema exists, so the description carries the return burden and does: a rough 0-100 score plus plain-English fixes, and the specific record classes examined. It also resolves the payment and error semantics that would otherwise be invisible.

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 the schema already documents it at 100% coverage including the hostname-or-URL example. The description adds no format or parsing detail beyond the schema, 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 and resource ('Review the email authentication setup of a domain') and enumerates exactly which checks are run: SPF + lookup count, DMARC policy/pct/reporting, DKIM selectors, MTA-STS, TLS-RPT, BIMI. This clearly separates it from siblings like check_dns and check_security_headers, which cover unrelated 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 an explicit trigger context: 'Use it before sending mail from a domain or when mail lands in spam.' That is strong when-to-use guidance, though it names no sibling alternative (e.g. check_dns vs. this tool) and states no when-not-to-use condition.

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), and the description adds substantial behavior beyond them: a single live HTTPS GET, redirect chain capped at 5 hops, the body is not read or stored, and a $0.01 USDC x402 charge placed in _meta with a no-charge guarantee on invalid input or upstream failure. Cost and billing semantics are exactly the kind of context 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 action and the fetched artifacts, then the routing caveat, then cost/error behavior. Dense but every clause carries information an agent needs; 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 contract itself (redirect chain, final status, per-header results, A-F grade, findings) and also discloses billing and failure semantics. Nothing an agent needs to invoke or interpret the 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?

There is one parameter at 100% schema description coverage, so the schema already documents 'domain' with an example. The description refers only generically to 'a website' and adds no format, allowed-scheme, or normalization detail beyond the schema, 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 names a specific verb and resource ('Check the HTTP security headers of a website') and enumerates exactly which headers are inspected (HSTS, CSP, X-Frame-Options, COOP, etc.) plus the A-F grade output. That enumeration cleanly separates it from check_cert, check_dns, and check_email_auth, and the 'not a vulnerability scan' clause rules out the closest misread.

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 use context ('Use it for web-hardening checks') and an explicit exclusion ('it is not a vulnerability scan'), which prevents the most likely misselection. It stops short of naming the sibling to use instead (e.g., full_site_audit for a combined audit), so routing is left partly 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 cover read-only/idempotent/open-world safety, so the bar is lower. The description still adds substantial value: partial=true handling of unavailable categories, 3-10 s latency, x402 pricing ($0.03 USDC in _meta["x402/payment"]), and that errors are not charged. That is rich behavioral context beyond the 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 core purpose and verdict framing, then layers in categories, return shape, alternatives, and payment semantics. Every clause earns its place, though the single dense paragraph is longer than strictly needed for a one-parameter tool.

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 picks up the slack by describing exactly what comes back: one letter, a 0-100 score, per-category points, and top fixes. Combined with cost, latency, and partial-result semantics, 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 description coverage is 100% and there is only one parameter, so the schema fully documents the accepted hostname/URL format. 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 (grade a domain's security posture A-F) plus the scope of work it performs (TLS, DNS/DNSSEC/CAA, registration, email-auth, HTTP headers). It also distinguishes itself from siblings by positioning as the verdict tool rather than the raw-data checks.

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 says to use it when you want a verdict, and names alternatives (site_health and the single checks) for raw data. Also names the target scenarios (vendor-risk or due-diligence), leaving little 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?

Goes well beyond the readOnly/idempotent annotations: discloses the x402 payment mechanism and $0.04 USDC cost, that payment goes in _meta["x402/payment"], that partial failures still return partial results, and that invalid input or total failure is not charged. These are exactly the operational facts an agent needs before spending money on a 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?

Single dense paragraph that front-loads what the tool returns and when it applies, then appends failure and payment terms. Every clause carries distinct information — output fields, sources, partial-failure semantics, cost, non-charging conditions — 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 and no output annotations, the description fully compensates by naming each returned field and the aggregate result. It also covers the failure modes and billing implications of a paid, open-world network operation, leaving nothing an agent must guess before invoking 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 description coverage is 100% and the single parameter already documents the '2 to 5 comma-separated domains' format. The description restates the cardinality but adds no new syntax or edge-case guidance (e.g. duplicate handling, whitespace, max URL length) 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 (certificate and domain-registration expiry lookups) with explicit scope (2 to 5 domains in one call) and enumerates exactly what comes back: days left, expiry dates, ok/warn/expired status, soonest date overall. The batch scope plus the data sources (CT logs, RDAP) distinguish it clearly from single-target siblings like check_cert and check_domain_expiry.

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 2-to-5 domain batch constraint makes the intended use case obvious against the single-domain siblings, and the partial-failure/all-fail behavior tells the agent what to expect on mixed input. It never names an alternative tool explicitly, so selection against check_cert or check_domain_expiry 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/non-destructive, but the description adds substantial extra context: ~5-15s runtime, $2 USDC x402 payment passed in _meta['x402/payment'], and that failures or invalid input are not charged. These are operationally decisive facts the 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?

Dense but front-loaded: purpose first, then coverage, then return shape, then cost/failure semantics. The long parenthetical check list is justified by the tool's breadth, though it could be trimmed slightly.

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 contract itself: A-F grade and score, action plan sorted by severity with fix and effort, and raw sections. Combined with cost and failure behavior, an agent has everything needed to call and interpret this 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 description coverage is 100% and there is a single required parameter, so the schema already documents format and examples. The description adds only the implicit 'one domain' scope constraint, 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+resource ('full site audit report for one domain') and enumerates the checks it performs, so the agent knows the scope precisely. It explicitly differentiates itself from the sibling domain_grade ('Use domain_grade for just the letter').

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 use cases (client reports, vendor reviews, pre-launch check), names the narrower alternative and when to prefer it, and states failure/charging conditions. The when-to-use decision is fully resolved without opening a schema.

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, but the description adds genuinely new behavioral facts: it is free, makes no network request, and requires no payment. That answers the natural agent worry about whether merely checking prices costs anything.

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 tight sentence with the key fact ('Free') front-loaded, followed by exactly what is returned and the reason to call it. 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?

There is no output schema, so the description carries the burden of describing return values, and it does: per-tool prices, the network, and the receiving address. Nothing needed to call this zero-arg tool 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?

The tool takes zero parameters, so the schema baseline is 4. The description correctly signals 'No input,' which is consistent with the empty properties object.

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 (return the price of every paid tool) plus the extra fields returned (payment network Base, receiving address). It is instantly distinguishable from the diagnostic siblings like check_dns or full_site_audit.

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 use context — 'so you can budget before calling' — which tells the agent to consult it before invoking paid tools. It does not name alternatives or exclusions, but for a metadata endpoint none are really needed.

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/non-destructive, but the description goes well beyond them: per-call cost of $0.03 USDC via x402 with the payment location (_meta["x402/payment"]), the partial=true degradation when one or two sources fail, and the billing rule that errors are not charged. That is exactly the operational context an agent needs before invoking a paid 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?

Purpose is front-loaded and routing guidance follows immediately; nearly every clause carries usable information. The first sentence, however, is a dense run-on that bundles return contents, a dated flag and a certificate note, which slightly muddies scanning.

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 tells the agent what the response contains (raw sub-results, summary, renewal-stall flag, LE 64-day note) and how failures surface (partial=true). Combined with the pricing and error-billing rules, nothing needed to call or interpret this tool 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 exists and the schema already documents it at 100% coverage, including accepted hostname/URL formats, so the baseline is 3. The description adds nothing about the domain argument itself (no normalization, no example beyond the schema's own), so it neither compensates nor regresses.

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 concrete composite action — running check_cert, check_dns and check_domain_expiry together — and enumerates what comes back (raw results, summary, renewal-stall flag, 64-day cert note). It also explicitly distinguishes itself from the sibling domain_grade, so an agent can route without opening schemas.

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 when-to-use ('a full data dump in one call') and a named alternative with the condition that selects it ('use domain_grade if you want a single scored A-F answer that also covers email auth and HTTP headers'). It further explains the partial-failure path, which removes ambiguity about degraded runs.

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, non-destructive), and the description goes well beyond them: cache behavior and hourly refresh, stale-feed handling, the exact pricing model ($0.02 USDC via x402 in _meta), and that errors are not charged. It also warns that leak-site claims are unverified attacker assertions. This is rich behavioral 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?

The description is dense and fairly long, but it is front-loaded with the core question and each subsequent clause carries distinct information (mechanism, verdicts, caveat, failure/pricing). No filler sentences; slightly heavy for a single-parameter tool.

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 return verdicts (listed, claimed, listed_and_claimed, no_known_threat) and the matching reports. Error/payment semantics are fully covered, so an agent has everything needed to invoke 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?

With one parameter at 100% schema coverage the baseline is 3, but the description adds real meaning: it explains that the input hostname is resolved (A/AAAA) and matched both as the name, its parent domains, and resolved IPv4, clarifying what form of input is accepted and how it is used.

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 plus the mechanism sentence state a specific verb (check/resolve/match) and resource (domain against IOC feed and leak-site claims), so an agent knows exactly what this does. However, it never differentiates itself from the obvious sibling bulk_threat_check, leaving the single-vs-bulk choice implicit.

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 implied (look up whether a domain is known-bad) and the caveat 'No match is not proof of safety' usefully frames interpretation. But there is no explicit when-to-use/when-not or named alternative, and the sibling bulk_threat_check for multi-domain cases is never mentioned.

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 and closed-world, but the description adds behavior that annotations do not convey: it is free, performs no network request, and rejects malformed inputs outright. That is meaningful extra context for an agent deciding whether a call is safe and what failure means.

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 the most decision-relevant fact ('Free'), then the action, then the boundaries. No filler and nothing buried.

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 offline validator with no output schema, the description covers cost, network behavior, return value (normalized hostname) and rejection cases. Nothing an agent needs 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 the schema already shows the example formats, so the baseline is 3. The description adds semantics beyond the schema by stating the value is normalized to a hostname and by enumerating what input forms are rejected, which constrains what the single parameter will accept.

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 ('check that a domain or URL is well-formed') plus the payoff ('get the normalized hostname'), and positions it explicitly as the free pre-step to a paid check, which separates it from the paid check_* siblings. An agent can tell exactly what it does and does not do.

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?

Clearly signals the usage window: run this 'before calling a paid check'. It also lists rejection cases (IP addresses, single-label names, credentialed URLs), which is useful boundary information. It stops short of naming specific sibling tools as the alternatives, so it is clear context rather than fully explicit 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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that: the call is free (no quota/billing cost) and requires the creation-time webhook_secret as an auth credential, which an agent must know before calling.

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 dense sentences, front-loaded with the 'Free' cost signal and the resource identity, followed by the returned fields and the auth prerequisite. Slightly list-heavy 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?

There is no output schema, so the description usefully enumerates what the status payload contains and flags the auth requirement and zero cost. That is enough for an agent to call it correctly, with only error/not-found behavior left unstated.

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%, with both watch_id format (ocw_ pattern) and webhook_secret provenance already documented in the schema. The description restates the webhook_secret requirement without adding syntax, format or failure-mode detail, so the schema is doing the heavy lifting.

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: retrieves status of a paid domain watch, and enumerates the fields returned (items, expiry, last check, DNS/IOC/claim state, webhook delivery). It also anchors the resource to its creation endpoint (HTTP POST /v1/watch), which clearly separates it from the check_* siblings, 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?

Makes the usage context clear: this is for a watch that already exists (created via POST /v1/watch) and requires the webhook_secret issued at creation. It does not name alternatives or state when-not-to-use, but the precondition framing leaves little ambiguity about when to reach for it.

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