Agent Data Tools: Compliance and checks

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

Adds material behavior beyond annotations: a $0.03 USDC charge on Base per successful call paid via x402, and an explicit scope disclaimer ('screening aid, not legal advice or a security audit'). The annotations already flag openWorldHint and non-read-only, and the payment disclosure explains why it is not read-only. It stops short of describing auth flow, caching, or failure/refund behavior for the paid call.

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

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

Front-loaded with the core action and checks, and every sentence carries information (checks, verdicts, cost, disclaimer). Slightly penalized for repeating the trigger phrase ('before paying, trading or onboarding' / 'Use before paying, trading with or onboarding an address') and for one very long opening sentence.

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 work of explaining return shape (block/review/pass verdict with reasons) and the categories of findings, plus cost and scope limits. What is missing is any detail on error/payment-failure responses or output field structure beyond the verdict.

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 chain enum values are spelled out (Base, Ethereum, Arbitrum, Optimism) and it discloses that Base yields wallet risk heuristics or contract bytecode/proxy checks while other chains do not, so chain choice changes what the caller gets back.

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 ('vet an address') and enumerates exactly what is checked (OFAC SDN match, account type/activity, USD holdings, Base wallet risk heuristics or contract bytecode/proxy checks) and what is returned (block/review/pass with reasons). This distinguishes it from siblings like sanctions_check, contract-risk, and wallet-audit, which each cover only a subset.

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 triggering context ('Use before paying, trading with or onboarding an address') and implicitly positions itself against the partial tools via 'Cheaper than buying the parts.' However, it never names the alternatives (sanctions_check, contract-risk, wallet-audit) or states when NOT to use this tool, so the routing signal is inferential rather than explicit.

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: 404-on-no-match with no charge, CC0 public-domain licensing, and a $0.003 USDC-on-Base cost via x402. The pricing and error behavior are exactly the kind of traits annotations don't convey. It doesn't explain the payment side effect behind readOnlyHint=false, but nothing is contradicted.

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 fields, then adds cost/error/usage in short sentences. The long field enumeration is dense but each item earns its place by telling the agent what it will receive; slightly over-stuffed.

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 lookup tool with no output schema, the description fully covers what fields are returned, the licensing, the error path (404, uncharged), and the payment mechanism. An agent has everything needed to call 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 description coverage is 100%, so both parameters (id and name) are already fully documented in the schema. The description restates 'by name or Wikidata ID' but adds no syntax, format, or precedence detail beyond what the schema provides, 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/resource ('Facts about a company') and enumerates the exact fields returned (website, founding date, country, HQ, industries, CEO, founders, parent, employee count, tickers, LEI, Wikidata/Wikipedia links), making it clearly distinct from siblings like wikipedia, country, or coin.

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 enrich leads, vendors and counterparties or ground an answer about a company' gives concrete use cases, and 'best for established and listed companies' implies the when-not condition (obscure companies may 404). It does not name an alternative sibling (e.g. wikipedia) for cases where this tool has no match, so it stops 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 declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, which is ambiguous for what looks like a lookup; the description resolves part of that by disclosing the x402 payment model — $0.005 USDC on Base, charged per successful call. That pricing and success-condition detail is real context beyond the annotations. It stops short of explaining auth/setup for x402 or rate limits, and never reconciles the readOnlyHint=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?

Three sentences, zero filler: capability scope first, then use cases, then cost. The enumerated record types are justified content because no output schema exists to communicate the return shape elsewhere. Nothing is restated from the title or name.

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

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

With no output schema, enumerating returned fields is necessary and it is done well; the single required param and the call cost are both covered. The remaining gap is absence of any routing versus the closely-named sibling domain-report and no mention of rate limits or x402 payment prerequisites.

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 'name' parameter already carries a format example ('cloudflare.com'), so the schema does the heavy lifting. The description adds no syntax guidance beyond what the schema provides, so the baseline 3 applies.

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

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

The description names a specific resource and enumerates exactly what comes back: DNS records by type, DNSSEC status, registrar, registration/expiry dates with domain age, and SPF/DMARC email-authentication data. That is far more specific than a typical lookup tool. It falls short of a 5 because it never distinguishes itself from the sibling 'domain-report', which an agent could reasonably confuse it with.

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

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

It gives concrete usage contexts — lead qualification, phishing and trust checks, deliverability audits — which tell the agent when this tool is relevant. However, it offers no exclusions and never names an alternative (e.g. domain-report or email) for overlapping needs, so selection between 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?

Goes well past the annotations by disclosing the cost model ($0.01 USDC on Base, x402, charged per *successful* call) and the reliability caveat that output is signals, not a guarantee. It also reconciles the odd readOnlyHint=false by implying a payment side effect, and enumerates the output content in enough detail to substitute for the absent output schema.

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 value proposition ('A trust verdict for any domain in one call') before the flag inventory and pricing. The first sentence is a long comma-stuffed list, but nothing is padding and the sentence order is sensible.

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 carries the burden: it names the verdict scale, the specific flags, and the key facts returned, and it discloses cost and the signals-only caveat. An agent has everything needed 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?

Schema description coverage is 100% and there is a single, obvious `name` parameter with an inline example, so the schema already does the heavy lifting. The description's 'any domain' adds only marginal meaning over that baseline.

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

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

States a specific deliverable (a high/medium/low trust verdict) plus the concrete flags and facts it returns (new registration, expiry, SPF/DMARC, nameservers, DNSSEC). This clearly separates it in spirit from the generic sibling `domain` lookup, though it never names that sibling to make the distinction explicit.

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 contexts: lead qualification, phishing/vendor checks, and pre-send-mail trust decisions. It also states the boundary 'signals only, not a guarantee.' It does not, however, name an alternative or exclude any scenario, 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?

With annotations present, this description goes well beyond them: it discloses that no message is sent and the mail server is not contacted, that results are DNS/syntax signals rather than proof of mailbox existence, and that each successful call costs $0.002 USDC on Base via x402. The cost and payment mechanism are exactly the kind of context annotations cannot express.

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

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

Four tight sentences: what it checks, what it returns, what it does not do, and how to pay. The most decision-relevant facts (checks performed, no side effects, price) are front-loaded with no filler.

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

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

No output schema exists, yet the description enumerates the return categories (likely-deliverable, risky, undeliverable, invalid) and their reasons, and it covers cost and the key caveat. An agent has everything needed to invoke it 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?

There is a single parameter and schema description coverage is 100%, so the schema already documents 'address' fully. The description adds no format, normalization, or syntax guidance beyond what the schema provides, 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 opens with a specific verb and resource ('Check email syntax, DNS and MX records, disposable providers, role addresses...') and states the exact scope of the check. It is unmistakably distinct from sibling validators like validate_iban or validate_luhn and from domain/domain-report.

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 positive context ('Use before sending mail or saving a signup'), which tells the agent when this tool is the right choice. It does not name a when-not condition or an alternative sibling to use instead, so it stops short of the 5-level 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?

Annotations are uninformative here (readOnlyHint=false on what is obviously a query tool), so the description carries the load and does so well: it defines the semantics of the "ok" result ("no listed flags, not a safety guarantee"), discloses a paid x402 flow at $0.002 USDC on Base charged per successful call, and notes the version parameter switches advisory source to deps.dev. None of that is in 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?

Dense and front-loaded: the returned fields come first, then caveats, ecosystem coverage, version behavior, alternative tool, and cost. Every sentence carries information, though the run-on field list and payment sentence make it heavier 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 must enumerate return values, and it does (existence, version, release, age, downloads, licenses, deprecation, advisory severity) while also covering pricing and the sibling-tool boundary. An agent has everything needed to call it and 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 baseline is 3, but the description adds behavior beyond the schema: passing an exact version changes what metadata is returned and which advisory source is queried, and it reinforces that ranges/tags are not accepted. That is genuine added meaning over the property descriptions.

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 (reports) plus the exact resource attributes returned: existence, latest version/release, age, version count, npm weekly downloads, licenses, deprecation and advisory severity. It enumerates supported ecosystems and explicitly names the sibling it differs from (package-audit), so an agent can select it without inspecting either schema.

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

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

It gives both a positive trigger ("Use before adding a dependency") and an explicit routing rule to an alternative ("use /package-audit for OSV affected ranges and dated FIRST EPSS CVE estimates"), plus the condition under which the optional version parameter changes behavior.

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.20 USDC on Base per successful call via x402), operational caps (detail and subrequest limits), explicit handling of omissions and incomplete coverage, and two important epistemic caveats: missing evidence is unknown rather than zero risk, and results are automated signals, not a safety guarantee. This is unusually rich disclosure for a read-style check.

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 core purpose and scope are front-loaded in the first sentence, and each subsequent sentence carries distinct information (capabilities, caveats, pricing, usage timing). It is dense rather than padded, though the run of caveats is at the edge of what's needed in a tool description.

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

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

There is no output schema, so the description must describe the return contents, which it does by listing advisory IDs, OSV ranges, and EPSS estimates, plus how incompleteness is surfaced. Combined with the pricing and limit disclosures, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100%, and the single parameter's schema description already covers the comma-separated ecosystem:name@version format, the max-10 limit, and scoped npm syntax. The description largely restates these, adding no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

The description names a specific verb (check) and resource (public dependencies), and enumerates the exact outputs (advisory IDs, OSV affected/fixed ranges, dated FIRST EPSS CVE estimates). The scope qualifiers ('up to 10', 'optionally pinned to exact versions', 'scoped npm names supported') separate it from the generic 'package' and 'pypi' 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?

It gives a clear triggering context: 'Use before installing or upgrading dependencies.' It also points to the buying guide for limits. It stops short of naming an alternative sibling tool or stating when not to use it, 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?

The description carries far more than the annotations: it discloses the return payload (SDN ID, programs, match strength, list date), a liability caveat ('screening aid, not legal advice'), and the payment model ($0.005 USDC on Base per successful call via x402). The pricing note also explains the otherwise surprising readOnlyHint=false annotation, since each call settles a payment.

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

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

Purpose, return shape, caveat, usage trigger and cost all appear in a compact block with no redundancy, and the core purpose leads. The single-sentence enumeration of outputs and the trailing pricing clause make it slightly denser than ideal, but nothing is 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 returned fields. It also covers cost, payment rail, both optional inputs, and the legal-boundary caveat, so an agent has everything needed to decide and invoke 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% and both parameters are documented there, including the matching rule ('matches when every word appears in a listed name or alias') and the 'give address, name or both' instruction. The description restates the same input surface without adding syntax, format, or normalization 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?

A precise verb+resource statement: 'Screen a crypto wallet address or a person or company name against the US Treasury OFAC SDN list.' It names the exact data source, the accepted input types, and the covered asset coverage (BTC, ETH, USDT, TRX), which no sibling tool (contract-risk, wallet-audit, x402_check) claims.

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

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

It gives a concrete trigger: 'Use before paying, onboarding or trading with a counterparty,' which tells the agent exactly when this tool belongs in a workflow. It does not name an alternative or state when not to use it, but no sibling performs sanctions screening, 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?

With annotations present (readOnlyHint=false, openWorldHint=true, idempotentHint=false), the description still adds real context: 'Never signs', the v1 body vs v2 header decoding paths, and the $0.002 USDC-on-Base per-successful-call cost, which explains why readOnlyHint is false. It does not cover failure/error behavior, but the fee and no-sign guarantee are exactly the behaviors 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-loaded with the core action and no-sign guarantee, then the return fields, then usage and cost. It is dense and somewhat run-on in the return-value enumeration, but every clause carries information and nothing is filler.

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

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

There is no output schema, yet the description specifies the returned fields (USD price, network, asset, recipient, scheme, timeout, listing-quality score and its inputs), plus cost and usage. For a single-parameter tool this is complete enough for an agent to call it correctly and anticipate 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?

Only one parameter and schema coverage is 100%, so the schema fully documents 'url' (with the https/query guidance). The description's 'for https resource URL' slightly reinforces it but adds no syntax or format 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 and resource: 'Decode any public x402 endpoint's 402 payment requirements without paying.' It enumerates exactly what it returns (price, network, asset, recipient, scheme, timeout, listing-quality score), leaving no ambiguity about scope. No sibling tool covers x402 payment inspection, so it is trivially distinguished.

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 buying from an unfamiliar seller or to debug your own listing.' This covers the two main scenarios clearly. It stops short of naming exclusions or any alternative tool, but no sibling overlaps this niche.

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