Agent Data Tools: Compliance and checks

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

Annotations cover safety (readOnly, non-destructive, openWorld), and the description adds real value beyond them: cost model ($0.01/call, first 25 free, failed calls free) and the explicit note that each call is charged so repeats are not free — which meaningfully explains the idempotentHint=false. It also discloses output shape (block/review/pass with reasons) and a legal disclaimer, though no rate limits or latency expectations.

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 opening sentence is one long semicolon-chained clause that is dense to parse, and the instruction "Use before paying, trading with or onboarding an address" nearly duplicates the opening "Screen a payee before paying, trading or onboarding." Pricing and disclaimer content is useful, but the block is longer than it needs to be.

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

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

With no output schema, the description still tells the agent the return is a block/review/pass verdict with reasons, plus cost and per-call charging. Missing only scoring detail or how to interpret a partial (e.g., domain-only) result, which is a minor gap for a 3-parameter read-only 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%, so all three parameters (address, chain enum, optional domain) are already documented. The description restates the chain list and the domain's effect (domain age and trust flags) plus an example address, but adds no syntax or format detail the schema lacks. 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 (screen/vet) and resource (payee EVM address) plus scope: OFAC SDN match, account type, holdings, Base risk checks, optional domain signals. Clear enough to be actionable, but it never distinguishes itself by name from close siblings like check_payee or sanctions_check, which an agent selecting among 25 tools would need.

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?

"Use before paying, trading with or onboarding an address" gives a clear situational trigger. There are no explicit exclusions or named alternatives (e.g., when to prefer sanctions_check or check_x402_seller), so routing among overlapping siblings is still 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?

Adds real context beyond the annotations: pricing ($0.005/call, first 25 free, failed calls free), which explains why idempotentHint=false since repeats are charged, plus the output shape (pass/review/block with reasons) and the "screening aid, not legal advice" limitation. "Reads or computes only and changes nothing" largely restates readOnlyHint, but the charging semantics justify it.

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

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

Purpose is front-loaded in the first clause, but the description is a dense run-on that repeats the chain enum verbatim and splits pricing across two places ("$0.005/call ... first 25 free" and "each call is charged, so repeats are not free"). Several clauses could be consolidated without losing 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 does the necessary work by describing the verdict shape (block/review/pass with reasons) and the legal-advice caveat. Missing only edge-case behavior, such as what a passing verdict looks like when the domain is omitted or how a partial OFAC match is reported.

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 baseline is 3; the description goes slightly further by explaining that the optional domain parameter unlocks domain age and trust flags, and supplies a worked address example. It does not add anything about failure modes for an invalid or non-EVM address.

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 (payee screening) and enumerates exactly what is checked: OFAC SDN match on the address, account type and nonce on named chains, optional domain age and trust flags. It also names the sibling it is not (holdings/wallet heuristics → check_counterparty), so an agent can separate the two 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?

"Use before an x402 or USDC payment to an unfamiliar address" gives a clear trigger condition, and it explicitly routes holdings/wallet heuristics to check_counterparty. It stops short of routing other adjacent siblings (sanctions_check, check_x402_seller, domain_report), which would have been the natural exclusions for an OFAC/domain tool.

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?

It discloses a lot beyond the readOnly/openWorld/idempotent annotations: it does not sign transactions, it does not touch the endpoint's state, each call is charged so repeats are not free (which explains the non-idempotent hint), and the verdict format is 'review or pass with reasons'. Cost and the legal-disclaimer caveat are exactly the kind of context 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?

The purpose is front-loaded and each clause carries real information, but the pricing boilerplate ('$0.01/call via x402 USDC or a card key (/credits), first 25 free; failed calls free') and the specific worker example URL are noise an agent does not need to select or call the tool. The single dense semicolon-chained sentence is also hard to scan.

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 conveys the return shape ('review or pass verdict with reasons'), the checks performed, and the free-of-side-effect guarantee. The parameter is fully documented. Only the exact verdict fields and what happens on an unreachable or non-402 endpoint are left to discover.

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 only one parameter and the schema already describes it fully at 100%: an absolute public https URL, including any query string. The description adds an example URL, but no extra syntax or constraint beyond what the schema says. 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 opens with a specific verb+resource+scope: auditing an x402 seller's 402 terms, payTo addresses, domain and assets before an agent pays. That is far more specific than a generic 'check'. It never names the near-identical sibling x402_check, so what separates the two is not stated 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?

Use is clearly labelled: 'Use before the first payment to an unfamiliar x402 seller.' It also says 'Never signs' and 'Screening aid, not legal advice', which sets limits on when the verdict is enough. No alternative tool is named, so there is no explicit 'use X instead when…' guidance.

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

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

Annotations already declare read-only/non-destructive, and the description adds substantial context beyond them: CC0 licensing, 404-on-no-match behavior (uncharged), failure calls free, per-call pricing and payment routes, and an explicit reconciliation of why repeats are not free despite being a pure read. That last point usefully explains the idempotentHint=false, which would otherwise look odd for a read-only tool.

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

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

Front-loaded with the useful field list, but the tail is dense and partly redundant: price and 'failed calls free' appear in one sentence, then 'each call is charged, so repeats are not free' restates the billing point. Payment-rail detail (x402 USDC, /credits key) is relevant to cost but crowds out structure in a single undifferentiated paragraph.

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 only two optional parameters, no nested objects, no output schema, and near-zero complexity, the description covers everything needed: the returned fields are enumerated, error behavior and cost are stated, and the read-only nature is explicit. Nothing an agent needs before calling 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 both parameters are self-documented ('Wikidata item ID such as Q689141, instead of name'; 'give name or id'). The description restates the either/or choice and adds one worked example (name=Spotify), which is mildly helpful but adds no format or disambiguation rules beyond the schema. 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 resource (company facts) with explicit input modes (name or Wikidata ID) and enumerates the exact fields returned: website, founding date, HQ, industries, CEO, founders, parent, employees, tickers, LEI, and external links. An agent can immediately distinguish this from siblings like domain, sec_filings, or check_counterparty without opening the 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 concrete use cases (enrich leads, vendors, counterparties; ground an answer about a company) plus a scoping constraint ('best for established and listed companies'), which implies when NOT to use it. It stops short of naming which sibling to use for private/early-stage companies or for financial filings, so it is clear context without explicit alternatives.

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: discloses the data source and license (Wikidata, CC0), the uncharged-404 no-match behavior, per-call price ($0.01 via x402 USDC or card key), the 25-free allowance, and that repeats are charged. This is consistent with readOnlyHint=true and idempotentHint=false rather than contradicting them.

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 and inputs are front-loaded, then fields, then pricing and safety notes; nearly every sentence carries information. Minor redundancy: 'Reads or computes only and changes nothing' largely repeats readOnlyHint, and the title restates the same scope.

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 usefully enumerates the profile fields returned and covers the no-match case and cost model. It does not describe response structure or how sparse Wikidata records may be, but 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 100%, so the baseline is 3; the description mainly restates the two inputs and adds a worked example. It also advertises 'website domain' as a lookup key while the schema exposes only id and name, leaving the agent to guess how a domain is passed.

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

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

Names a specific verb+resource (company lookup by name, website domain or Wikidata id) and enumerates the returned profile fields, so an agent can distinguish it from sibling tools like lei_lookup, domain_whois or check_counterparty without opening the schema. The 'Example: name=Spotify' anchor makes the invocation concrete.

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

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

Explicitly states use cases (enrich a lead, vendor or counterparty; ground an answer about a business), which is clear when-to-use context. It stops short of naming an alternative tool or a when-not-to-use condition relative to siblings such as lei_lookup or company.

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, non-destructive, open-world and non-idempotent, and the description adds context beyond them: the DoH provider, per-call pricing via x402 USDC or card key, first 25 free, failed calls free, and the warning that repeats are not free (consistent with idempotentHint=false). It also discloses what is returned: TTL per answer, response code (NOERROR/NXDOMAIN) and DNSSEC validation status.

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 and record list are front-loaded, followed by use cases, then operational details. It is dense and every clause adds information, though the pricing parenthetical ('$0.002/call via x402 USDC or a card key (/credits), first 25 free; failed calls free') is somewhat cluttered.

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?

Despite no output schema, the description names the returned fields (TTL, response code, DNSSEC status), and for a two-parameter read-only lookup it covers cost, auth mechanism, and failure behavior. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the schema already documents name (including the URL-host behavior) and type with its full record list and default. The description only adds a usage example (name=example.com) and the default of A, so it does little beyond what the schema provides.

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 ('Look up DNS records of a domain') and enumerates the supported record types, plus the transport (DNS-over-HTTPS, Cloudflare 1.1.1.1). It is clearly distinguishable from siblings like dns_propagation, which it names.

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 when-to-use scenarios (check email via MX/SPF, verify a domain, debug a DNS change) and explicitly routes propagation checks to dns_propagation. That is an explicit alternative with a stated selection 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 declare readOnlyHint, destructiveHint=false and openWorldHint, but the description adds genuinely new behavior: what the response contains (per-resolver answers and TTLs, agreement flag, majority answer), the supported record types, and the cost model ($0.03/call, first 25 free, failed calls free, repeats charged). The only gap is that it does not explain why idempotentHint is false beyond the billing angle.

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 output contents and the when-to-use conditions are front-loaded in the first two sentences, and pricing is correctly relegated to the end. Slightly redundant phrasing ('Reads or computes only and changes nothing') repeats what the annotations already state.

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 only two parameters and no output schema, the agent needs to know what comes back and what it costs, and the description covers both (per-resolver answers, TTLs, agreement, majority answer, per-call price with free failures). Nothing required 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?

Schema coverage is 100%, and both parameters are already documented in the schema including the URL-host acceptance and the record-type list. The description restates the record types and gives a bare name example but adds no syntax or format 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?

The description gives a specific verb and resource (check whether a DNS change has propagated) and immediately pins down the mechanism: the same record queried at five named public resolvers. It also names the sibling dns_lookup as the single-lookup alternative, so an agent can distinguish the two without inspecting 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?

It states the concrete situations that call for this tool (old value still cached after a record change, hosting move, email setup) and explicitly routes one-off lookups to dns_lookup. A worked parameter example is included.

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/destructive=false, but the description goes further: it states the 8,000-character input cap, the shape of the response (line, severity, fix, plus a score, which matters since there is no output schema), and the billing model including 'failed calls free' and that repeats are charged, which meaningfully explains the idempotentHint=false. Behavior is fully disclosed beyond structured fields.

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

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

Purpose and the full check list are front-loaded, with the response shape, usage timing, and pricing at the end. Slightly bloated by the pricing/credits sentence and an inline multi-line example that disrupts the sentence flow, but nearly every sentence carries information.

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

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

For a single-parameter tool with no output schema, the description supplies the input limit, the finding structure, severity and score, cost per call, and failure billing. Nothing an agent needs to invoke or interpret the result is missing.

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

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

Schema coverage is 100% and there is only one required parameter, so the baseline would be 3. The description adds value by restating the 8,000-character limit and supplying a concrete example value that shows the expected raw-text format for the dockerfile field.

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 a Dockerfile') and then enumerates the exact classes of findings (unpinned base images, root user, curl|bash, secrets in ENV/ARG, ADD from URLs, cache retention, sudo, chmod 777, SSH port). An agent knows precisely what this does and that it is distinct from the many unrelated siblings.

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?

'Use before building or shipping an image' gives a clear trigger point in the workflow. There are no near-alternative siblings to disambiguate against, so explicit exclusions are not needed, but it also does not say when not to use it (e.g., for non-Dockerfile configs).

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, open-world, non-idempotent, and non-destructive behavior. The description adds useful context beyond annotations: payment and auth via x402 USDC or a card key, per-call cost, the first 25 free, failed calls free, and that repeats are charged. It still does not describe data freshness or failure modes in detail, but it meaningfully covers cost and access behavior.

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

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

The description is front-loaded and organized around outputs, use cases, the alternative tool, and cost. It is somewhat dense and repeats the read-only safety point already covered by annotations, but the extra payment and free-tier details are relevant for a paid 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?

For a complex multi-source domain lookup with no output schema, the description enumerates the returned intelligence and covers usage, the key alternative, pricing, auth, and safety. It is complete enough to select and invoke, though it does not specify response shape or edge-case behavior.

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 single required parameter is fully documented in the schema with an example, and the description repeats the same example without adding format constraints such as IDN support, subdomain handling, or URL rejection. With 100% schema coverage, the baseline of 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?

The description names a specific resource and enumerates the exact data it aggregates: DNS record types, DNSSEC status, registrar and registration dates with domain age, and SPF/DMARC email authentication. It also explicitly distinguishes itself from domain_report for a flagged trust verdict, so an agent can tell what this tool is and is not.

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 provides concrete use cases such as lead qualification, phishing and trust checks, and deliverability audits, and it names domain_report as the alternative when a trust verdict with named flags is needed. It does not explicitly address other relevant siblings like dns_lookup or state when not to use this broader paid lookup, so the guidance is clear but not exhaustive.

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/openWorld/non-idempotent, and the description adds genuinely new context: the data source (registry RDAP, DNS as fallback), what a 'taken' result contains, and a cost model ($0.01/call via x402 or card key, first 25 free, failed calls free). The line 'each call is charged, so repeats are not free' directly reinforces and explains the idempotentHint=false annotation rather than contradicting it.

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

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

Front-loaded with the core question and the batch capability, then layers outcomes, use cases, caveats, example and pricing. Dense but essentially paragraph-shaped; the pricing/billing tail could be tightened, but no sentence is pure filler.

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

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

For a two-parameter, read-only lookup with no output schema, the description covers what is checked, where data comes from, what each result state means, limits on batching, and cost. An agent has everything needed to decide to call it and how to interpret the response.

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, but the description adds a constraint not present in the schema: a maximum of 20 TLDs per call, plus the clarification that the name may omit a TLD. The worked example (name=agentdatatools) shows intended usage concretely.

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 a specific question ('Is a domain name free?') and then states the concrete operation: check one name across up to 20 TLDs against each registry's RDAP server, with DNS fallback. The three possible outcomes (available, taken with registrar/creation/expiry, likely available) make it unmistakably distinct from siblings like domain_report, dns_lookup or domain.

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

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

Gives explicit when-to-use context ('pick a product or company name, or check a brand before launch') and a clarifying caveat that availability is not a price quote because premium and reserved names exist. It doesn't name an alternative sibling (e.g. domain_report or dns_lookup) or state when not to use it, so it falls short of full routing guidance.

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

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

Beyond the annotations, the description explains that each call is charged, repeats are not free, failed calls are free, and pricing is $0.02 via x402 USDC or a card key with the first 25 free. It also reinforces the read-only nature by saying it reads or computes only and changes nothing, and it frames the verdict as signals rather than a guarantee.

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 front-loads the main value proposition and then adds flags, use cases, limitations, raw-record routing, an example, pricing, and read-only behavior. It is dense but mostly earns its length; the example slightly duplicates the schema and the billing details are detailed, preventing a 5.

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 explains what the verdict contains: high/medium/low trust, named flags for registration age, expiry, SPF, DMARC, nameservers, web host, non-resolution, plus key facts like registrar, age, nameservers, and DNSSEC. It also covers billing and the signals-only limitation, which is sufficient for a one-parameter lookup 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 schema already has 100% description coverage for the single 'name' parameter, including the same example domain. The description adds the example usage 'name=cloudflare.com' but no meaningful syntax or format detail beyond what the schema provides, so the baseline of 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?

The description states a specific verb and resource: it returns a trust verdict for a domain in one call, with high/medium/low trust, named flags, and key facts. It also distinguishes this from the sibling raw DNS operation by saying 'Raw DNS records: domain,' so an agent can tell which tool gives a verdict versus raw records.

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

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

It gives clear usage contexts: lead qualification, phishing checks, vendor checks, and before sending mail to or trusting a domain. It also names the raw DNS alternative implicitly via 'Raw DNS records: domain' and warns that results are signals, not a guarantee. It lacks an explicit when-not-to-use statement against other verification siblings, so it stops short of a 5.

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

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

Annotations already cover read-only/non-destructive/open-world, and the description adds genuinely new behavioral facts: per-call cost of $0.01 via x402 USDC or card key, first 25 free, failed calls free, and that repeat calls are not free (clarifying the idempotentHint=false). It also restates safe behavior ('reads or computes only and changes nothing') and implies open-world dependency via RDAP/WHOIS.

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 resource and its payload, then usage, then an example, then pricing/auth — a sensible order with no filler sentences. Slightly dense, with the final sentence packing cost, free-tier, failure billing, and safety into one long clause. The title/description overlap on the record list is minor redundancy.

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, no-output-schema tool this is complete: it tells the agent what data comes back (since no output schema exists to do so), what it costs, how payment works, and that the call has no side effects. The only remaining gap is sibling differentiation, which is a routing concern rather than a completeness one.

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 'name' fully with the same example. The description's 'Example: name=cloudflare.com' merely repeats the schema example and adds no format, TLD, or normalization rules. Baseline 3 is appropriate when the schema carries the parameter semantics.

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

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

Names a concrete verb/resource pair ('WHOIS and domain lookup in one call') and enumerates the returned data: registrar, registration/expiry dates and age, DNS record types (A, AAAA, CNAME, MX, NS, TXT, CAA), DNSSEC, and SPF/DMARC. That is far more specific than a restated title. The gap: it does not distinguish itself from siblings like dns_lookup, domain_report or pack_domain_intel, which clearly overlap in returned 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?

Gives explicit usage contexts: 'check who owns a domain, how old it is, where it is hosted or whether it accepts mail, for lead research, trust and phishing checks.' That is strong when-to-use guidance. It never states when NOT to use it or names an alternative sibling, so routing between this and dns_lookup/domain_report 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?

Adds substantive context beyond annotations: no message is sent, the mail server is not contacted, results are DNS/syntax signals not proof of mailbox existence, and pricing ($0.01/call, first 25 free, failed calls free, repeats not free). The per-call cost caveat meaningfully informs an agent about repeat invocation, complementing the idempotentHint=false annotation without contradicting it.

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

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

Front-loads purpose and what is checked, then covers limits and pricing. Dense but each sentence carries information; the pricing and billing sentences could be trimmed slightly but are relevant to call 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, and the description still names the return classifications (likely-deliverable, risky, undeliverable, invalid) with reasons, plus caveats about what the result does not prove. Nothing an agent needs to invoke or interpret it 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?

Single parameter at 100% schema description coverage, so the schema already does the work. The inline example (address=support@cloudflare.com) adds slight format confirmation but nothing beyond that; 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 ('Check email syntax, DNS and MX records...') and enumerates the exact signal set (disposable, role, free provider, SPF/DMARC). This clearly separates it from generic siblings like dns_lookup or domain_report, and from pack_email_deliverability.

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

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

Gives explicit trigger conditions: 'Use before sending mail or saving a signup.' It does not name an alternative sibling (e.g. pack_email_deliverability vs this tool) or state when-not-to-use, so it falls short of a 5.

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

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

Annotations already declare read-only, non-destructive, open-world, non-idempotent, but the description adds substantial behavior the schema does not: no mailbox is contacted, DNS/syntax signals only, a $0.01/call charge via x402 USDC or card key, first 25 free, failed calls free, and that repeats are not free because each call is billed. The billing model is material to an agent deciding whether to loop over addresses, and it is stated plainly rather than buried.

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 what is checked and what is returned, followed by the caveat, usage contexts, example, and pricing in a logical order with no filler. The semicolon-separated clause about pricing and read-only behavior is dense but each element carries information an agent needs.

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

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

For a single-parameter tool with no output schema, the description supplies the verdict taxonomy, the reasons field, the caveat that mailbox existence is unproven, usage contexts, and cost/billing semantics. Nothing an agent would need in order to invoke it correctly or interpret the result is missing.

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

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

With one parameter at 100% schema coverage, the schema already defines 'address' as the email address to verify, so little is required. The description adds a concrete worked example (address=support@cloudflare.com) that clarifies format expectations beyond the field description.

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 plus the exact signals checked (syntax, domain/MX, disposable/free providers, role addresses, SPF/DMARC) and the four verdict values returned. It is unmistakable what the tool does, though it never explicitly names the sibling it differs from (e.g. pack_email_deliverability, email, dns_lookup) to route the agent.

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 usage contexts: 'Use before sending mail, saving a signup or scoring a lead.' It also sets an explicit boundary on interpretation ('this is not proof that a mailbox exists'), which functions as guidance on when the result should not be trusted for gating. What's missing is an explicit alternative tool for mailbox-level checks or bulk use.

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, openWorld, non-idempotent and non-destructive, so the safety profile is covered. The description adds materially beyond that: per-call price of $0.01, 25 free calls, card-key alternative, failed calls free, and a warning that repeats are charged because the call is not idempotent. The only omission is result ordering/pagination behavior, which is partially covered by 'newest first'.

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 what is searched and what is returned, followed by filters, provenance, use case and pricing. Dense but each clause carries information; the pricing sentence is long but operationally necessary for an agent deciding whether to call.

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

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

There is no output schema, yet the description enumerates the returned fields (title, type, agencies, abstract, publication dates, comment deadline, links) and the sort order, and it discloses cost and provenance. Nothing an agent needs in order to decide or 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?

Schema coverage is 100%, so baseline is 3. The description adds a little meaning by mapping the content classes (final rules, proposed rules, notices, presidential documents) onto the type filter and by showing an example query value, but it does not clarify the agency-slug format or the limit range beyond what the schema already documents.

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 (search the US Federal Register), enumerates the document classes covered, and the scope ('US rules and notices') clearly separates it from the SEC-focused siblings. An agent can pick it without opening the 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 a concrete use case ('track new regulations or open comment periods on a topic') plus a worked example (q=artificial intelligence). It stops short of naming when to prefer a sibling such as sec_filings or sec_8k for company-level disclosure, so the boundary is implied 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 cover read-only, non-destructive, open-world and non-idempotent, and the description usefully explains the non-idempotency in cost terms ('each call is charged, so repeats are not free') plus private-host refusal and free failure handling. It adds real context but is largely commercial (price, free tier, payment rails) rather than operational depth such as redirect handling, timeout behavior, or what a partial fetch yields.

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 capability and check list, then the alternative, then error/pricing details, which is the right order. It runs long and packs a lot into a few dense sentences, with pricing detail occupying roughly a quarter of the text, but no sentence is genuinely dead weight.

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, and the description compensates by describing the return shape (grade A-F, score, per-check values and findings). Error behavior, cost model, and eligibility constraints are all present, so an agent has enough to call it and interpret 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?

With a single parameter at 100% schema coverage, the schema already defines 'url' as a public http(s) URL. The description reinforces the public constraint and gives a concrete example, but adds no format or edge-case detail beyond that (e.g., trailing paths, query strings, redirect targets).

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 a specific verb+resource ('Fetch a public URL and grade its HTTP security headers') and enumerates exactly what is checked (HSTS, CSP, framing, nosniff, Referrer-Policy, Permissions-Policy, version leaks, cookie flags). It also names the sibling 'domain' as the tool for DNS/email records, so an agent can separate the two 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?

Explicitly states the use case ('review a site's basic web security') and routes a common adjacent need to the named alternative ('for DNS and email records use domain'). The private-host restriction is stated as a hard exclusion with the exact failure mode (400, uncharged), leaving little to infer.

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 charging model ($0.002/call via x402 USDC or a card key, first 25 free, failed calls free) and the failure behavior for non-public addresses (400, uncharged). This is consistent with idempotentHint=false, since the description explains that repeats are not free even though the call changes nothing.

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 capability and returned fields, then groups cost and failure semantics at the end. It is dense and single-paragraph, but every clause carries information; only the repeated pricing/free-call detail could be tightened 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 compensates by listing the returned attributes, and it covers pricing, error behavior and the read-only nature of the call. Nothing an agent needs in order to decide to call it or to interpret a failure 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 single parameter is already documented as 'Public IPv4 or IPv6 address'. The description adds marginal value by supplying a concrete example value (ip=8.8.8.8) and by reinforcing the public-only constraint, so it edges above the baseline without adding new parameter detail.

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

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

Names a specific verb and resource ('Look up who holds an IPv4 or IPv6 address') and enumerates exactly what is returned: holding organisation, network name and range, allocation type, registration country, abuse contact and registry. It also pre-empts a likely misinterpretation by stating 'Registration country, not city geolocation', so an agent can distinguish it from geolocation-style peers without opening the 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 use case ('to see which company or ISP a log or firewall address belongs to') and states a clear exclusion (private and reserved addresses are refused with 400 and uncharged). It does not name sibling alternatives such as pack_ip_intelligence or dns_lookup, leaving the agent to infer which tool to pick in overlapping situations.

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=true and destructiveHint=false, so the 'reads or computes only and changes nothing' line is mostly redundant. What adds real value beyond the annotations is the cost model ('$0.01/call via x402 USDC or a card key, first 25 free; failed calls free') and the note that repeats are not free, which explains the practical consequence of idempotentHint=false. Data provenance (GLEIF, CC0) and the returned field set are also disclosed.

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

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

Purpose and input modes are front-loaded, with usage, provenance, pricing and the read-only guarantee following in a logical order. The long enumeration of returned fields and the example LEI are somewhat dense but each carries information; trimming the read-only sentence that duplicates annotations would tighten it further.

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's list of returned attributes (legal name, status, jurisdiction, addresses, registration status, etc.) is exactly what an agent needs to judge result sufficiency. Combined with pricing, provenance, both lookup modes and example input, nothing material is missing for a 3-parameter read 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 the schema already documents lei as a 20-character identifier and name as an alternative, plus the 1-10 limit range. The description restates the mutual exclusivity ('by 20-character LEI, or search by company name for up to 10 matches') but adds no format, casing, or matching-behavior detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Look up a Legal Entity Identifier from GLEIF') and enumerates both input modes (LEI or name search) plus the returned fields. This clearly separates it from siblings like check_counterparty, sanctions_check and vat_validate, which do different checks on an entity.

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 use cases are given: 'KYB, counterparty checks, trade reporting and matching companies across systems,' which tells an agent the business context. It does not, however, state when NOT to use it or name the sibling to prefer (e.g. sanctions_check vs. this for screening), so the routing decision is only implied.

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: clarifies that it 'lists, never calls a tool', that it detects OAuth/401 challenges (openWorld behavior made concrete), and explains the commercial model ($0.01/call via x402 USDC or card key, first 25 free, failed calls free). The note that 'each call is charged, so repeats are not free' directly explains the non-obvious idempotentHint=false, which annotations alone would leave ambiguous.

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 return contents are front-loaded and the pricing/usage notes follow logically, so an agent can stop reading early. It loses a point for redundancy: 'Read-only: it lists, never calls a tool' and 'Reads or computes only and changes nothing' say the same thing twice in one paragraph.

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 return-value burden and does so by enumerating every field family returned. Combined with annotations covering safety and the explicit billing behavior, nothing an agent needs to call this 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 single parameter is already documented as 'The MCP server's streamable-HTTP URL'. The description adds a concrete example value (https://mcp.deepwiki.com/mcp), which clarifies the expected URL form beyond the schema's abstract wording.

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 ('MCP server check over streamable HTTP') and then enumerates exactly what is returned: initialize response, name, version, protocol version, capabilities, auth requirement, tool names/titles/descriptions/input parameters, and prompt/resource counts. This is precise enough to separate it from neighbors like openapi_summary or http_security_headers 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 explicit when-to-use contexts: 'vet an MCP server before adding it to an agent, or to check your own after a deploy', plus a concrete example invocation. It does not name a sibling alternative or state when not to use it, so it stops short of a 5.

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

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

Adds substantial context beyond the annotations: a 2 MB size limit, JSON-or-YAML acceptance, per-call pricing (first 25 free, failed calls free), and an explicit 'each call is charged, so repeats are not free' that explains the non-idempotent, costly nature of retries. Also restates the read-only/no-mutation guarantee consistently with readOnlyHint and destructiveHint=false.

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 returned fields, then usage, then an example, then commercial terms. The pricing/permission sentence is long but earns its place because it explains retry cost. Slightly dense as a single paragraph, but 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?

No output schema exists, yet the description effectively specifies the return payload field-by-field, including the 150-operation truncation cap — the key detail an agent needs to avoid assuming a full listing. Coverage limit, auth/payment route, and safety profile are all 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% and the single `url` parameter is documented there. The description still contributes format and constraint meaning ('JSON or YAML, up to 2 MB' and a concrete example value) that the schema does not carry, though it does not say what happens for non-OpenAPI URLs or unreachable hosts.

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 ('Read ... and summarise') and resource (OpenAPI 3 / Swagger 2 document), then enumerates the exact fields returned (title, version, servers, auth schemes, operation counts, paid/deprecated flags, up to 150 operations with method/path/summary/operationId). No sibling tool does this, and the scope is unmistakable.

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 trigger conditions: 'Use before calling an unfamiliar API, to pick an endpoint, or to compare APIs', plus a worked example URL. It stops short of naming when NOT to use it or a specific alternative, but no sibling overlaps meaningfully.

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

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

Adds real context beyond the annotations: deprecation/advisory severity comes from deps.dev for pinned versions, and "ok means no listed flags, not a safety guarantee" sets expectation limits on the result. It also explains the otherwise puzzling non-idempotent read behavior — each call is billed, failed calls are free, first 25 free — which reconciles with idempotentHint=false.

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 returned signals, then ecosystem coverage, then alternatives, then cost. Nearly every sentence carries distinct information, but the pricing sentence is dense and mixes three separate billing facts, slightly packing the tail.

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 enumerates the returned fields and the caveat on interpreting them. For a read-only lookup with three simple parameters, nothing an agent needs in order to select or 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%, so the baseline is 3, but the description adds meaning the schema lacks: passing an exact version unlocks pinned-version metadata and switches advisory source to deps.dev. The example (ecosystem=npm, name=lodash) reinforces the naming convention, though version-format edge cases are left to 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 and resource up front: reports package existence, latest version and release, age, version count, npm weekly downloads, licenses, deprecation and advisory severity. It also enumerates all six supported ecosystems, so an agent knows exactly what the tool covers versus sibling lookups.

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 use case ("Use before adding a dependency") and names the alternative with the condition that selects it: package_audit for OSV affected ranges and dated EPSS CVE estimates when an exact pinned version matters. The optional version semantics (exact only, no ranges/tags) are also 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?

Goes well beyond the readOnly/destructive annotations: discloses detail and subrequest caps, that omissions are explicit rather than silent, that missing evidence is 'unknown, not zero risk', that outputs are automated signals not a safety guarantee, and the full pricing model ($0.01/call via x402 USDC or card key, first 25 free, failed calls free). The 'each call is charged, so repeats are not free' line coherently explains the idempotentHint=false annotation.

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 capability, then caveats, then a usage trigger and example, then pricing — a sensible order. It is dense but most sentences carry real information; the pricing sentence is long and 'See the buying guide for limits' is a soft pointer that costs a little space.

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 only one parameter, no output schema, and open-world behavior, the description compensates well: it names the return fields (advisory IDs, affected/fixed ranges, EPSS), warns that coverage may be incomplete, and sets expectations that the tool is advisory-only. An agent has enough to decide and call 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 parameter is well documented, so the schema carries the format burden. The description still adds value with a concrete example ('packages=npm:lodash@4.17.20,pypi:requests@2.31.0,npm:@types/node@22.0.0') and the scoped-npm note, reinforcing the encoding an agent must produce.

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 up to 10 public dependencies') and enumerates exactly what it returns: advisory IDs, OSV affected/fixed ranges, and dated FIRST EPSS CVE estimates. Scope limits (max 10, optional exact pins, scoped npm names) clearly separate it from generic sibling tools like package, pypi, or semver.

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?

'Use before installing or upgrading dependencies' gives an explicit trigger context. However, no sibling alternative is named for the case where the agent only needs version/download metadata (e.g., package, npm_downloads, pypi), so the when-not guidance is left implicit.

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

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

Adds material facts beyond the annotations: three requests per call with min/median/max aggregation, explicit per-call pricing ($0.01 via x402 USDC or card key, first 25 free, failed calls free), and the warning that every call is charged so repeats are not free — directly relevant given idempotentHint=false. 'Reads or computes only and changes nothing' restates readOnlyHint, but the cost model is genuinely new information.

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 return surface, then examples, then pricing. Dense but nearly every sentence carries signal; the safety restatement ('reads or computes only') and the slightly redundant price/free-tier phrasing cost it a point.

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, and the description fully compensates by listing every returned artifact and the aggregation method. With one parameter, no auth ambiguity beyond the stated payment models, and cost behavior disclosed, an agent has everything needed to call it correctly and know the bill.

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?

Single required parameter with 100% schema coverage, so the baseline is already high. The description still adds value by showing a real example endpoint URL (including query string), which clarifies that a full URL with parameters is acceptable rather than a bare host.

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 and resource ('health-check an API endpoint') followed by an explicit enumeration of what is returned: status, response time over three requests (min/median/max), redirect chain, security headers, x402 payment terms, and the OpenAPI document. This distinguishes it from the narrow siblings (http_status, url_uptime, url_redirects, http_security_headers, x402_check, openapi_summary) that each do one slice.

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

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

Gives three concrete situations (API monitoring, pre-integration vetting, post-deploy check) and a worked example URL. 'Cheaper than the tools bought one by one' implicitly routes the agent away from the single-purpose siblings, but it never names them, so the agent must infer which alternatives this replaces.

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/openWorld/non-idempotent, but the description adds genuinely new operational context: data provenance ('public DNS, RDAP and the home page only'), pricing ($0.01/call via x402 USDC or card key, first 25 free, failed calls free), and the key consequence that each repeat call is billed, which is exactly why idempotentHint=false matters here. This is behavior an agent cannot derive from the structured fields.

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

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

The output inventory is front-loaded in the first sentence and the cost/safety caveats are packed into the tail, so the important facts land early. The middle enumeration is dense and long but each item describes an actual returned field, so nothing is clearly padding.

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

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

With no output schema and no sibling differentiation available from annotations, the description carries the full burden and does: it lists the returned data, the data sources, the billing model, and confirms no side effects. An agent can decide to call it and predict the cost and result shape without further information.

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 documents that a URL is accepted and its host used, so the baseline is 3. The description adds only a light example ('domain=stripe.com') and the phrase 'any domain', which adds marginal clarity rather than new semantics.

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 concrete capability ('Company enrichment in one call for any domain') and enumerates the exact data returned: site name/description/logo, tech stack, email provider and SPF/DMARC, hosting IP holder, DNS records, registrar, age, expiry. An agent knows precisely what comes back, which matters since there is no output schema. It does not distinguish itself from overlapping siblings such as domain_report, dns_lookup or company, so it stops short of a 5.

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 names concrete use cases ('lead enrichment, company research, vendor checks or sales prospecting') and supplies a worked example (domain=stripe.com). However it gives no exclusions and no routing advice against the many similar siblings (domain_report, dns_lookup, pack_website_audit), leaving the agent to guess when this bundle is preferable to a single-purpose lookup.

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/openWorld/non-idempotent/non-destructive, and the description adds material context on top: public DNS only, sends no mail, changes nothing, and a pricing model ($0.01/call via x402 USDC or card key, first 25 free, failed calls free) with the explicit warning that repeats are not free — which explains why idempotentHint is false. That cost/repeat behavior is exactly the kind of fact 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?

The coverage list is front-loaded, followed by safety, usage triggers, example and price — a sensible decision order with no filler sentences. Minor redundancy: 'Reads or computes only and changes nothing' restates the readOnlyHint annotation, and the pricing block is dense enough to slightly dilute the core purpose statement.

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, and the description compensates by specifying the return shape: a 0-100 score, a grade, and a list of fixes. Combined with the enumerated checks, the DNS-only/no-mail guarantee and the cost model, an agent has everything needed to decide and call correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by explaining what the optional email parameter actually triggers (syntax check, MX check, disposable-domain detection), which the schema's one-line 'Optional address to check as well' does not. The domain parameter is only illustrated by example rather than given extra semantics.

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 ('Email deliverability check for a domain') and enumerates exactly what is inspected: MX, SPF with all-policy, DMARC with policy, DKIM at named selectors, MTA-STS, TLS-RPT, BIMI. The enumeration plus the 0-100 score/grade/fixes output distinguishes it from adjacent siblings like dns_lookup, domain_report and pack_domain_intel without the agent needing to open any schema.

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

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

Gives concrete triggering situations: 'before a campaign, when mail lands in spam, or to vet a sender domain', and adds a worked example (domain=github.com). It does not explicitly name a sibling as the alternative for narrower needs (e.g. plain dns_lookup or single-address email check), so it stops short of full when/when-not routing.

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

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

Goes well beyond the annotations: it explains cost ($0.01/call, first 25 free, failed calls free) and explicitly ties the non-idempotent hint to billing ('each call is charged, so repeats are not free'). It also scopes the data honestly ('registration country, not city geolocation') and confirms the read-only nature in plain language.

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 what is returned, then usage, then pricing. Slight redundancy between the price sentence and the closing 'each call is charged, so repeats are not free', though the latter also explains the idempotency hint, so it 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, the description carries the burden of describing returns, which it does by enumerating the fields and flagging the geolocation caveat. It does not describe response shape or error behavior, but for a one-parameter lookup this is close to 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?

Schema coverage is 100% for the single `ip` parameter, so the baseline is 3; the description adds that both IPv4 and IPv6 are accepted and gives an example value (ip=8.8.8.8), which is genuine added meaning over the schema's bare type declaration.

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?

A specific verb-and-resource statement: it enumerates the returned facts (IP type, registry record, reverse DNS) and the address families supported. It could be sharper about how it differs from siblings ip_info, ip_lookup and dns_lookup, which an agent would plausibly consider interchangeable.

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?

Clear usage context (investigating an address in logs, a login, or an abuse report) plus a concrete call example. It does not explicitly exclude or route away from the similar single-purpose IP/DNS tools in the sibling list, so the agent must infer when this aggregated call is preferable.

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?

Beyond the annotations it discloses pricing and auth mechanics ($0.01/call via x402 USDC or a card key, first 25 free, failed calls free) and explains the non-idempotent cost implication: 'each call is charged, so repeats are not free'. It also characterises the output as heuristics rather than a verified blocklist, which is important behavioral context an agent cannot infer from readOnlyHint alone.

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

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

The lead clause front-loads the action and the decision it supports, and the sentence is dense with distinct facts rather than filler. The closing 'Reads or computes only and changes nothing' largely restates readOnlyHint/destructiveHint, costing some tightness.

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

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

There is no output schema, yet the description spells out the shape of the result (redirect hops, final URL, domain age, registrar, trust flags, HTTPS/security headers, named signals) so an agent can anticipate what it gets back. Combined with the cost model and safety profile, nothing material is missing for a one-parameter read 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 a single parameter and 100% schema description coverage, the schema already documents that url is the link to check and must be http/https. The description adds only a worked example (url=http://github.com) and no additional format or edge-case guidance, 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 states a specific verb and resource ('Check a link') and enumerates exactly what is returned: each redirect hop and final URL, domain age/registrar/trust flags, HTTPS and security headers, and named risk signals. This clearly distinguishes it from siblings like url_redirects (hops only), domain_report or pack_domain_intel (domain facts only) and pack_website_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?

It gives concrete usage contexts: 'before an agent opens or pays it', links in emails, chats, scraped pages, or a payee's website. It also sets a boundary by declaring this is 'heuristic signals from public facts, not a phishing blocklist'. It does not name a specific sibling alternative for narrower needs, so it falls short of a full 5.

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

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

Annotations already declare readOnly/openWorld/non-destructive, but the description adds substantial context beyond them: server-side HTML only with no JavaScript (so JS-rendered pages will read as empty), reads/computes only and mutates nothing, per-call pricing via x402 USDC or a card key with first 25 free and failed calls free. 'Each call is charged, so repeats are not free' is a concrete, correct elaboration of the non-idempotent annotation rather than a contradiction.

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?

It is one dense paragraph, but it is front-loaded with the audit contents before cost and usage, and every clause carries information an agent needs (scope, limitation, price, safety). The pricing/settlement detail is slightly compressed but earns its place for a metered paid 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 effectively substitutes for one by enumerating the return payload (uptime/speed, redirect chain with http→https check, SEO score and issues, header grade, robots.txt, DNS/email auth/registration age). It also covers the key operational caveat (no JS execution) and the billing model, leaving no material gap for correct invocation.

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% for the single required parameter, so the schema carries the definition ('Absolute http(s) URL of the page'). The description still adds value with a concrete worked example (url=https://www.wikipedia.org/), demonstrating an acceptable absolute URL form including scheme and www host, which resolves the common apex-vs-www and scheme ambiguity.

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

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

The description opens with a specific verb+resource ('One call to audit a website') and then enumerates the six sub-audits it bundles: uptime/speed, redirect chain, on-page SEO with score, security headers with grade, robots.txt, and DNS/email auth/registration age. That enumeration makes it distinguishable from the granular siblings (url_uptime, seo_audit, http_security_headers, dns_lookup) 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?

It names concrete situations ('before a launch, for a client report or to compare competitors') and states the economic rationale ('Cheaper than the six tools bought one by one'), which implicitly steers agents here over the individual tools. It never explicitly says when NOT to use it or names a specific cheaper sibling for single-purpose checks, so it falls short of a 5.

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

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

Adds a lot beyond the annotations: verdict semantics (block/review/pass), match fields, cost model ($0.009/call, first 25 free, failed calls free) and the fact that repeats are charged, which explains the idempotentHint=false flag. It does not say what happens with zero parameters or how partial name matches degrade, which keeps 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?

Single paragraph that front-loads the action, scope and usage trigger, then layers in return shape, pricing and the example. Dense but every block earns its place; the sample address and parenthetical cost/key detail make it slightly overstuffed for one sentence flow.

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, and the description compensates by describing the verdict values and per-match fields. Combined with pricing, disclaimer and sibling routing, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema, giving a baseline of 3. The description adds marginal context — accepted chain families and that names match aliases — but the alias rule is largely repeated from the schema's own wording.

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 — checking a crypto wallet address or person/company name against the OFAC SDN list — and enumerates supported chains (EVM, BTC, USDT, TRX). It distinguishes itself from the closely related check_counterparty by scoping itself to SDN screening.

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

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

Gives explicit timing ('before you pay it or accept funds', 'Use before paying') and names the alternative for the adjacent job ('with wallet risk: check_counterparty'). An agent knows both when to call this and where to route a broader wallet-risk question.

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?

The annotations already declare readOnlyHint, destructiveHint false, openWorldHint true and idempotentHint false, so the bar is lower. However, the description adds real value: it discloses the price ($0.009/call), the free tier, that failed calls are free, and the reason repeats are not free, which directly explains the idempotentHint=false annotation. The 'screening aid, not legal advice' caveat is also useful context about the response's authority.

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 verb and resource, then usage triggers, then the caveat and pricing, all in one dense block with zero filler sentences. Nothing is repeated and every clause carries information an agent needs before calling.

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

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

With no output schema, the description compensates by describing the verdict values and match payload (SDN id, programs), which is exactly what an agent needs to interpret results. It leaves open how partial name matches are ranked and whether the verdict thresholds are configurable, but for a two-optional-parameter screening tool this is close to 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?

Schema description coverage is 100%, so both parameters are already documented, including that every word of a name must appear in a listed name or alias. The description adds only an example address value and restates that address, name or both may be supplied, which is baseline value at best.

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 verb and resource: screens an address or a person or company name against the OFAC SDN list, and even names the return shape (verdict of block/review/pass plus matches, SDN ids, programs). It does not differentiate itself from the close sibling sanctions_check, so an agent still has to guess which of the two to call.

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

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

Gives three concrete trigger situations: before paying or accepting funds, when onboarding a counterparty, and as the compliance step of an agent payment flow. It stops short of explicit when-not guidance or naming the sibling tools (check_counterparty, check_payee, sanctions_check) as the alternatives, which is what would push this to a 5.

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

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

Goes well past the annotations: ordering (largest first), recency semantics of 13F filings, and an unusually explicit cost model (first 25 free, $0.01/call via x402 or card key, failed calls free, repeats are not free). The annotations already declare readOnly/non-destructive, and the description reinforces 'reads or computes only and changes nothing'.

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

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

Front-loads what the tool returns and how to identify the filer, then pricing at the end where it belongs. The final billing sentence is a long run-on that packs in several clauses, but each sentence carries information the agent needs.

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

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

There is no output schema, so the description must cover return shape, and it does: issuer, class, CUSIP, USD value, shares, portfolio weight, report period, total value and position count. Combined with the pricing and freshness notes, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description restates the filer-vs-CIK choice already documented in the schema and omits the limit parameter entirely, adding no syntax or format detail beyond what structured fields provide.

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: 'latest 13F-HR holdings of an institutional investment manager ... from SEC EDGAR', and enumerates the returned fields. Naming the 13F-HR form cleanly separates it from sibling tools like sec_filings, sec_8k and sec_insider without the agent having to open 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?

'Use to see what a fund owns' plus a worked example (filer=Berkshire Hathaway) gives a clear trigger. It also supplies timing context (filed quarterly, up to 45 days after quarter end) that tells the agent when data may be stale. It never names an alternative or an exclusion, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, destructiveHint=false, and idempotentHint=false. The description reinforces this with 'reads or computes only and changes nothing' and explains the idempotent=false consequence in practical terms ('each call is charged, so repeats are not free'), plus pricing, free-trial, and failed-call-fee details. That is meaningful added value, though it stops short of covering rate limits or pagination beyond the limit param.

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?

It is front-loaded with purpose and returned fields before pricing caveats, and every sentence carries information (contents, data source, usage, pricing, safety). It is slightly dense with pricing mechanics but no sentence is pure filler.

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

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

With no output schema, the description compensates by enumerating the return fields and ordering ('newest first'), and it discloses the billing model and safety profile. It is essentially complete; only edge details like error behavior or pagination limits are left to the schema.

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

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

Schema description coverage is 100%, so each param is already documented. The description reinforces that ticker also accepts a company name and that CIK is an alternative key, but adds no syntax or range detail beyond the schema (e.g., limit 1-40 lives in the schema). Baseline 3 is appropriate when the 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?

The description names a specific verb and resource ('Latest Form 8-K current reports'), specifies the lookup keys (ticker, name, or CIK), and enumerates the returned contents (filing date, reported items with their meaning, accession number, direct link, newest first). This clearly distinguishes it from general siblings like sec_filings or sec_13f.

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 an explicit use case ('watch a company's material events or check what it disclosed recently') and an invocation example (ticker=AAPL). However, it never names an alternative such as sec_filings or states when NOT to use it, so context is clear but exclusions are absent.

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?

Beyond the annotations (readOnlyHint, destructiveHint=false, openWorldHint, non-idempotent), the description discloses the cost model ($0.002/call via x402 USDC or card key, first 25 free, failed calls free) and explicitly warns that repeats are not free, which reinforces idempotentHint=false. It also states results are newest-first and that the tool 'reads or computes only and changes nothing.' Rate limits and pagination/beyond-limit behavior are not covered.

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 critical scope, form types and use cases are front-loaded with zero preamble, and the example is compact. The single opening sentence is dense and the closing pricing/free-tier pitch is verbose relative to the schema-and-behavior value it adds, but nothing is truly 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?

With no output schema, the description fully compensates by enumerating the returned fields (form, filing and report dates, accession number, description, link, company name, CIK, SIC) and the ordering. Combined with cost and read-only disclosure, an agent has everything needed to call and interpret results correctly.

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

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

Schema description coverage is 100%, so the schema already documents cik, form, limit and ticker, and the description adds little beyond restating that form can be limited to one type and that ticker/CIK are alternatives. It gives one example (ticker=AAPL) but no format guidance for CIK or limit. Baseline 3 is appropriate when the schema carries the parameter burden.

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

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

The description gives a specific verb+resource ('Latest SEC EDGAR filings for a US-listed company by stock ticker or CIK') and enumerates the returned fields: form type, filing/report dates, accession number, document description, direct link, plus company name, CIK and SIC. It also names the accepted form types (10-K, 10-Q, 8-K, 4, S-1). It does not explicitly differentiate itself from the overlapping siblings sec_8k and sec_insider, which keeps it out of the top band.

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?

Concrete use cases are supplied: checking a company's latest annual or quarterly report, insider trades (form 4), or material events (8-K), plus an example (ticker=AAPL). However, there is no when-not guidance and no routing to the overlapping siblings (sec_8k, sec_insider, sec_13f, company), leaving the agent to guess which tool to pick for an 8-K or insider query.

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 cost model ($0.01/call via x402 USDC or card key, first 25 free, failed calls free) and warning that repeats are charged, which reinforces the non-idempotent hint. It also names the data source (public SEC EDGAR). Some space is spent restating the readOnly/destructive-free behavior already in 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?

Purpose is front-loaded in the first clause and the pricing caveat closes it out usefully. The mid-sentence enumeration of returned fields is dense but 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 listing what each trade record contains (who, role, date, transaction type, shares, price, value, post-holding, 10b5-1 flag). Cost, source, ordering and limits are all covered; only the ticker-vs-cik precedence is left to the schema.

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

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

Schema description coverage is 100%, so ticker/cik/limit are already documented, including the 1-10 default. The description only echoes the 10-filing cap and adds a ticker example, adding no new semantics about how cik and ticker interact.

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

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

Names a specific verb and resource: insider trades from SEC Form 4 filings of a US-listed company, with the exact scope (up to 10 filings, newest first). This is clearly distinguishable from siblings like sec_13f (institutional holdings), sec_8k (material events) and sec_filings (generic filing lookup).

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 use case ("Use to see whether insiders are buying or selling") and a concrete example (ticker=AAPL). It never names an alternative sibling tool or states when NOT to use it, so the routing guidance is clear but not exclusive.

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

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

Adds substantial behavioral context beyond annotations: cost model ('$0.01/call via x402 USDC or a card key, first 25 free; failed calls free'), repeat-call charging ('each call is charged, so repeats are not free'), output masking ('hits are shown masked'), and input limit ('up to 20,000 characters'). These details complement the readOnlyHint and openWorldHint annotations without contradicting them.

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 detection capabilities, then adds practical details. It is dense but mostly earns its space; the pricing sentence is slightly tangential to the scanning purpose but relevant for cost-aware agents.

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?

Given the tool's complexity, two parameters, no output schema, and annotation coverage, the description is complete. It explains output shape ('each with its position, plus the text with every hit replaced by a label such as [EMAIL]'), input limits, detection scope, masking, and cost/auth requirements.

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 100% schema description coverage, the schema already defines both parameters. The description adds an illustrative example ('text=Contact Anna at anna.berg@example.com...') and restates the detectable types, giving useful usage context even though it largely mirrors the schema's 'types' description.

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 ('Find personal data... and get it back redacted') and enumerates the detected entity types (emails, phones, Luhn-checked cards, IBANs, SSNs, IPs, crypto addresses), clearly distinguishing this text-scanning/redaction tool from sibling tools like text_prompt_injection.

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?

Provides clear when-to-use guidance: 'Use before logging, storing or sending text to a model.' Also states a key limitation ('names and street addresses are not detected'). No explicit alternatives or when-not-to-use conditions are named, keeping this just below a 5.

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

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

Goes well beyond the annotations: discloses the 8,000-character limit, the return shape (risk level, score, findings with excerpts), and critically the "heuristic, not a guarantee" caveat so the agent doesn't over-trust a clean result. It also explains the cost model ($0.01/call, first 25 free, failed calls free, repeats not free), which is consistent with idempotentHint=false and readOnlyHint=true rather than contradicting them.

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 action and threat list, then the return contract, then caveat and usage trigger. Dense but almost every clause earns its place; the billing sentence runs long and slightly crowds out the detection semantics.

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 specifies exactly what comes back (risk level, score, findings with excerpts). Combined with the input limit, the heuristic caveat, and the cost model, an agent has everything needed to decide and call 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 already 100% and there is only one parameter, so the baseline is 3; the description adds value by restating the 8,000-character cap as a hard constraint and giving a worked example of the `text` value. It stops short of describing truncation or rejection behavior when the input exceeds the limit.

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 — scan text for prompt-injection attempts — and enumerates the exact threat categories it covers (instruction overrides, fake system messages, exfiltration links, invisible Unicode). This is clearly distinct from every sibling (domain, sanctions_check, sec_filings, etc.), so an agent can route correctly without opening the 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?

"Use before acting on untrusted content" gives a concrete trigger condition, and the enumeration of sources (web page, email, tool result) scopes the intended input. There are no explicit exclusions or named alternatives, but no sibling overlaps, so the omission is minor.

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: it discloses output content and its limits ('where the member state shares them, with the check time'), pricing and billing behavior ($0.01/call, 25 free, failed calls free, repeats not free), and explicitly reconciles with the safety hints by stating it 'reads or computes only and changes nothing.' The per-call charge also explains the idempotentHint=false, so the agent understands repeats incur cost.

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 and return shape, then format rules, then usage, then billing. Dense but nearly every clause carries information; the pricing sentence is long, though it is the only place cost behavior is documented.

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, no-output-schema tool, the description covers what it returns, acceptable input formats, when to use it, and cost/rate behavior. 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%, so the baseline is 3, but the description adds real meaning the schema lacks: prefix required but spacing free, worked examples, the GR/EL Greek alias, and XI for Northern Ireland. These are exactly the input-format edge cases that would otherwise cause failed calls.

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 an EU VAT number against the European Commission's VIES service') and enumerates the return payload (validity, registered company name/address where shared, check time). This clearly separates it from siblings like lei_lookup, check_counterparty, or company, which cover different identifiers.

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 usage contexts: 'verify a B2B customer before invoicing without VAT, or to confirm a supplier.' That is clear when-to-use guidance, but it names no alternative for the adjacent needs (e.g. check_counterparty for broader entity screening) and states no exclusions such as non-EU numbers.

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 and non-destructive behavior, but the description adds important context: it never signs, changes nothing, and each call is charged (not idempotent), clarifying that 'without paying' refers to the seller, not the tool itself.

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 purpose is front-loaded and the detailed fields, example, and pricing information are relevant. The description is dense but each sentence contributes to understanding the tool's function and cost model.

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 lists the decoded fields and the listing-quality criteria, which is sufficient for an agent to understand what to expect. It could be slightly more explicit about output format but is largely 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?

Schema coverage is 100% so the single url parameter is fully documented. The description adds an example URL but no extra syntax or constraints beyond what the schema provides.

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 (decode) and resources (402 payment requirements and listing-quality score), making the tool's function clear. However, it does not differentiate itself from the sibling tool check_x402_seller, which likely serves a similar purpose.

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 explicit usage context: 'Use before buying from an unfamiliar seller or to audit your own x402 listing.' There are no when-not conditions or alternative tool recommendations.

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