Agent Data Tools: Company, compliance and checks

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

Given non-read-only annotations, the description does the essential work of explaining why: 'Reads or computes only; not marked read-only because each call is charged,' which directly resolves the readOnlyHint=false tension. It also discloses concrete operating facts beyond the annotations — price ($0.03/call via x402 USDC or card key), first 25 free, failed calls free — that an agent needs before invoking.

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

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

Front-loaded with what the tool checks and the verdict it returns, followed by cost and the example, so the most important information comes first. The single dense paragraph packs pricing, payment rails, example and disclaimer together, which is slightly heavy but every sentence earns its place.

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

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

With no output schema, the description must convey returns, and it does name the three verdict levels with reasons. It also covers supported chains, cost model and payment paths. Remaining gap: it doesn't describe the shape of the verdict payload or the factor list in detail, but for a screening aid 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% (address described as '0x address to check', chain enum documented), so the schema already carries the parameter meaning. The description adds a worked example (address=0xd8dA..., chain=base) and notes Base-only heuristics, but adds little syntactic detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb+resource (vet an EVM address) plus the exact sub-checks performed (OFAC SDN match, account type/activity, USD holdings, wallet risk heuristics, contract bytecode/proxy) and the output form (block/review/pass verdict with reasons). The phrase 'cheaper than buying the parts' tells the agent this aggregates sibling tools like sanctions_check, contract_risk and wallet_audit, distinguishing it clearly.

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 names the triggering scenarios: 'Use before paying, trading with or onboarding an address,' reinforced by the title. It bounds scope with 'Screening aid, not legal advice or a security audit,' but does not spell out when to prefer a narrower sibling (e.g. sanctions_check alone) versus this aggregate, so it stops short of full when/when-not coverage.

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

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

Rich disclosure beyond annotations: CC0 public-domain data, 404-with-no-charge on no match, price and free tier, failed calls free, and an explicit explanation of why readOnlyHint=false ('not marked read-only because each call is charged'). This proactively reconciles the non-obvious 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-loads the returned-fields list, then usage, example, and pricing in a logical order with no filler sentences. It is long but nearly every clause carries actionable information; only the pricing/payment detail is somewhat dense.

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 returned fields, and it covers error behavior, cost, and licensing. An agent has everything needed to invoke and interpret the call.

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

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

Schema coverage is already 100%, so baseline is 3; the description adds value by clarifying the name-or-id choice and supplying concrete example values (name=Spotify, id=Q689141) that show the expected formats in practice.

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 ('Facts about a company') and enumerates the concrete fields returned (website, founding date, HQ, industries, CEO, tickers, LEI). An agent can immediately distinguish this from siblings like wikipedia, domain, or token_report 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 explicit when-to-use ('enrich leads, vendors and counterparties or ground an answer about a company') and an implied scope limit ('best for established and listed companies'), plus a worked example. It does not name a specific alternative sibling to use instead for small/private entities, so it falls short of the 5 bar.

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 description explains the otherwise puzzling annotation set: readOnlyHint=false is justified ('not marked read-only because each call is charged'), which also explains idempotentHint=false. It further discloses pricing ($0.005/call via x402 USDC or card key), the first-25-free quota, and that failed calls are free – none of which is derivable from 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?

The most important information – what you get and when to use it – is front-loaded, and the pricing caveat is placed at the end. It is a dense single block, though every clause (including pricing) carries real decision value, so little could be cut.

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 enumerating the returned data categories. For a one-parameter, single-purpose lookup tool this is close to complete; only edge-case behavior (unregistered domains, DNS lookup failures, partial SPF/DMARC results) is left unstated.

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

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

There is a single parameter with 100% schema description coverage ('Domain name, e.g. cloudflare.com'), so the schema already carries the semantics and the baseline is 3. The description's example (name=cloudflare.com) merely mirrors the schema rather than adding constraints such as handling of subdomains or URLs.

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 precise verb+resource ('Domain intelligence in one call') and then enumerates exactly what is returned: DNS record types, DNSSEC, registrar, registration/expiry dates, domain age, and SPF/DMARC. It never distinguishes itself from the sibling domain_report, which an agent could reasonably confuse with this tool, so it falls 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 three concrete use cases (lead qualification, phishing/trust checks, deliverability audits) and gives a worked example (name=cloudflare.com), so the intended context is unambiguous. It offers no when-not-to-use guidance and doesn't route to domain_report as an alternative, which keeps it at 4 rather than 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: it explains why readOnlyHint=false (each call is charged despite being read-only), discloses pricing, the x402 USDC / card-key credit paths, 25 free calls, free failed calls, and explicitly bounds reliability with 'Signals only, not a guarantee.' This is exactly the behavioral context an agent needs.

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 purpose and output shape before pricing and caveats, and every sentence carries information. It is dense but slightly overlong, stacking pricing and billing paths that could be trimmed.

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 return shape (verdict tiers, named flags, key facts like registrar, age, nameservers, DNSSEC). Combined with pricing and the reliability caveat, an agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100% and the single parameter is already documented in the schema, so the schema does the heavy lifting. The description only adds a redundant example (name=cloudflare.com), so baseline 3 applies.

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

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

States a concrete verb+resource and enumerates the exact output: a high/medium/low trust verdict with named flags for new registrations, expiry, SPF/DMARC issues, nameserver count, and non-resolving domains. It is clearly distinguishable from siblings like 'domain', 'company', and 'check_counterparty' which do not provide a consolidated trust verdict.

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: lead qualification, phishing and vendor checks, and pre-mail/pre-trust decisions. No named alternative or explicit when-not condition, and it does not distinguish itself from the sibling 'domain' tool, 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?

Goes well beyond the annotations: it explains the readOnlyHint=false flag that would otherwise look surprising ('Reads or computes only; not marked read-only because each call is charged'), discloses cost and failure pricing ($0.002/call, first 25 free, failed calls free), and bounds accuracy ('DNS and syntax signals, not proof that a mailbox exists'). That is exactly the 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?

Front-loaded with the capability list, then expectations, then usage, then pricing. Every sentence contributes, though the pricing/auth sentence is dense enough to read as a run-on and could be split.

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 one parameter, no output schema, and no annotation detail, the description supplies the return semantics (likely-deliverable / risky / undeliverable / invalid with reasons), the safety and cost model, and the accuracy limits. An agent has everything needed to decide and call.

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 'address' parameter, so the baseline is 3. The description adds only a concrete example value (address=support@cloudflare.com) and no format, normalization, or edge-case detail beyond the schema.

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

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

States a specific verb and resource (validate an email address) and enumerates exactly what signals are checked: syntax, DNS/MX, disposable providers, role addresses, free providers, SPF/DMARC. The title's phrase 'without sending mail' plus the explicit list cleanly separates it from the surrounding domain/infra 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 sending mail or saving a signup' gives a concrete trigger context, and 'No message is sent and the mail server is not contacted' rules out the obvious alternative (SMTP probe). It stops short of naming a sibling alternative, but no sibling performs this function.

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 ($0.002/call, first 25 free, failed calls free), clarifies that 'ok' means no listed flags but is not a safety guarantee, and explains why readOnlyHint is false ('not marked read-only because each call is charged'). These are critical behavioral details that an agent needs.

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 with the core functionality and includes all necessary context, but it is somewhat long (eight sentences). Each sentence conveys useful information, though slight tightening could improve conciseness.

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 covers the return values thoroughly (list of reported data), includes pricing and free tier details, provides usage guidance and an alternative tool, and clarifies output meaning ('ok'). This is complete for an agent to call the tool 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 all three parameters. The description adds only a concrete example (ecosystem=npm, name=lodash, version=4.17.20) without providing additional semantic detail about the parameters. Baseline 3 is appropriate.

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

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

The description enumerates the specific data reported (existence, latest version, age, version count, npm weekly downloads, licenses, deprecation, advisory severity) and explicitly distinguishes this tool from /package-audit. The verb 'reports' and resource 'package' are clear, and an agent can tell exactly what the tool does.

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 'Use before adding a dependency' as the primary use case and directs to /package-audit for OSV affected ranges and FIRST EPSS CVE estimates, providing a clear alternative for a different need. The guidance is explicit about when to use this tool and when to use its sibling.

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: detail/subrequest caps, explicit reporting of omitted details and incomplete coverage, 'missing evidence is unknown, not zero risk', 'automated signals, not a safety guarantee', and pricing/failed-call behavior. It even pre-empts the readOnlyHint=false question by explaining the call is charged, so nothing looks contradictory.

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 capability, then layers caveats, example and pricing in a logical order with no filler. It is dense with multiple clauses per sentence, which slightly hurts scannability, but every sentence carries real information.

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

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

With no output schema, the description still conveys the shape of results (advisory IDs, OSV affected/fixed ranges, dated EPSS estimates) plus limits and cost. 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, but the description adds a concrete worked example (npm:lodash@4.17.20,pypi:requests@2.31.0,npm:@types/node@22.0.0) that reinforces the format and scoped-name syntax in a usable form.

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: audits up to 10 public dependencies for advisory IDs, OSV affected/fixed ranges and EPSS estimates. It clearly distinguishes itself from generic siblings like 'package', 'pypi' and 'npm_downloads' by naming the exact artifacts it returns.

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

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

Gives a clear trigger ('Use before installing or upgrading dependencies') and constraints (max 10, scoped npm syntax, exact-version pinning). It does not name an alternative sibling tool or a when-not condition, 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?

Goes well beyond the annotations: it discloses return contents (SDN ID, programs, match strength, list date), the legal-disclaimer stance ('screening aid, not legal advice'), pricing/rate terms ($0.005/call, first 25 free, failed calls free), and even explains why readOnlyHint is false ('not marked read-only because each call is charged'). This is unusually rich behavioral context with no contradiction of the annotations.

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

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

Front-loads the core purpose, then layers returns, disclaimer, usage trigger, example, and pricing. Dense but nearly every sentence earns its place; the pricing and disclaimer are slightly tangent to tool selection but still relevant to invocation.

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

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

With no output schema and no required parameters, the description compensates by describing the return shape and both optional inputs. An agent has everything needed to select and call it correctly.

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

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

Schema coverage is 100% and the schema already documents both parameters' matching semantics, so the baseline is 3. The description adds value by providing concrete example values (an ETH address and 'Lazarus Group') and clarifying that either or both may be supplied, which aids correct invocation.

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) and resource (crypto wallet address or person/company name) against a named dataset (US Treasury OFAC SDN list), including scope of aliases and listed digital currency addresses. This clearly distinguishes it from siblings like check_counterparty, contract_risk, and wallet_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?

Explicitly states when to use it ('before paying, onboarding or trading with a counterparty'), giving a concrete decision context. However it does not name or exclude an alternative sibling (e.g. check_counterparty), so it falls short of a full when/when-not/alternative treatment.

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 behavior beyond annotations: it never signs, only reads/computes, each call is charged, failed calls are free, first 25 calls are free, and pricing is $0.002/call via x402 USDC or card key. It also explicitly reconciles why readOnlyHint is false despite read/compute-only behavior, which prevents misinterpretation.

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 with the core action and result fields, then moves to usage, example, and billing caveats. Despite being dense, every sentence adds operational value and there is no obvious 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 one-parameter tool with no output schema, the description is unusually complete: it explains what is decoded, what quality signals are returned, safety behavior, pricing, and use cases. An agent has enough context to invoke it correctly and interpret the result.

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

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

Schema coverage is 100%, so the URL parameter is already documented. The description still adds value by clarifying that it must be a public x402 endpoint and providing a concrete example URL with the expected shape.

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: decode/inspect a public x402 endpoint's 402 payment requirements without paying. It also enumerates the returned fields and distinguishes the tool from paid calls by emphasizing that it never signs and does not pay. This is enough for an agent to identify the tool's exact job.

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

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

Gives clear use cases: before buying from an unfamiliar seller or to debug your own listing, plus an example URL. It does not name explicit alternatives or when-not conditions, so it falls short of full usage routing but is still clear and actionable.

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