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

Annotations only cover read-only/open-world/idempotent, and the description adds substantial context beyond that: no wallet or payment required, per-IP rate limits of 30/min and 500/day, unchanged JSON passthrough, and the crucial staleness semantics of Ethereum data_through. It also discloses scope limits (poisoning only, no sanctions or scam lists), which is exactly the behavioral framing an agent needs before trusting a false negative.

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 highest-value qualifier ('Free (no wallet, nothing paid)') and organized as purpose, return shape, interpretation, alternatives, limits. It is a dense single block with heavy parenthetical nesting, which costs a little scannability, but no sentence 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?

No output schema exists, yet the description names the returned fields (flagged, first_seen, kind, data_through, coverage) and explains how to interpret each, including the false-negative trap. For a two-parameter read tool this leaves nothing an agent needs 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 still adds value by contrasting 'base (default, live)' against 'ethereum (daily scan, not live)' and by imposing a checksum requirement for mixed-case addresses that the schema pattern alone does not convey. It stops short of adding format examples or guidance on when to prefer one chain.

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 whether the address-poisoning watcher has flagged an EVM address as a lookalike or poisoning bait, with named chain scope. It explicitly separates itself from the sibling risk tools, so an agent can route correctly 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 explicit when-to-use (pre-send check of the recipient) and when-not-to-use ('flagged=false is NOT a safety verdict'), naming the alternatives check_address_risk_lite and check_address_risk_quick for a full pre-send screen. The Ethereum caveat ('a DAILY scan, not live') is a usage condition, not just a fact.

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?

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?

Goes well past the annotations by disclosing that every call costs $0.01 USDC via x402 from VERDIX_PRIVATE_KEY, that calls above VERDIX_MAX_PRICE_USD are refused up front, that 503 responses are not charged, and that the tool never returns 'safe'. It also spells out the semantic meaning of each verdict (danger = do not send, caution = confirm first), which is 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?

Front-loaded with purpose, cost, and scope in the first sentence, and the verdict-SLA caveat lands before the alternative-tool routing. The chain paragraph is dense and slightly overstuffed, but each clause carries operational meaning.

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 paid, non-idempotent, open-world tool with no output schema, the description enumerates every returned field, the payment and refusal behavior, the non-charged failure case, and the per-chain coverage differences. 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 earns above that by explaining that chain=ethereum is a daily rather than live scan, returns data_through and coverage, lacks phishing-token and deployer checks, and still bills in USDC on Base. It adds real consequences to the enum choice rather than restating it.

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') plus the exact risk categories checked and skipped, which distinguishes it from check_address_risk_deep/standard and is reinforced by the explicit sibling reference to check_address_risk_quick.

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 USDC or other funds, when the recipient is unknown or new to you') and names the alternative ('If you need a "safe" verdict ... call check_address_risk_quick ($0.02) instead or after this one'), including the cost tradeoff that selects between them.

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.