Verdix prices per tier

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.