Dexra

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

Annotations cover the safety profile (readOnly, idempotent, openWorld), so the description is free to add non-obvious context, which it does: it discloses per-call pricing (0.020 USDC, included in subscriptions) and explains the verdict output including the 'unknown when data is missing' fallback. This is meaningful detail beyond the annotations.

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 front-loaded with the supported venues and the metric list, followed by a compact return-value and pricing note. Two sentences plus a pricing clause, with no filler, though the metric enumeration is dense.

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 carries the return-value burden, and it does reasonably well by naming the metrics and the verdict enum with its 'unknown' state. The only modest gap is that the shape of the returned reasons is not described, but for a two-parameter analytical tool this is close to 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 coverage is 100%, so both parameters (pool address and width_pct) are already fully documented in the schema, including the default of 10 and the constraint bounds. The description's phrase 'range of the given width' confirms but adds no syntax or format detail beyond the schema. 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 the specific protocols supported (Raydium CLMM, Orca Whirlpool, Meteora DLMM) and enumerates the exact analytics computed: liquidity by price, time-in-range over 7/30 days, fee yield, impermanent loss, and rebalance count. This is a concrete verb+resource statement that an agent can distinguish from pool_health or score_performance without opening the 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?

The purpose ('Which range to hold') implies the decision context for using the tool, but there is no explicit statement of when to prefer it over siblings like pool_health or when it is not applicable. Usage is inferable but not 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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), but the description adds genuinely useful non-annotated context: this is free while the pointed-to tools are paid. The main gap is that it doesn't describe response shape or rate limits, but cost transparency beyond annotations is a real contribution.

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 and tight, with the 'Call first' guidance leading. However, the cost is stated twice ('Free.' at the start and 'Price: free.' at the end), which is redundant padding in an otherwise efficient 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?

With no output schema, the description usefully previews what the return contains (address type, age, activity, basic stats) and provides clear routing. For a single-parameter read tool whose annotations already cover safety, this is close to complete; only pagination/response-format detail is absent.

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 ('Any Solana address'), so the schema already carries the meaning. The description adds no syntax or format detail beyond what the schema provides, which is the expected baseline when coverage is complete.

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 ('describe any Solana address') and enumerates what the caller learns: wallet/program/pool/token classification, age, activity, and basic stats. This is enough to distinguish it from siblings like wallet_check, pool_health, and token_deep_check, which it explicitly names as the follow-on tools.

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 sequencing instruction ('Call first with any Solana address') and routes the agent to the alternatives that answer the next question (wallet_check, pool_health, token_deep_check). When-to-use and which-tool-next are both stated rather than inferred.

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 readOnly, idempotent, open-world, so the safety profile is covered. The description adds genuinely non-structured context: a per-call price of 0.010 USDC (included in subscriptions), the verdict vocabulary (ok/caution/avoid/unknown), and explicitly how missing data is surfaced as 'unknown'. It does not describe latency, rate limits, or pagination.

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 data coverage and ends with the return/verdict semantics and pricing. Three sentences with little waste, though the opening sentence is a dense run-on list of venues and metrics that could be split.

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 carries the return burden and does reasonably well: verdict values, reasons, per-venue costs, and cheapest venue are all stated. Minor gaps remain — the exact shape of the per-venue cost breakdown and how size_usd defaults interact with the output 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 coverage is 50% — symbol is documented, size_usd (default 10000, max 5,000,000, must be positive) is not. The description references 'an order of the given size' and 'all-in cost on each venue', which ties size_usd to the cost calculation, but it does not explain the default, the cap, or the USD units beyond what the param name implies.

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 data sets (funding, open interest, liquidations, order book depth), the venues covered (Binance, Bybit, OKX, Hyperliquid, Drift, plus Jupiter), and the composite output (all-in execution cost with cheapest venue). This is far more specific than any sibling and an agent can distinguish it from pool_health or swap_preflight immediately.

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 — this is the pre-trade market/venue comparison tool — but the description never states when to prefer it over siblings like swap_preflight or pool_health, nor any exclusions or prerequisites. No alternative is named, so the agent must infer 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?

Annotations already declare readOnly/idempotent/openWorld, and the description adds genuinely new context: per-call cost, cost escalation rules, the 20-per-answer cap tied to plan batch size, and the semantics of the verdict including 'unknown' when data is missing. It stops short of discussing rate limits, auth, or ordering of results.

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 resource and platforms, then the fields, then the verdict/pricing model — a logical order with no filler sentences. The single dense paragraph is long and could be split into scannable clauses, which keeps it off 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 carries the return-value burden and does so well by enumerating authorities, extensions, liquidity/lock, price/market cap, curve progress, creator history, funding graph, and verdict with reasons. Remaining gaps are result ordering and the two undocumented optional filters.

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 60%, so the description must add value, and it does partially: it ties 'limit' to plan batch size and clarifies the cost effect of 'minutes'. However, include_collapsed and min_liquidity_usd get no explanation anywhere in description or schema, leaving real gaps.

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: fresh token/pool launches on Solana across seven named platforms within a look-back window, and enumerates what each record carries (authorities, Token-2022 extensions, liquidity, verdict). It does not differentiate itself from the sibling new_launches_batch, which is the one thing an agent most needs to distinguish.

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?

Implied usage (triage of newly created tokens) is clear and pricing/cost cues are given (0.005 USDC per call, surcharge for >60 min windows or >20 launches). But there is no explicit when-to-use/when-not guidance and no mention of alternatives such as new_launches_batch or token_deep_check.

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 readOnly, idempotent and open-world, so the description adds real value: it discloses the verdict vocabulary (ok, caution, avoid, unknown when data is missing), the per-call price (0.015 USDC, included in subscriptions) and the tiered batch limits. It does not cover what happens to individual mints that fail resolution inside a successful batch, which is the main remaining gap.

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 dense sentence leads with the capability and then appends limits, verdicts and pricing in a logical order; nothing is redundant. It is long but every clause carries operational information, so the length is justified.

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 takes responsibility for describing the return (per-launch verdict plus reasons) and the cost/limit model an agent needs before issuing a batch. Combined with 100% schema coverage and read-only annotations, nothing essential for correct invocation 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?

Schema coverage is 100% with a single, well-documented 'mints' array, so the baseline is 3. The description earns above baseline by explaining the effective batch ceiling per tier (5 / 50 / plan max_batch via /billing/plans), which reconciles the schema's maxItems of 500 with actual runtime limits.

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 specific resource (Solana token mints you already know about), the operation (the same checks as new_launches) and the batching dimension ('in one call'), which cleanly separates it from the single-mint sibling new_launches. The parenthetical enumerates exactly what is checked.

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 'for Solana token mints you already know about' plus explicit per-tier batch caps (5 Free, 50 paid, plan max_batch) tells the agent when this tool applies and how much it can pass. It stops short of an explicit 'use new_launches instead for a single mint' exclusion, but the batching framing makes the alternative clear.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely non-structural context: the verdict taxonomy (ok/caution/avoid, and 'unknown when data is missing') and the per-call cost (0.030 USDC, included in subscriptions). It stops short of describing latency or failure/error behavior for unsupported pools.

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?

Structurally sound and front-loaded: supported venues first, then metrics, then the verdict, then pricing. Every sentence carries information, though the dense metric enumeration reads as a catalog rather than prose, which slightly costs 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?

With no output schema, the description correctly carries the return contract: it specifies the verdict values and the metric set the agent will receive. Cost and missing-data behavior are disclosed. Minor gaps remain, such as units/format of the LP-return figures and what happens for an unsupported or unindexed pool.

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 only one parameter, so the schema already carries the burden; baseline is 3. The description does contribute a domain constraint by listing which AMM families the pool address must belong to, which is a useful semantic filter beyond the schema's bare pattern.

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 specific resource (pool health for Raydium AMM/CPMM/CLMM, Orca Whirlpool, Meteora DLMM, PumpSwap) and enumerates the exact metrics returned (depth within 2%, slippage at $1k/$10k, 24h liquidity flow, LP return vs holding at 7/30 days, bot/sandwich share) plus a verdict. That is far more specific than a tautology. It does not, however, differentiate itself from sibling clmm_range_stats or market_snapshot, 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 statement, no prerequisites, and no explicit routing to or away from alternatives such as clmm_range_stats or market_snapshot. The list of supported AMMs implicitly scopes applicability, but the agent gets no guidance on choosing this tool over its siblings.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds that the report covers 'every launch risk flag we publish' and that results include daily drift, and it discloses that the tool is free — a mildly useful behavioral fact for a paid-data service. No contradiction with annotations, but no detail on latency, data freshness or rate limits either.

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 word 'Free' is stated twice (opening token and trailing 'Price: free.'), which is pure redundancy, and the description opens with pricing rather than the tool's function. One sentence of substance is padded with duplicated billing 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 carries the return-value burden and does so reasonably well, enumerating the metrics returned (24h collapse rate, base rate, sample size, window, drift). For a single optional integer parameter tool it is nearly sufficient, missing only data freshness or coverage caveats.

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%: the single 'days' parameter is fully documented including the 1/7/30/90 rounding and 1-90 bounds. The description touches the same concept ('test window') without adding syntax or defaults, so the schema does the heavy lifting. Baseline 3 applies when coverage is high.

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 concretely what data is returned: for each published launch risk flag, the collapse rate within 24h versus the base rate across all launches, plus sample size, test window and daily drift. That is clear enough for an agent to know this is a read-only flag-accuracy report. It never differentiates itself from siblings like service_stats, pool_health or market_snapshot, so it stops short of a 5.

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 guidance, no prerequisites, and no mention of any alternative tool. The only context is pricing ('Free', 'Price: free.'), which does not help an agent decide between this and the other ten sibling tools. Usage is left entirely 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?

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds the fact that it is free and specifies the 24h/7d/30d aggregation windows, which is genuinely useful, but says nothing about latency, rate limits or freshness beyond the windows.

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 metrics list, which is good, but wastes tokens by stating 'Free.' at the start and 'Price: free.' at the end — the same information twice. One of those clauses should be dropped.

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 parameters and no output schema, the description carries the return-value burden and does it reasonably well by enumerating the metrics and time windows. It is nearly complete for a zero-arg stats tool; only freshness/caching behavior is 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?

The tool takes zero parameters, so the baseline is 4. The description correctly describes the only meaningful 'input' dimension an agent needs to know — the fixed time windows the stats are aggregated over.

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 the resource (this service) and enumerates exactly what is returned: calls, unique payers, paid volume, uptime, latency. An agent can tell it apart from siblings like pool_health or token_deep_check, though the verb ('get/read') is implied rather than stated.

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 a clear trigger condition — 'Check before paying' — which tells the agent when this read-only reputation check belongs in a workflow. It does not name alternatives or exclusions, so it stops 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?

Annotations already establish readOnly, idempotent, openWorld, so safety is covered. The description adds genuinely new behavior: the return contract (verdict of ok/caution/avoid with reasons, plus an assessment of ok/unverified/high_slippage_risk/high_sandwich_risk/blocked) and the cost model (0.005 USDC per call, included in subscriptions). Latency and rate limits are not mentioned, but this is well beyond annotation coverage.

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 dense sentences: one front-loading the checks, one covering verdicts and pricing. Every clause carries information and there is no filler, though the checklist style reads as a run-on rather than tightly structured prose.

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 high-complexity multi-signal preflight with no output schema, the description does the necessary work by disclosing the verdict enum and the underlying assessment codes so the agent knows how to read the result. Only ancillary details (latency, whether the sandwich share is historical vs simulated, rate limits) are 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?

With 75% schema description coverage on four parameters, the schema already carries most of the parameter meaning (mint, quote default SOL, amount units by side). The description adds no parameter-level detail at all — the lone gap, the 'side' enum, is left undocumented in both places.

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-scope ('Before a Solana swap') and enumerates exactly what is checked: price impact, sandwich share, Token-2022 transfer fees, hooks, permanent delegate, mint/freeze authority. That enumeration is far more concrete than the sibling names pool_health or token_deep_check. It stops short of naming a sibling to differentiate from, so it is clear but not fully disambiguated.

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?

'Before a Solana swap' gives an explicit temporal trigger for when to call it, which is stronger than implied usage. It never says when NOT to use it or which sibling (pool_health, token_deep_check) covers a narrower case, so an agent still has to guess at boundaries with overlapping 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?

Beyond the readOnly/openWorld/idempotent annotations, the description discloses the verdict taxonomy (ok, caution, avoid, unknown), the degradation path when the RPC cannot enumerate holders (partial results with explicit coverage and null holder sections, which can never be ok), and the 0.030 USDC per-call price. That is precisely the extra layer annotations cannot express: output shape, failure semantics, and cost.

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 front-loaded with the use case, then the analytical scope, then the return contract, then the degradation case and price. It is dense but nearly every clause carries new information; the enumeration is long yet each item is a distinct capability rather than padding.

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 and only one input parameter, the description carries the burden of explaining what comes back, and it does: verdict plus reasons, section-level coverage on degraded runs, and cost. An agent can decide, call, and interpret the result without further context.

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 a single required parameter whose schema description coverage is 100% and whose pattern already constrains it to a base58 mint address. The description adds no format, network, or edge-case 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?

The description names a specific resource (a Solana token's holder graph and mint history) and enumerates the concrete analyses: shared-funder clusters, post-merge concentration, snapshot dynamics, blacklist proximity, and mint authorities/Token-2022 extensions. Its purpose is unambiguous, though it never explicitly distinguishes itself from siblings like token_holders_delta or wallet_check, leaving that routing to inference.

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 before buying or holding a Solana token" gives a clear triggering context, which is exactly the decision an agent needs to place this call. It stops short of explicit when-not guidance or naming the alternative to use for lighter-weight holder queries, so it is strong but not exhaustive.

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 cover the safety profile (readOnly, idempotent, openWorld), and the description adds value on top: it defines the returned verdict vocabulary (ok/caution/avoid/unknown when data is missing) and discloses cost (0.030 USDC per call, included in subscriptions). That pricing and missing-data behavior goes meaningfully beyond 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?

Front-loaded with the purpose, then the signal set, then the verdict semantics, then pricing — every sentence earns its place with no repetition or 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 carries the burden of explaining returns and does so via the verdict values plus reasons. Cost and unknown-data handling are also covered; only minor gaps remain (e.g., what the 1h/24h deltas look like structurally).

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 coverage, so the schema already documents 'mint' including its pattern. The description only implies a Solana token identifier and adds no format or constraint 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 — top holder changes over 1h and 24h from snapshots — and enumerates the concrete signals returned (new/exited holders, concentration shift, large holders selling). This is clearly distinguishable from siblings like token_deep_check or wallet_check.

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?

Opens with an explicit use case ('Use to see whether insiders are leaving a Solana token'), giving the agent a clear selection context. It stops short of naming alternatives or exclusions (e.g., when token_deep_check is preferable), so it is clear but not fully 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?

Annotations already cover safety (readOnly, idempotent, openWorld), so this is graded on added context. The description goes beyond them by disclosing cost mechanics (0.030 USDC per call, included in subscriptions) and analytical depth ('up to two hops' for OFAC/hack linkage), which materially affects agent decisions on batching and budget.

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 sentences, no filler, and the core deliverable is front-loaded before the cost caveat. Every clause carries information about either scope or price.

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 verdict components (exchange status, age, activity, bot/human, PnL on launches, exchange funding, OFAC/hack links). It also discloses cost. Only the response packaging/shape is left unstated, which is minor for a single-address lookup.

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 description coverage is 100%, so the schema fully documents the address input including its regex pattern. The description adds no format or sourcing nuance beyond that, making 3 the appropriate 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 output (a verdict with reasons) for a specific resource (a Solana address) and enumerates the dimensions checked, so the agent knows exactly what capability this is. It does not, however, differentiate itself from near-neighbors like describe_address or score_performance, which the agent must distinguish on its own.

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 title 'Should I deal with this address' plus the risk-signal list implies the use case (vetting an address before transacting), and the pricing line gives a cost consideration. But there is no explicit when-to-use/when-not guidance and no mention of when describe_address or score_performance would be the better pick.

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