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

Discloses far beyond the annotations: the paid x402/USDC-on-Base model, the wallet and cap used for payment (VERDIX_PRIVATE_KEY, VERDIX_MAX_PRICE_USD), per-tier prices, the default tier, and that a 503 data-unavailable answer is not charged. This covers cost, side effects, and failure semantics that annotations alone (readOnlyHint=false, openWorldHint=true, idempotentHint=false) do not explain.

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

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

Front-loads the core action and the verdict semantics before the pricing detail, and every clause carries information (verdict meanings, tier behavior, payment mechanics, 503 handling). It is dense and long, but not padded with 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 enumerates the returned fields (verdict, risk_score, reasons, checked, tier, price_usd, as_of) and interprets the two actionable verdicts. Combined with the payment and failure-mode details, 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%, so both parameters are already documented, giving a baseline of 3. The description adds genuine meaning on top by clarifying that 'deep' currently runs the same checks as 'standard' and is a choice about transfer value rather than extra coverage, which the schema's tier description only partially conveys.

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), resource (EVM address on Base), and the decision context (before sending funds or interacting). It also implicitly distinguishes itself from the sibling tier-specific tools by explaining that the tier parameter selects quick/standard/deep within this one 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?

Explicit when-to-use guidance: call before sending funds, treat 'danger' as do-not-send, treat 'caution' as confirm-with-user, and pick 'deep' for high-value or first-time transfers rather than for extra checks. It also routes to get_pricing for current prices, naming the alternative.

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

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

Goes well beyond the annotations by disclosing the full cost model: always $0.50 USDC on Base via x402, paid from VERDIX_PRIVATE_KEY, refused up front if above VERDIX_MAX_PRICE_USD, and 503 responses are not charged. It also decodes the 'danger'/'caution' verdicts into actionable conditions.

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 action, tier and price, and the return-shape summary is dense but useful. The clause 'this tier additionally runs the same checks as standard today' is mildly confusing and could be tightened, costing 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?

With no output schema, the description fully documents the return payload (verdict, risk_score, reasons, checked, tier, price_usd, as_of) and its interpretation. Combined with the payment and tier semantics, 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 description coverage is 100% for the single 'address' parameter, so the schema already carries the semantics. The description adds no format or syntax detail beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific verb ('screen') and resource ('an EVM address on Base'), and pins itself to a distinct tier. It explicitly tells the agent that check_address_risk with tier="deep" is the equivalent, so the sibling relationship is unambiguous.

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 explicit when-to-use guidance ('pick it for high-value or first-time transfers, not for extra checks') and names the alternative that avoids the dedicated tool. Both the selecting condition and the exclusion are 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 are minimal (readOnlyHint=false, openWorldHint=true, idempotentHint=false) and the description carries the real behavioral load: it discloses the $0.01 x402 payment on Base, the funding wallet (VERDIX_PRIVATE_KEY), the up-front refusal when above VERDIX_MAX_PRICE_USD, and that a 503 is not charged. It also warns that the tool NEVER returns 'safe', preventing a dangerous misinterpretation of 'no_known_risk'.

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 cost and the core use case, then the field/verdict semantics, then the escalation path and payment details — a sensible ordering. It is dense and slightly overlong for a one-parameter tool, but nearly every sentence carries decision-relevant 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 enumerates the return fields (verdict, risk_score, reasons, checked, limited_checks, checks_performed, not_checked, full_check, as_of), defines each verdict, and covers cost and failure behavior. An agent has everything needed to call this 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?

Single parameter with 100% schema description coverage, so the baseline is 3. The description adds only marginal value ('EVM address on Base', recipient/contract/counterparty), largely restating what the schema description already says.

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 (screen an EVM address on Base), names its scope limits (skips address age and caution-only contract checks), and differentiates itself from the sibling check_address_risk_quick. An agent can pick this tool over the other five risk tools without opening a schema.

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

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

Gives an explicit when (before sending USDC to an unknown or new recipient), a when-to-escalate (need a 'safe' verdict before a large/irreversible transfer → use check_address_risk_quick), and decision rules for the outcomes ('danger' = do not send, 'caution' = confirm with the user). Very little 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?

Goes well beyond the annotations: discloses that the call is paid ($0.02 USDC via x402 from VERDIX_PRIVATE_KEY), that it is refused up front if above VERDIX_MAX_PRICE_USD, that a 503 is not charged, which checks every tier runs vs. the extra address-age read this tier adds, and the exact meaning of each verdict value. This is unusually rich disclosure for a paid, open-world 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-loads purpose, tier and price, then verdict semantics, then payment mechanics. Dense but every clause carries information; only the parenthetical about check_address_risk tier="quick" and the payment paragraph overlap slightly in topic, keeping it short of 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 enumerates the returned fields (verdict, risk_score, reasons, checked, tier, price_usd, as_of) and the failure/pricing edge cases, so an agent knows both what it gets back and what it costs before invoking.

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

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

Schema description coverage is 100% and there is a single required param whose pattern and meaning are already documented in the schema ('the recipient, contract or counterparty'). The description adds only contextual framing (sending money / interacting) rather than new syntax or semantics, 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 (screen) and resource (EVM address on Base) plus the exact tier and price, and explicitly distinguishes itself from the sibling check_address_risk with tier="quick". An agent can tell instantly what this does and how it differs from the other three risk tiers.

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 (before sending funds or interacting), an explicit alternative with the condition that selects it (check_address_risk with tier="quick" for the same price without a dedicated tool), and decision rules for the two non-safe verdicts ('do not send funds' for danger, 'confirm with the user first' for caution).

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 x402 USDC-on-Base payment, the funding wallet, the max-price refusal, and the notable edge case that a 503 is not charged. It also decodes the verdict semantics ('danger' = sanctioned/scam/poisoning/burn, 'caution' = insufficient evidence, confirm with user).

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, then pricing, then verdict semantics, then payment mechanics — a logical order with no filler. It is dense and long-ish, but every clause carries operational information, so it stays just short of 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?

No output schema exists, and the description compensates by enumerating the returned verdict JSON fields (verdict, risk_score, reasons, checked, tier, price_usd, as_of). Combined with the pricing and failure-mode details, 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?

Single required parameter with 100% schema description coverage, so the schema already documents the address and its pattern. The description reinforces that the address is the recipient/contract/counterparty, but adds no format or validation detail beyond the schema — baseline 3.

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 ('Screen an EVM address on Base') and pins the scope to the standard tier at a fixed $0.10, which cleanly separates it from the sibling check_address_risk_quick/deep and the generic check_address_risk. An agent can select it without opening 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 an explicit trigger ('before sending it money or interacting with it') and names the alternative route ('use check_address_risk with tier="standard" if you want that price without a dedicated tool'). It also states a refusal precondition (price above VERDIX_MAX_PRICE_USD).

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 openWorldHint=true, so the safety profile is covered; the description goes further by stating the tool is free, that 'nothing is signed or paid', and that the wallet address is exposed so it can be funded. These are real behavioral facts beyond the annotations, though it stops short of describing any freshness or caching 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?

Three dense sentences, front-loaded with the 'Free' cost signal, then output contents, then the tiers/lite split. Every sentence carries information, though the output-field enumeration runs long and could be tightened slightly. No filler or repetition.

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 explain return values, and it does: currency and chain (USDC on Base via x402), the tiers field contents (quick/standard/deep), the separate lite field, payment recipient, max price, and wallet configuration. For a zero-parameter, no-output-schema tool this is 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?

The tool takes zero parameters, which is the baseline-4 case; there are no arguments whose semantics could be missing. The description instead spends its words documenting returned fields, which is useful but not 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?

The description makes clear this is a read-only pricing/configuration lookup for the Verdix service, enumerating exactly what is returned (per-tier prices, payment recipient, configured max price, wallet status). It also distinguishes itself from the check_address_risk_* siblings by explaining that the lite tier belongs to check_address_risk_lite. It never states a clean verb+resource ('returns pricing/config'), but the resource and scope are unambiguous.

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?

There is no explicit when-to-use guidance such as 'call this first to discover prices or verify your wallet/max price before invoking a paid check.' The reference to check_address_risk_lite and the lite tier is routing context for interpreting a field, not usage direction. An agent must infer the invocation context on its own.

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