Lucky x402

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

No annotations are provided, so the description carries the full burden. It does add genuinely useful context: pricing ($0.22 per call, USDC on Base via x402) and that the score is sybil-rejection and token-decay adjusted. However it omits permission/read-only nature, rate limits, and latency, which matters for a 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?

Two tight sentences; the core value proposition is front-loaded and the commercial detail trails it. No filler, though the sentence is dense enough that splitting cost from function would read better.

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 and no annotations, so the description should say more about what the score looks like (scale, components, response shape). It gestures at the return ('eligibility score' + 'expected value') but leaves format and interpretation to inference.

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 schema already documents chain, address and expected_payout_usd. The description marginally enriches expected_payout_usd by framing it as the 'expected value of the opportunity', but adds nothing on chain or address semantics. 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?

Names a specific resource and output: 'Airdrop eligibility score for an address' plus 'calibrated expected value of the opportunity'. An agent can tell this scores airdrop farming opportunity, but the description never contrasts it with siblings like wallet-risk or wallet-status, which sounds adjacent.

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?

No guidance on when to use this versus wallet-risk/wallet-status or defi-risk-basic, and no prerequisites or exclusions stated. Usage is only inferable from the tool name and the word 'eligibility'.

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 no annotations, the description does carry weight and does disclose two genuinely useful behavioral facts: the upstream data source (DefiLlama) and a per-call cost of $0.22 in USDC on Base via x402, which tells the agent payment/auth is required. It omits what happens on unknown pools, whether results are cached, and what the response looks like, leaving real gaps for a zero-annotation tool.

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?

Two short sentences and the core purpose is front-loaded, which is good. However, 'Quick screening Price: $0.22 per call' is punctuationally garbled and reads as two fragments merged, slightly reducing scannability of the cost 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?

For a simple one-parameter read tool with no output schema, the description covers purpose, source, and cost, which is the minimum an agent needs to call it. It does not indicate what the return contains (APY fields, TVL, chain granularity) or failure behavior, so it is adequate but not 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 description coverage is 100% with a single 'query' parameter, so the baseline is 3. The description's 'any protocol/pool' wording confirms the free-text intent and matches the schema, but adds no format, matching, or disambiguation guidance beyond 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?

The description names the exact resource (APY/TVL) and the data source (DefiLlama) for any protocol/pool, which is concrete enough to distinguish it from the risk-oriented siblings (defi-risk-basic, defi-risk-deep). It stops short of an explicit differentiator such as 'raw yield data, not risk scoring', so it is clear but not exhaustively differentiated.

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?

'Quick screening' implies a lightweight, fast-check use case, hinting that this is the shallow option versus defi-risk-deep. However, it never states when to prefer this over the risk tools, nor any preconditions (e.g., protocol must exist in DefiLlama). Usage is implied rather than spelled out.

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?

Crucially, the description provides behavioral traits not in the schema or annotations, such as the operational cost ('Price: $0.22 per call, USDC on Base') and performance ('Fast pre-audit screen'). This is highly valuable context for execution planning.

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 perfectly sized and front-loaded. The first sentence establishes scope, and the second efficiently communicates operational constraints (cost/speed) with zero fluff.

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?

While annotations are missing, the combination of a clear scope, defined parameters, and critical operational information (cost and speed) makes this definition highly complete for an execution-focused agent.

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?

Since the schema coverage is 100%, the schema itself defines the semantics of the 'contract' and 'chain' parameters. The description does not add meaning beyond what is already present in the structured input definition.

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 clearly defines the scope as 'Basic DeFi risk,' specifying the types of checks performed (contract exists, proxy, whales) and framing it as a 'Fast pre-audit screen.' This differentiates it as a lightweight alternative to a deeper analysis.

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?

The term 'Basic' and the explicit reference to a 'pre-audit screen' guide the agent on the appropriate context for use. It implies a need for a quick initial assessment before committing to a more intensive or deep analysis tool.

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 no annotations, the description carries the full burden; it does disclose a genuinely important behavioral trait that structured fields do not: a paid x402 call costing $0.22 in USDC on Base, which tells the agent an auth/payment flow is required. It says nothing about latency, failure modes, or what a risk result looks like, so the disclosure is partial.

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?

Two compact fragments, front-loaded with what the tool returns before pricing. Slight deduction because the pricing clause is compressed to the point of garble ('Agent-grade DD Price:'), reading more like a sales tag than usable guidance.

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?

The input side is simple and fully covered by the schema, and the cost/auth requirement is stated. But for a paid, two-parameter analysis tool with no output schema, the description never indicates what comes back — a risk score, a report, a verdict — which an agent needs to decide whether to pay for 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 100% — chain enumerates ethereum|base|arbitrum and contract is typed as a 0x address string — so the schema already does the work. The description adds no parameter-level meaning, which is the expected 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?

Names the resource precisely (deep DeFi risk) and enumerates the included dimensions: basic metrics plus exploit history, TVL, and full tokenomics. The prefix 'basic +' implicitly signals it is a superset of defi-risk-basic, but that sibling is never named, so differentiation is left for the agent to infer.

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?

The phrase 'Agent-grade DD' implies due-diligence use, which hints at when to reach for this rather than the cheaper basic variant, but there is no explicit when-to-use/when-not statement and no mention of the obvious alternative defi-risk-basic. Guidance is implied only.

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 no annotations, the description carries the full behavioral burden, and it adequately discloses that this is market data only, what fields are returned, and that the call costs $0.30 in USDC on Base via x402. It does not mention rate limits, data freshness guarantees, or error behavior, but the core behavioral profile is well covered for a read-only snapshot.

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 purpose and return fields, followed by a compact payment note. Every sentence earns its place with no redundant or vague phrasing.

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 market data tool with no output schema, the description sufficiently explains the returned fields and the venues queried. Minor gaps remain around response structure and missing-data behavior, but the definition is largely complete for correct invocation.

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 only parameter, 'coin', is fully documented in the schema with an example ('string, e.g. SOL'), and the description reinforces that it takes a coin. Because schema coverage is 100%, the baseline is 3 and the description adds little beyond the schema here.

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 clearly identifies the resource as perpetual funding for a given coin across four named venues: bitget, gate, kucoin, and okx. It lists returned fields (rate, interval, annualized, mark/index basis, cross-venue spread), but it does not explicitly differentiate itself from any sibling tool.

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?

The phrase 'Market data only' signals that this is a read-only data lookup rather than a trading or execution tool. However, it provides no explicit guidance on when to use this versus alternatives, and no exclusions or prerequisites beyond the payment note.

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 no annotations and no output schema, the description carries the full behavioral burden. It usefully discloses cost and payment mechanics ('$0.22 per call, USDC on Base via x402'), but it does not describe the return format, side effects, determinism, or other operational behavior 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 a single front-loaded sentence with no filler, and the pricing detail is clearly separated. However, abbreviations such as 'CoF' and 'prisms.db' are unexplained, slightly reducing clarity without adding verbosity.

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 specialized computation tool with a nested input object, no annotations, and no output schema, the description is too thin. It explains the conceptual source and price but leaves the operational meaning of the output, the feature object, and invocation context insufficiently specified.

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 only one required parameter and schema description coverage is 100%, so the schema is expected to carry parameter meaning. The description adds no extra semantics for 'features' beyond the schema's cryptic 'object{tension,harmony,pitch}' note, so the baseline of 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 identifies a produced artifact ('Color grade') and a source domain ('harmony/tonal center', Scriabin CoF<->color, prisms.db), but it does not use a clear action verb or explain what the tool actually does operationally. It also does not distinguish itself from potentially related siblings such as synesthetic-av.

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 guidance on when to use this tool, when not to use it, or which sibling tool to choose instead. The pricing sentence describes cost, not usage context or prerequisites.

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 no annotations, the description carries the full burden and does add meaningful behavioral context: it specifies a liquidation buffer of at least 1.5x beyond the stop, includes costs versus move, risk per trade, a survival cap, and the exchange limit, then returns the minimum with the binding constraint named. It also discloses the pricing/payment model via x402, though it does not explicitly state side-effect or idempotency 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?

The description is front-loaded with the core purpose and then lists the calculation factors and pricing in one dense sentence. It is efficient, but some phrases such as 'measured survival cap' and 'binding constraint named' are compressed and slightly cryptic.

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 complex 8-parameter calculation tool with no output schema and no annotations, the description covers the main computation logic, the key safety constraint, and the payment model. It stops short of explaining optional modes or the exact return shape, but the schema already documents parameter-level details.

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 input schema already documents all eight parameters. The description references the same concepts at a high level but does not add syntax, defaults, or interpretation details beyond what the schema provides; 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 states a specific operation: computing max safe leverage for a perpetual futures trade. It enumerates the factors involved (liquidation buffer, costs, risk, survival cap, exchange limit), but it does not differentiate this tool from nearby risk-related siblings such as defi-risk-basic or defi-risk-deep.

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?

Usage is implied by 'for a perp trade,' so an agent can infer that this is for leverage sizing on perpetual futures. However, the description gives no explicit when-to-use versus alternatives, no exclusions, and no routing guidance relative to sibling tools.

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 no annotations, the description carries the behavioral burden and does disclose the key traits: paid call at $0.30 USDC on Base via x402, and the output shape (PROPAGATES/ISOLATED plus per-link strength). Remaining gaps are latency/rate-limit behavior, which are secondary.

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 question and tight overall, with the pricing note parked at the end where it belongs. The telegraphic arrow notation and fragment phrasing cost some readability.

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?

Covers what it computes, the qualitative caveat, the categorical output, and the payment requirement, enough to call it correctly despite the absence of an output schema. A brief note on how many candidates are supported would close the last gap.

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 both parameters are already documented, so baseline 3 applies. The description usefully establishes the anchor-as-news-source / candidates-as-tested relationship, but adds no format or selection guidance for the optional candidates list.

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 analysis: 30-day hourly return correlation between an anchor ticker and related perps, returning PROPAGATES/ISOLATED. The concrete contrast (ETH->LINK strong, NVDA->RENDER weak) makes the operation unambiguous and no sibling covers anything similar.

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?

The framing 'Does news about coin X move Y?' plus the 'not narrative' qualifier implies when to reach for it (measured correlation rather than sentiment/narrative checks), but it never says when not to use it, nor names an alternative for the unmeasured-narrative case.

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 no annotations, the description does disclose important non-schema behavior: it is pure-logic and costs $0.22 per call via x402/USDC on Base. That is useful payment and execution context. However, it does not state what the verification returns, what checks are performed, or failure 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?

It is a single front-loaded sentence with no redundant clauses. The pricing/payment detail is compact, though the slash and pricing phrase make it slightly less polished than it could 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?

For a simple one-parameter verification tool, the description covers purpose and pricing but omits return information despite there being no output schema. An agent still lacks clarity on what 'verify' produces and how results are structured.

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 one parameter with 100% schema description coverage, so the schema already documents the 'srt' string input. The description adds no parameter-specific meaning beyond what the schema provides, making 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 and resource: verify subtitles/timing with QC. This clearly distinguishes it from unrelated siblings such as wallet-risk or defi-pool-apy. Slightly terse but 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?

Implies usage through 'Verify subtitles/timing (QC)', so an agent can infer it is for checking SRT files. However, it gives no explicit when-to-use guidance, prerequisites, or conditions for choosing alternatives.

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 no annotations, the description carries full burden. It does disclose cost and payment rail ($0.22 per call, USDC on Base via x402), which is genuinely useful and would be an auth/payment gate the agent must anticipate. But it omits output form, precedence between features and audio_url, and any failure 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?

A single compact sentence-fragment with the mechanism front-loaded and the price trailing. No filler, though the telegraphic arrow style verges on being too terse to parse.

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 is the only place the return value could be described, and it never says whether the result is an image, a color/geometry spec, or coordinates. For a tool with a nested required object and two input paths, that is a substantive gap.

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 baseline is 3. The description does add a mapping hint (pitch->hue, harmony->geometry) that aligns with fields inside the nested features object, but it says nothing about the optional audio_url or how the two inputs interact.

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?

"Audio->visual" names a transformation and the Scriabin AV-map gives it specificity (pitch->hue, harmony->geometry), but what the tool actually emits is never stated. Siblings are all finance/crypto tools, so no disambiguation is needed, yet the core verb is arrow notation rather than a concrete operation.

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?

No indication of when to reach for this versus alternatives, no prerequisites, no exclusions. The only guidance-like content is the price, which tells the agent nothing about applicability.

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?

No annotations exist, so the description carries the full burden, and it does disclose the output categories and the payment model ($0.30 per call, USDC on Base via x402) — genuinely useful behavioral context. However it omits return shape detail, data freshness/latency, and failure behavior when a ticker is absent from some exchanges, which matters for a multi-source comparison tool.

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?

It fits in one sentence with no filler, but the structure is a run-on of arrows and commas rather than front-loaded prose, which hurts scannability. Compact, yet the compression trades clarity for brevity.

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 annotations, the description supplies the essentials: what is compared, which venues, the possible verdicts, the payment terms, and the intended use case. It is close to sufficient for an agent to call it correctly; only error/edge-case behavior is 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?

There is a single 'coin' parameter with 100% schema description coverage including an example ('TRUMP'), so the schema already does the work. The description adds no semantics beyond that (e.g. case sensitivity, symbol vs contract address accepted), which is fine at 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 concrete check: whether the same ticker maps to the same token across bitget/gate/htx/kucoin, plus price vs median across five exchanges, returning CONSISTENT/DIVERGENT/COLLISION. The verb+resource is specific and no sibling tool overlaps, though the arrow-shorthand delivery makes it slower to parse than a plain sentence.

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?

The parenthetical '(anti-scam before deposit/arbitrage)' gives two concrete situations for calling it, which is real usage context. It does not say when not to use it, nor name any alternative among the 15 sibling tools, so guidance is implied 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses the cost model ($0.30 per call, USDC on Base via x402), lists the specific output attributes returned (withdraw/deposit open status, fee, minimums, memo requirement, ETA, congestion), and warns that same-ticker-different-contract traps are flagged. It stops short of stating that it is read-only/non-executing (i.e., that it does not actually move funds), which an agent might want confirmed.

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 and output contents in one dense semicolon-delimited sentence, then the pricing constraint. Every clause carries information, though the density makes it slightly harder to parse than a two-sentence split would.

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 correctly compensates by enumerating the fields returned. Combined with the pricing and the trap-flagging note, an agent has enough to decide and call it; only the non-execution nature and unsupported-pair behavior are 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?

Schema description coverage is 100%, so the schema already documents coin/from/to/amount. The description adds nothing about parameter semantics beyond naming the exchanges as A and B, 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 specific verb and resource: find the cheapest open network/route to move a coin from exchange A to exchange B, and enumerates what the answer contains (fee, minimums, memo, ETA, congestion). It is clearly distinct from all listed siblings (no other routing/transfer tool exists), though it doesn't explicitly name a sibling it might be confused 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?

The implied use case (comparing withdrawal/deposit routes between two exchanges) is readable from the purpose sentence, but there is no explicit when-to-use/when-not, no prerequisite statement, and no named alternative. The only explicit operational note is the price line.

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 no annotations, the description carries the full burden. It usefully discloses the verdict taxonomy and, unusually, the commercial model ($0.22 per call, USDC on Base via x402) — a genuinely non-obvious behavioral trait. However it omits data freshness, source, latency, and failure behavior for an invalid validator, leaving material gaps for a paid, unannotated 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?

Two front-loaded fragments with no filler: the analytical contract first, the pricing second. Dense and scannable, though arrow notation and the price clause are appended without structural separation.

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 compensates well by naming the verdict enum values and the checks performed, and it flags the paid x402 flow. It stops short of stating what the payload contains beyond the verdict or how stale the underlying data may be.

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% with a single well-labelled required 'validator' field (index or pubkey), so the schema does the heavy lifting. The description adds nothing about format tolerance or which identifier form is preferred, 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 specific verb+resource ('Ethereum validator health verdict') and enumerates the three checks (slashing, status, balance-vs-effective) plus the three outcome buckets (HEALTHY/CAUTION/AVOID). That makes it clearly distinct from sibling wallet-risk / wallet-status tools, though it never names a sibling explicitly.

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?

Usage is implied by the object under analysis (a validator) but there is no explicit when-to-use, when-not-to-use, or alternative routing — notably no guidance on choosing between this and wallet-risk/wallet-status for related address-level questions.

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 no annotations, the description carries the full burden and does disclose important behavior: the four data sources, the verdict categories, per-flag provenance, and the paid x402/USDC access model. It still omits side effects/permissions and any error or rate-limit behavior, but the core operational context is unusually strong.

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 definition is a single front-loaded sentence that puts the verdict and sources first, then the payment detail. It is dense but not wasteful; the arrow notation is compact and clear.

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 simple two-parameter read-style tool with no output schema, the description covers the key inputs indirectly, the data sources, the output taxonomy, provenance, and pricing. It is not fully complete because it does not describe response structure or failure modes, but an agent can 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%, and the schema already documents both the chain values and the address format. The description adds no parameter-specific meaning beyond that, 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 concretely states the resource (wallet risk verdict) and the specific sources used, plus the three possible outcome labels. It does not explicitly distinguish itself from siblings like wallet-status or defi-risk-basic/deep, so an agent must infer the boundary.

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 when-to-use or when-not-to-use guidance, and no named alternative tool. An agent must infer that this is for wallet-level risk screening rather than transaction or protocol risk.

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?

Since there are no annotations, the description carries the full burden. It successfully discloses high-value behavioral traits, including the possible return states (OPEN/PARTIAL/CAUTION) and critical operational costs ($0.30 per call, USDC on Base).

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 definition is maximally concise, front-loading the core function and weaving together the scope, exchanges, status results, and cost into a single, dense, yet logical 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?

Despite lacking an output schema, the description explicitly defines the result taxonomy (OPEN/PARTIAL/CAUTION), which provides necessary contextual completeness for an agent to understand the possible outcomes of 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 100%, but the description adds semantic value by clarifying that the `venues` parameter targets a specific set of exchanges and that the status includes data from the last 30 days, which informs how the inputs should be used.

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 purpose is extremely clear: to check if a coin's deposit or withdrawal status is open. It distinguishes itself by specifying the scope across multiple exchanges (bitget, gate, htx, kucoin) and checking 30-day notices.

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?

While it doesn't list alternatives, it provides strong usage constraints by listing the exact exchanges covered. The user knows this tool is limited to specific venues and types of data (deposit/withdraw status, notices).

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