47620 Multichain Data API — onchain, crypto, utilities, x402 stats

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

With no annotations, the description carries the full behavioral burden. It does disclose a genuinely useful trait beyond the schema: the $0.002 USDC pay-per-call cost model. However, it omits rate limits, error/empty-address behavior, and the shape of the response for a read tool with no output schema.

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 with the core payload (what balances are returned) front-loaded and the cost caveat last. Slightly marred by the bracketed '[Solana by default]' prefix, which is cryptic without the sibling context.

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 read tool with no output schema, the description should explain the return shape more than 'native SOL plus every SPL token balance'. It covers the essentials and pricing but leaves chain-variant behavior (the 'by default' claim) and failure modes unexplained.

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 parameter and schema coverage is 100% ('Solana wallet address'), so the schema already documents it fully. The description adds no format, chain-variant, or address-validation detail, 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?

The description states concretely what the tool returns: native SOL balance plus all SPL token balances (including USDC) for a Solana address. That is a specific resource and scope, sufficient to distinguish it from siblings like tx or trending. It falls short of a 5 because the bare name 'account' is ambiguous and the '[Solana by default]' bracket muddies the relationship with the explicitly named sibling solana_account.

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 pick this tool over solana_account, snapshot, or token — despite an overlapping sibling set. The only conditional information is a pricing note ('Pay-per-call'), which is cost data, not usage direction.

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 pay-per-call cost ($0.002 USDC), which an agent needs for budgeting, but says nothing about return shape, pagination, failure modes, or whether stablecoin balances are limited to specific tokens.

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 payoff (what balances, for what input) followed by routing and pricing. Efficient overall, though the three literal endpoint paths consume space without helping tool selection.

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 two-parameter read tool this covers the essentials of input and cost, but with no annotations and no output schema it omits what the response contains (token list, decimals, zero balances) and how errors surface.

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 in the schema with format hints (base58 vs 0x). The description adds margin by mapping each chain value to a path, but that is routing detail rather than added parameter meaning, so the baseline 3 holds.

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 resource and scope: native plus stablecoin balances for an address on a chosen chain. It is clear what the tool returns, though it does not explicitly distinguish itself from siblings like 'account' or 'solana_account', leaving some overlap 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?

There is no when-to-use guidance, no exclusions, and no comparison to the closely named alternatives (account, solana_account, token). The listed endpoint paths are implementation detail, not selection guidance.

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 pay-per-call model and $0.01 USDC cost, plus the per-chain endpoint paths, which are real behavioral facts. It does not state that this is a read-only operation, nor does it cover rate limits, auth requirements, or behavior for non-contract/EOA addresses.

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, front-loaded with the primary purpose and return payload, followed by routing and pricing. Dense but efficient; the inline path strings are slightly cryptic but do not waste space.

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 no annotations, the description compensates well by naming the three return concepts (is-contract, bytecode size, ERC-20 metadata) and the pricing model. Missing only edge-case behavior and error handling, which is acceptable for a 2-parameter read 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 and the chain enum are already fully documented, giving a baseline of 3. The description adds the endpoint mapping for base vs polygon, but that is routing detail rather than parameter meaning, and it adds no format hints beyond what the schema's address description already provides.

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 verb and resource: determines whether an address is a contract, returns bytecode size and ERC-20 metadata, scoped to EVM. It distinguishes itself reasonably from the token/account siblings by focusing on contract-vs-EOA detection, though it never names a sibling to differentiate against.

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 explicit when-to-use guidance, no prerequisites, and no comparison to alternatives like token or account. The agent must infer from the name alone that this is for contract detection rather than balance or metadata lookup.

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 it does disclose one important trait: the tool is pay-per-call at $0.005 USDC, which an agent needs for payment-gating decisions. It does not cover auth requirements beyond payment, rate limits, error behavior, or whether the snapshot is cached/live, leaving real gaps for a paid endpoint.

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 payload description and metrics list, then the optional parameter defaults, then the route and price. Nearly every clause earns its place, though the raw route path '-> /x/crypto/analytics/:symbol' is internal plumbing that adds little for a tool-calling agent.

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 must convey the return shape, and it does by naming the four analytics fields. It stops short of describing value formats (e.g., trend states up/down/sideways are given, but volatility units and range-position scaling are not), which would complete the picture for a no-output-schema 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 description coverage is 100%, so the schema already documents all three parameters including the interval enum and limit bounds. The description restates the same defaults (1h, 168) without adding syntax care or interpretation guidance, 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 resource (analytics snapshot for a crypto coin) and enumerates the actual metrics returned (realized volatility, trend direction, relative volume, range position), which meaningfully differentiates it from siblings like crypto_ohlcv and crypto_indicators even though those siblings are not named. An agent can infer this is the derived-metrics aggregator, not the raw candle feed.

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 only implied: the agent infers it should call this when it wants a compact summary of volatility/trend/volume rather than raw data. The pay-per-call cost hint ($0.005 USDC) is a useful selection signal. However there is no explicit when-not guidance or named alternative against crypto_ohlcv, crypto_indicators, or crypto_deep, which all sound adjacent.

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 are provided, so the description carries the full burden. It usefully discloses the pay-per-call cost ($0.02 USDC) and the underlying route, which are real behavioral facts an agent needs, but says nothing about rate limits, auth, or error 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 dense sentence front-loads the value proposition and enumerates contents; the trailing route and price add practical detail. No filler, though the endpoint path is somewhat redundant with the schema.

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 no annotations, the description effectively serves as the return-value contract by listing the data categories returned. Remaining gaps are format and pagination specifics, which are minor given how completely the payload is enumerated.

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 both parameters documented (symbol ticker and interval enum with default), so the schema does the heavy lifting. The description's route string '/x/crypto/deep/:symbol' merely confirms symbol is a path parameter without adding new 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?

States a specific verb+resource: an aggregated 'full decision pack' for a crypto coin, and enumerates exactly what it bundles (spot + 24h stats, last candle, RSI/EMA/SMA, funding + open interest, order-book spread/imbalance). This clearly distinguishes it from the sibling component tools like crypto_price, crypto_indicators, crypto_orderbook, and crypto_derivatives.

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 'in ONE call' implies the consolidation value proposition versus calling the individual sibling tools, but it never explicitly names an alternative or states when not to use it. Usage is inferable 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses a pay-per-call charge of $0.005 USDC and the underlying endpoint, which an agent needs for cost-aware routing, but says nothing about auth requirements, rate limits, error behavior, or whether the symbol must be a listed perpetual.

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?

One sentence plus a short cost/endpoint clause, with the returned data fields front-loaded before the routing and pricing details. No filler, nothing repeated from the schema.

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 does the heavy lifting by enumerating the returned metrics (funding rate, mark vs index, next funding time, open interest in base and USD), which is exactly what an agent needs to judge relevance. Only the cost-aware and failure-mode details are thin.

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 single 'symbol' parameter is fully documented in the schema with examples (btc, eth, sol). The description adds only the endpoint path template, so it neither compensates for gaps nor adds meaning 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?

States a specific resource (perpetual-futures context) and enumerates the exact data returned: funding rate, mark vs index price, next funding time, open interest. The word 'perpetual-futures' cleanly separates it from spot-oriented siblings like crypto_price and crypto_ohlcv, so an agent can pick 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?

The description implies the usage context (derivatives/market context for a coin) and discloses the pay-per-call model, which is genuinely useful selection info. But it never states when to pick this over crypto_price, crypto_orderbook, or crypto_deep, and gives no exclusions 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. It usefully discloses the pay-per-call cost ($0.005 USDC) and the default interval (1h), which are real behavioral facts. However, it says nothing about payment mechanics, error behavior, rate limits, or return shape, leaving meaningful gaps for a paid endpoint.

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 that front-load the indicator set, followed by the interval default, endpoint path, and price. Nothing is padded, though the raw endpoint path is of marginal value to an agent.

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 2-parameter read tool with no output schema, listing the computed indicators does convey the return content. But with no annotations and a paid flow involving a should_pay sibling, the description omits how payment/auth is handled and how failures surface.

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 both parameters are documented in the schema, so the baseline is 3. The description restates the optional interval default (1h) but adds no syntax or semantics beyond what the schema already provides.

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 (technical indicators for a crypto coin) and enumerates the exact outputs (RSI(14), EMA(20), EMA(50), SMA(20/50/200)), so an agent can tell this apart from crypto_ohlcv or crypto_price by content. It stops short of naming a sibling explicitly, so it is clear but not fully 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?

There is no statement of when to use this versus the many sibling tools (crypto_ohlcv for raw candles, crypto_price for spot price), nor any exclusions or prerequisites. Usage is only implied by the described outputs.

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 two meaningful traits: the endpoint path and the pay-per-call cost ($0.005 USDC), which is important given payment-related siblings. However, it omits rate limits, ordering/pagination of returned candles, and any auth/payment-mechanics detail.

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?

Dense and front-loaded: the resource and return shape come first, then optional params, then endpoint and cost. The '-> /x/crypto/ohlcv/:symbol' fragment is terse but conveys the endpoint without waste.

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 explains the returned row structure, which compensates somewhat. But for a no-annotation, pay-per-call tool it still leaves out ordering, how many candles are returned by default, and payment/auth mechanics.

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 symbol, interval (with enum), and limit. The description restates the interval set and limit cap, adding no syntax or semantics beyond the structured fields, 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?

The description names a specific verb+resource ('OHLCV candle history for a crypto coin') and even specifies the row shape [openTime, open, high, low, close, volume], which clearly separates it from siblings like crypto_price or crypto_indicators. It does not explicitly name those siblings, 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 statement of when to use this tool versus crypto_price, crypto_indicators, or snapshot, and no exclusions or prerequisites beyond an implied 'you want candle history'. The pay-per-call note is a cost caveat, not usage 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the pay-per-call cost ($0.005 USDC) and the endpoint path, which are real behavioral traits. However, it omits auth requirements, rate limits, error behavior, and pagination, leaving meaningful gaps for a paid endpoint.

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 value proposition is front-loaded with the returned fields, followed by endpoint and cost in a compact arrow-delimited form. It is a single dense line with little waste, though the run-on enumeration is slightly hard to parse at a glance.

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, so the description must explain return values, and it does so thoroughly, including the sign convention for imbalance (>0 = more bids). For a two-parameter read tool it also covers cost and endpoint, leaving nothing essential 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 schema already documents both symbol and limit (including the 5-100 range and default 20). The description only restates the symbol as a path segment and adds no syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 resource (top-of-book order book for a crypto coin) and enumerates exactly what it returns: best bid/ask, mid price, spread (abs + bps), depth, and book imbalance. That enumeration inherently distinguishes it from siblings like crypto_price (last price only) and crypto_deep (deeper book), so an agent can tell what this is 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?

There is no explicit when-to-use/when-not guidance and no named alternative, despite numerous closely related siblings (crypto_price, crypto_deep, crypto_ohlcv). Usage is only implied by the returned fields. The endpoint path and pricing are operational details, not selection guidance.

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 are provided, so the description carries the full burden. It importantly discloses the pay-per-call cost ($0.002 USDC) and the endpoint path, which are real behavioral traits beyond the schema. However, it omits rate limits, error/unsupported-symbol behavior, and caching/freshness guarantees.

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 front-loads the core purpose (live spot price + returned metrics) before the endpoint and cost. No filler sentences, though the run-on structure packs endpoint and pricing into the same block.

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 no annotations, the description compensates by naming the returned fields (price, 24h change, high, low, quote volume) and the cost model. It covers what an agent needs to call and interpret the tool, missing only edge-case/error behavior.

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 there is a single required param, so baseline is 3. The description adds value by enumerating the concrete supported symbols (btc, eth, sol, bnb, ...) which the schema only illustrates with 'e.g. btc, eth, sol', effectively documenting the accepted input domain.

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+scope: live spot price in USD for a named coin, and even enumerates the supported tickers and the returned fields. It is clearly a spot-price lookup, distinguishable from crypto_ohlcv/crypto_indicators by naming the resource, though it does not explicitly contrast itself with those siblings.

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 (fetch a spot price for a supported coin) but there is no explicit when-to-use vs alternatives guidance, e.g. no pointer to crypto_ohlcv for historical bars or to token/token_report for metadata. The pay-per-call note gives a cost signal but not a routing rule.

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 load and does disclose the pay-per-call cost ($0.01 USDC) and the exact return fields (price, 24h change, quote volume), which are real behavioral facts beyond the schema. It omits error behavior for invalid/unlisted symbols and the endpoint's rate or auth characteristics.

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?

One dense sentence front-loads the core action and scope, then tacks on the return fields, endpoint, and price. No filler sentences.

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 covers input format, returned fields, and cost. Only edge-case behavior (invalid symbols, partial failures) is left 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 100% and the single parameter is fully documented there, including the <=25 limit. The description's comma-separated example (btc,eth,sol,doge) reinforces the format but adds nothing the schema lacks.

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+scope: 'Batch spot prices for MANY coins in ONE call,' and enumerates the returned fields. It clearly separates itself from the single-coin crypto_price sibling via the batching emphasis.

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?

'MANY coins in ONE call' with a comma-separated list strongly implies when to use this over the singular price tool, and the pay-per-call note flags that each invocation costs money. It stops short of explicitly naming crypto_price as the single-coin 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?

No annotations are provided, so the description carries the full burden. It discloses the return shape (cheapest buy venue vs highest sell venue with gross spread %) which is useful, but says nothing about authentication, rate limits, data freshness, or whether the spread is executable. It is a truncated, partial disclosure rather than a complete behavioral picture.

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 padding, which is good. However the tail is visibly garbled/truncated ('liquidi From $0.020 USDC.'), leaving an incomplete thought and an unexplained pricing fragment that weakens structure.

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, no-output-schema tool the description covers the essentials of what is returned. But given zero annotations and 0% schema coverage, it leaves key gaps: symbol format, chain scope behavior, and the meaning of the trailing pricing note.

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 one parameter at 0% schema description coverage, the description must compensate. It gives concrete examples of valid symbol values (ETH, SOL, USDC), which adds real meaning, but does not specify format rules (case sensitivity, contract addresses vs tickers) or how multichain resolution is handled.

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 verb and resource — 'cross-DEX arbitrage (multichain)' returning the best buy/sell spread for a token symbol — which is clear and concrete. It partially distinguishes itself from related siblings like defi_yields and opportunity_feed by naming the cross-DEX/cross-chain spread concept, though it never explicitly names an alternative.

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 versus the many sibling tools (opportunity_feed, defi_yields, crypto_price). Usage is only implied by the arbitrage framing; no exclusions, prerequisites, or conditions for selection 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?

With no annotations, the description carries the full burden, and it does disclose two real traits: the endpoint is keyless and costs $0.010 USDC (payment required). However, the pricing sentence is garbled ('Keyless, f From $0.010 USDC'), and nothing is said about read-only nature, rate limits, or failure modes for unknown symbols.

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 reasonably tight, but the trailing 'Keyless, f From $0.010 USDC.' is a typo-riddled fragment that costs clarity at the exact point where a key behavioral constraint (payment) is disclosed.

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 usefully previews the return fields (APY total/base/reward, TVL, project), which is genuinely additive. It still omits usage routing and annotates none of the safety/payment mechanics cleanly, so it is adequate rather than 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 0%, so the description must compensate; it does add format guidance via examples (USDC, ETH, SOL) and clarifies that chain is not a parameter (results span chains). It still does not state case sensitivity, accepted symbol forms, or behavior for ambiguous symbols.

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 resource (DeFi lending/staking yields) and scope (top pools by APY/TVL/project for a token symbol across chains), which is far more specific than the bare tool name. It does not name or differentiate itself from any sibling (e.g. token_report, crypto_analytics), leaving the agent to 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?

The description implies the input is a token symbol with examples, but never states when to prefer this tool over siblings or when it does not apply. No prerequisites, no exclusions, no alternative tools named.

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 must carry the full behavioral burden. It usefully discloses that the call is pay-per-call at $0.005 USDC, which an agent needs for cost-awareness, but says nothing about read-only nature, latency, caching, or what assumptions the 'estimated transfer cost' makes (e.g., transfer type or default gas limit).

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 value proposition in the first clause, then adds routing and pricing details. The path strings are somewhat noisy internal routing detail, but nothing is truly wasted and it stays to a few lines.

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 single-parameter, no-output-schema tool, the description covers what the call returns (gas price and transfer cost estimate), which chains are valid, and the sibling to use for Solana. Minor gap: it does not clarify what the transfer-cost estimate assumes, which an agent may need to interpret the number.

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?

One parameter with 100% schema coverage and an enum that already enumerates base and polygon. The routing paths restate the enum values rather than adding new meaning such as expected units, response currency, or behavior on unsupported chains. Baseline 3 applies when the schema does the heavy lifting.

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 precisely: current gas price plus an estimated transfer cost, and names the supported chains (base, polygon) via routing paths. It also distinguishes itself from Solana-oriented siblings by noting that Solana uses fixed micro-lamport fees. The verb is only implied rather than stated, but the intent 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?

Gives a clear exclusion: for Solana, gas does not apply because fees are fixed micro-lamports, so the agent should use health for fee context instead. No guidance is offered on when to prefer this over other non-Solana siblings, but the main routing decision is covered.

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 are provided, so the description carries the full burden. It does disclose real behavioral detail – the underlying eth_gasPrice call, the slow/standard/fast tier structure, and the chain-specific Solana per-signature base fee – plus a cost signal, but it omits rate limits, freshness/latency, and the exact paid-call semantics behind the USDC figure.

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 its scope in the first clause, followed by tier and chain-specific notes. The trailing pricing line is short and earns its place as a cost signal, though the em-dash packing is slightly 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?

For a one-parameter, read-only gas lookup with no output schema, the description covers the chains, the tier output shape, and the Solana special case. Missing only return-unit/format detail and permission or pricing caveats, which are minor at this complexity.

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 0% and the single 'chain' parameter has no enum, so the description must compensate. It does: the inline '(base|polygon|solana)' supplies the accepted values that the schema lacks, which is the key semantic an agent needs.

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 ('gas price for a chain') and enumerates the exact supported chains (base|polygon|solana), which lets an agent scope the tool without opening the schema. It does not explicitly contrast itself with the sibling 'gas' tool, so the multichain-vs-single-chain split must be inferred from the name.

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 chain enumeration and the 'From $0.002 USDC' cost hint, so an agent can tell this is for fetching gas prices on those three chains. There is no explicit when-to-use / when-not-to-use guidance and no direction to the sibling 'gas' tool, leaving the choice 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?

With no annotations, the description carries the full burden, and it does add one genuinely useful behavioral trait: pay-per-call pricing at $0.001 USDC. However, it says nothing about return contents, error behavior, rate limits, or auth requirements, so the disclosure is only 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?

Three short, front-loaded sentences with no filler; the core purpose and the pricing fact both land early. The per-chain path listing is slightly internal/technical filler for an agent, keeping it from 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?

For a one-parameter, no-annotation, no-output-schema tool the description is adequate on scope and cost, but it leaves the return shape of 'network health' and the relationship to solana_health undefined, so it is only the minimum viable.

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 the enum plus 'Chain to query' already documents the single parameter, so the baseline is 3. The description maps each enum value to a backing path, which adds minor meaning but not much that helps the agent choose a value.

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 ('Network health for a chosen chain'), so the agent knows exactly what it retrieves. It does not differentiate from the overlapping sibling solana_health, which appears to be a chain-specific variant of the same capability.

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. The phrase 'for a chosen chain' only weakly implies scope, and the description never tells the agent when to prefer this over the sibling solana_health.

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 the safety-critical trait: signatures are NOT verified. It also states the pricing model (pay-per-call, $0.002 USDC), which matters for agent decision-making. It omits error behavior for malformed tokens and any rate/limit context, keeping it short of a 5.

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 decode-only caveat, then tacks on the route and price. Every element is short, though the parenthetical claim list and the '-> /x/util/jwt-decode' internal route make it slightly denser than necessary for an agent.

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, and the description compensates by enumerating the returned claim fields, so an agent knows what to expect. Cost and the verification caveat round it out. Minor gaps remain around malformed-input behavior, but nothing essential to invoking it correctly 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 description coverage is 100% with a single 'token' parameter already documented as 'The JWT string to decode', so the schema does the heavy lifting. The description adds no syntax, size, or format constraints beyond that. Baseline 3 is appropriate for a fully-documented single parameter.

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 (decode) and resource (JWT), then enumerates exactly what is extracted (subject, issuer, audience, expiration with expired flag, issued-at, not-before, algorithm, key id). No sibling tool overlaps with JWT decoding, so the boundary is unambiguous from the definition alone.

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 clear conditional context via 'Decode-only — signature NOT verified', which tells an agent when this tool is inappropriate (any use requiring trust in the token's authenticity). It does not name an alternative verification tool, but no such sibling exists in the list, so the guidance is effectively complete for this catalog.

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 it does disclose useful traits: the Reservoir/Alchemy-free data route, that counts are estimated and floor is only 'where available', and a cost of $0.010 USDC. It omits auth requirements, rate limits, and failure behavior for unsupported chains or invalid addresses.

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?

Compact and front-loaded, but the opening repeats itself ('NFT holdings (multichain) — NFT holdings for a wallet') and the pricing clause is tacked on with no structural signal. Every clause carries information, yet the sentence is an awkward run-on.

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 or annotations, so the description must stand alone; it covers scope, chains, returned fields, and cost, which is enough to invoke the tool. It does not describe response shape, pagination, or edge cases (e.g. wallets with no NFTs).

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 0% for the single required 'address' parameter. The description implies it is a wallet address and constrains the valid chains to Base and Polygon, but gives no address format or validation details, so it only partially compensates for the undocumented schema.

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 resource and scope: NFT holdings for a wallet, limited to Base and Polygon, with the data returned (collections owned, estimated counts, floor). An agent can tell this apart from balance/token tools, though no sibling is named 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?

There is no when-to-use or when-not-to-use guidance, no mention of how this differs from wallet_balances_multichain or portfolio_multichain, and no prerequisites. The chain restriction is stated but framed as a data-source note rather than a selection rule.

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. It adds one useful behavioral fact — the call is paid, 'From $0.005 USDC' — but discloses nothing about the response shape, pagination, refresh cadence, or what 'live' implies about data staleness/recency.

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 short but the core content is truncated ('endpoin') and the pricing clause is awkwardly appended without separation. Front-loading the resource is good, but the broken sentence means the structure does not read cleanly or fully convey the offer.

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 or annotations, the description gives a reasonable sketch of input examples and cost, but the truncated return-value explanation ('total vs healthy endpoints') leaves the agent without a full picture of what it will receive.

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 0% for the single required 'domain' parameter, so the description must compensate. It partially does by giving example values ('crypto, security, agent, finance'), clarifying the expected granularity, but it does not state whether other domains are valid or the format constraints.

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 resource ('agent marketplace opportunity feed') and the content it surfaces ('unhealthy/underserved x402 categories with total vs healthy endpoin[t]s'), which is more specific than a tautology. However, the sentence is truncated mid-word and lacks a clear verb, so the agent must infer the operation. It offers no differentiation from any of the many sibling 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?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The user must infer from the name alone that this is for discovering marketplace gaps rather than, say, querying prices or trending tokens.

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 returned evidence fields (status, confirmations, sender, receiver) and pricing ('From $0.010 USDC'), but says nothing about authentication, rate limits, or what happens on an unknown/invalid hash.

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 front-loaded sentence that packs purpose, scope, input formats, return fields, and price with little waste. Minor sloppiness ('val' truncated, run-on clause) keeps it from 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?

For a paid lookup tool with no output schema and no annotations, the description should carry more — the return list is truncated at 'val' and omits error/not-found behavior. Adequate but with clear gaps given zero structured support.

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 0% with one required string param, so the description must compensate — and it does, specifying both accepted hash formats (EVM 0x 64-hex vs Solana base58 signature). This is meaningful guidance the bare 'string' schema does not provide.

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 (returns) and resource (on-chain payment evidence) and clarifies the multichain scope plus accepted input formats (EVM 0x 64-hex or Solana base58). It does not, however, differentiate itself from the close sibling payment_verify, which an agent must distinguish when choosing.

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 no explicit when-to-use guidance and never names an alternative such as payment_verify, tx_receipt, or tx. The usage is only implied by 'Given a transaction hash', leaving the agent to infer when this tool beats 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses what the verification checks (confirmations, finality, sender/receiver, value) and that expected-match checks are optional, but says nothing about permissions, rate limits, or whether the operation is read-only.

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?

Single front-loaded sentence with the core verb/resource first, followed by the verifying fields and the pricing note. No filler, though the inline query-parameter syntax is dense and slightly muddles the one-line structure.

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 no annotations, the description does good work by enumerating the fields returned (confirmations, finality, sender/receiver, value), which substitutes for a return-value doc. However, the undocumented 'hash' param and the mismatch between described query params and the schema leave meaningful gaps for a paid verification 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 description coverage is 0% and the single required 'hash' parameter is never explained in the description. Worse, the description introduces query parameters ('?to=', '?minAmount=') that do not appear in the input schema at all, creating ambiguity about the actual call surface.

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 ('Verify') and resource ('on-chain payment'), then enumerates exactly what is verified: confirmations, finality, sender/receiver, value. It's clearly more specific than generic sibling 'tx_receipt' or 'payment_evidence', but it never explicitly contrasts itself with those, so it falls short of full sibling differentiation.

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 — you call this to verify a payment — but there is no explicit when-to-use, no when-not-to-use, and no reference to alternatives such as payment_evidence, tx_receipt, or should_pay despite them being obvious overlaps in the sibling list.

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 burden, and it does disclose useful behavior: it aggregates three named chains, returns USD-denominated values and per-chain totals, and is priced at $0.010 USDC per call (a disclosed external side effect). It says nothing about whether the address is required to exist on all three chains, partial-failure behavior, or rate limits.

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 core sentence is front-loaded and dense, but the trailing pricing fragment is malformed and visibly truncated ("...three chain-s From $0.010 USDC."), which reads as a broken concatenation rather than a deliberate 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?

No output schema and no annotations, so the description must define the contract; it partially does by naming the returned fields, but it omits address-format expectations, behavior on chains where the address has no activity, and the difference from wallet_balances_multichain.

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?

One required parameter ('address') with 0% schema description coverage. The description says "for one address" but never clarifies whether the address must be Solana-format, EVM-format, or whether both forms are accepted for the three chains — the single most important calling question for this tool.

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 resource (unified multichain portfolio) and scope (Solana + Base + Polygon for one address), with the returned contents enumerated (native balance, USD value, per-chain totals). It does not, however, distinguish itself from the close sibling wallet_balances_multichain, which an agent could easily confuse it 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?

"One call instead of three chain-s" implies an efficiency-based reason to use this over per-chain calls, but there is no explicit when-to-use, when-not-to-use, or named alternative. Given a near-identical sibling (wallet_balances_multichain) exists, the absence of routing guidance is a real gap.

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 two meaningful traits: the return format (SVG + base64 data URI) and the billing model ('Pay-per-call ($0.002 USDC)'). It omits auth/wallet requirements and failure behavior, but pricing and output shape are the high-value disclosures here.

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 compact clauses, front-loaded with the action and output, then endpoint path, then cost. No filler and nothing redundant.

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, but the description states the return value (SVG + base64 URI) and the pricing, and the input schema fully documents both params. Only minor gaps remain, such as auth/payment mechanics and error cases.

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 both parameters (text, size with range and default) are already documented in the schema. The description adds no format or syntax detail beyond what the schema provides, making the baseline 3 correct.

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 ('Generate a QR code') and the exact artifact returned ('inline SVG + base64 data URI'), so the agent knows precisely what it produces. No sibling tool in the list competes with QR generation, so it is trivially distinguishable.

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 description scopes input ('for any text or URL'), which implies when the tool applies, but gives no explicit when-to-use/when-not-to-use guidance or alternative tools. Usage is inferable but not framed.

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. It discloses the pay-per-call cost ($0.02 USDC), the re-verifiable on-chain fact basis, and the output verdict, but it never explicitly states read-only status, rate limits, or auth beyond payment.

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 primary use case and output, then compactly lists chain endpoints and cost. Every line carries information; the endpoint mapping is dense but purposeful, so it is efficiently structured.

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 no-annotation, no-output-schema tool, the description covers the essential context: when to use, what it returns, which chains, and the cost. It leaves minor gaps (read-only status, error behavior), but an agent has enough to invoke 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 coverage is 100%, so the schema already documents both parameters. The description adds a chain-to-endpoint mapping, but doesn't add syntax or constraints beyond the schema's enum and address description, so 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 verb ('get') and resource ('risk score') with output detail ('0-100 risk score with reasons and a proceed/review verdict'). It does not explicitly distinguish from siblings like trust_check or should_pay, so it is clear but lacks sibling differentiation.

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?

It gives a clear usage context ('BEFORE paying an address'), which is when to use it. It offers no when-not guidance or named alternatives among siblings, so it falls 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?

With no annotations, the description carries the full behavioral burden; it usefully discloses the pay-per-call cost ($0.001 USDC) and the endpoint path, which is real value beyond structured fields. However it omits whether the operation is deterministic/idempotent or how billing is triggered per call, leaving the safety profile under-specified.

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 with the core purpose front-loaded and zero filler. The '-> /x/util/fingerprint' fragment is somewhat cryptic notation but compact and does not obscure the 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?

There is no output schema, so the description compensates by naming the four return encodings an agent will receive, and it mentions cost. For a one-parameter pure utility this is close to complete, with only idempotency/permission details 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 description coverage is 100% for the single 'text' parameter, so the schema already documents it fully. The description adds no format or constraint detail beyond what the schema provides, matching the baseline-3 case for complete schemas.

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 ('Compute') and resource ('SHA-256 fingerprint of a string') and even enumerates the output encodings (full hex, colon-separated, short 16-char id, base64). It is unmistakably distinct from siblings like jwt_decode, qr_generate, or unit_convert, so an agent can select it 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?

There is no explicit when-to-use, when-not-to-use, or alternative tool guidance. The pricing note implies it is a paid call but gives no condition for choosing it over other utility siblings. The usage is only inferable from the purpose statement.

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 it does add real behavioral context: this is a paid call at $0.02 USDC and it condenses multiple on-chain facts into one verdict. However, it never states whether it is read-only, what the verdict contains, or latency/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?

Two tight sentences, front-loaded with the purpose before routing and cost details. Nothing is wasted, though the raw endpoint template line is somewhat implementation-oriented for an agent-facing 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?

There is no output schema, so the description is expected to convey what a call returns; 'aggregating on-chain facts into a single verdict' gestures at it but leaves the actual verdict shape and fields unexplained. Combined with zero annotations, a paid decision tool warrants more on permissions and output.

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 both parameters fully described and chain constrained by an enum, so the schema already does the work. The description adds only the endpoint routing per chain, which is marginal 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 decision verb and resource: a 'Pay-vs-do-not-pay decision for a payee' that aggregates on-chain facts into 'a single verdict.' This is distinctive from the raw-fact siblings (balance, tx, gas) and the narrower risk_check/trust_check tools, though it never names those alternatives directly.

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?

It discloses cost ('Pay-per-call ($0.02 USDC)') and routing, which is useful, but gives no when-to-use guidance and no exclusions relative to risk_check, trust_check, or health, which appear to be decision-adjacent siblings. The agent is left to guess which decision tool to pick.

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. It usefully discloses pay-per-call cost ($0.01 USDC) and the data returned, but does not state that the operation is read-only, nor describe auth requirements, rate limits, or error 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 benefit ('Whole-network picture in ONE call') and uses compact sentences. Endpoint mapping and cost are included efficiently, with little wasted language.

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 query tool with no output schema and no annotations, the description explains what data is returned, the per-call cost, and the endpoint mapping. It is complete enough to select and invoke correctly, though it omits usage alternatives.

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%, giving a baseline of 3. The description adds value by mapping each enum value to a specific endpoint path, clarifying chain-specific behavior beyond the schema's 'Chain to query' text.

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 clear resource and scope: a whole-network snapshot containing cluster health, chain status, price, and trending data. It distinguishes itself from narrower sibling tools through the phrase 'in ONE call', though it does not explicitly name the siblings it aggregates.

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 'Whole-network picture in ONE call' implies usage for an aggregated overview rather than topic-specific calls, but no explicit when-to-use, when-not-to-use, or alternative tools are named. Sibling tools like health, trending, and solana_health are left unaddressed.

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 burden of behavioral disclosure. It usefully discloses the monetary cost ($0.002 USDC) and the comprehensive scope of the balance lookup, but it does not state whether the operation is read-only, how errors are surfaced, or any rate-limit constraints.

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 that conveys the core behavior, scope, and cost with no filler. Every clause earns its place.

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 sufficiently explains what the call returns (native and SPL balances) and the cost. It does not detail response formatting or failure modes, but the low complexity and full schema coverage keep the gap minor.

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 single parameter is adequately described as 'Solana wallet address'. The tool description adds no further semantic detail beyond the schema, 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 clearly identifies the resource (a Solana address) and the exact data returned: native SOL balance plus all SPL token balances including USDC. It is distinguishable from sibling tools by content focus, though it does not explicitly name an alternative.

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 description gives no guidance on when to use this tool instead of siblings like solana_token, solana_tx, or solana_trending. It states the pay-per-call cost but not the conditions or contexts in which this tool is the appropriate choice.

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 are provided, so the description carries the behavioral disclosure burden. It does disclose the call's expected outputs and the pay-per-call cost of $0.001 USDC, which is useful. However, it does not mention auth requirements, rate limits, availability, or response format, leaving some behavioral traits undisclosed.

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 sentence that front-loads the resource, immediately lists the three returned metrics, and ends with the pricing detail. There is no filler and every phrase earns its place.

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 zero-parameter, low-complexity read-only health tool, the description provides all essential selection information: the resource, the exact returned values, and the cost. The lack of an output schema is acceptable because the expected data points are stated directly in prose.

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 input schema has zero parameters and 100% schema description coverage, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because parameter documentation is effectively a non-issue.

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 states the tool reports Solana network health and names three concrete outputs: current slot, epoch, and SOL/USD price. This is specific enough to distinguish it from the token, account, transaction, and trending siblings, even though it does not explicitly contrast itself with them.

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 explicit when-to-use, when-not-to-use, or alternative tool guidance is provided. The agent must infer from the 'network health' label and the sibling names that this is the right tool for chain status and price checks. For a zero-parameter health endpoint this is acceptable, but the usage context remains implicit.

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 are provided, so the description carries the burden of explaining behavior. It discloses the returned information, the 0-100 risk score, the proceed/review verdict, and the pay-per-call cost. It does not explicitly state that the call is read-only or describe error behavior, but for a risk-check tool this is reasonably transparent.

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 compact and front-loaded: it states the triggering condition first, then lists outputs, then the purpose and cost. Every sentence provides necessary information and there is 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?

For a single-parameter tool with no annotations and no output schema, this description is complete. It explains when to use it, what it returns, why it matters, and even discloses the per-call cost. An agent has enough context to select and invoke the tool 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%, so the baseline applies. The single 'address' parameter is already described as 'Solana address to check before paying' in the schema. The tool description adds context about SOL/USDC and risk, but does not add new parameter-level semantics beyond the schema.

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 states the tool's purpose: a pre-payment risk check for Solana addresses. It specifies the resource (Solana address), the action (check risk before sending SOL/USDC), and the outputs (account type, balance, activity, risk score, verdict), which distinguishes it from sibling tools like solana_account.

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 description explicitly tells the agent when to use it: before sending SOL/USDC to any address, and to avoid paying dead, wrong, or program addresses. It does not explicitly name alternative tools or exclusions, but the triggering condition is clear enough for an agent to route correctly.

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 are provided, so the description carries the burden of behavioral disclosure. It usefully reveals that the call aggregates multiple network data points, is a single call rather than separate ones, and carries a pay-per-call cost of $0.01 USDC. However, it does not disclose output format, failure behavior, or whether any authentication or rate limits apply.

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 compact, front-loaded with the core value proposition, and every sentence provides distinct information: what the tool returns, why it is advantageous, and what it costs. There is no filler or redundancy.

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 zero-parameter tool, the description gives a solid picture of what the agent will receive: health, slot, epoch progress, price, and trending pairs. It also covers pricing, which is behaviorally relevant. There is no output schema, but the enumerated data categories are adequate for an agent to decide whether to invoke 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?

The tool has zero parameters, so there is no parameter semantics for the description to add. With an empty input schema and no parameters, the baseline of 4 applies because no param documentation is needed; the description focuses instead on what the call returns.

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 states the tool's function: providing a whole-network picture in one call, enumerating specific data points such as cluster health, current slot, epoch progress, SOL/USD price, and top trending pairs. It distinguishes itself from sibling tools by explicitly positioning it as a consolidated alternative to making multiple separate calls.

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 description provides clear context for when to use this tool: when a broad, multi-signal snapshot is needed and paying for one combined call is cheaper than several individual calls. It does not explicitly state when NOT to use it or name the specific sibling alternatives, but the usage context is evident enough.

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 burden of behavioral disclosure. It does add meaningful context by stating the tool is pay-per-call at $0.002 USDC and that data is live, which goes beyond a generic fetch. However, it does not mention error behavior, rate limits, or what happens for invalid mint addresses.

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 extremely concise: one clause states the returned data and input scope, and one clause states the cost. There is no redundant or filler content, and the most important information is front-loaded.

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-style tool with no output schema, the description covers the input, the returned fields, and the cost model. It does not describe response format or failure cases, but the tool's low complexity and the description's directness make it largely 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 the schema already documents the single 'mint' parameter as an SPL token mint address. The description adds only 'any' and 'Solana' context, which does not materially improve understanding beyond the schema. A 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 names the resource (Solana SPL token mint) and the data returned (price, liquidity, 24h volume, DEX pairs), which clearly distinguishes it from the account, transaction, health, and trending siblings. It lacks an explicit verb like 'get' or 'fetch', but the intent 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?

No guidance is given about when to choose this tool over the sibling tools. The phrase 'for any Solana SPL token mint' implies the input condition, but there is no explicit when-to-use, exclusions, or reference to alternatives such as solana_account or solana_trending.

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 are present, so the description carries the behavioral disclosure burden. It adds valuable context such as pay-per-call pricing and the categories of data returned. However, it does not disclose potential failure modes, data freshness guarantees, auth requirements, or whether the call mutates anything or is read-only, leaving some agent-facing ambiguity.

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 sentences, each earning its place: what it returns, when to use it, and cost. The main deliverable is front-loaded in the first sentence. Minor structure improvements could separate pricing into a more prominent callout, but overall it is tight and readable.

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?

Given one parameter, no output schema, and no annotations, the description provides a solid picture: purpose, included data categories, use case, and cost. It does not describe the output shape or error behavior, but the listed report contents approximate the return set well enough for a single-mint research 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?

The schema covers the single `mint` parameter with a clear description ('SPL token mint address'), so schema coverage is 100%. The description does not add meaning beyond naming the token context, but none is strictly needed for a single, well-documented parameter.

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/resource ('Full token due-diligence') and enumerates concrete items (live price, liquidity, 24h volume, DEX pairs, supply, mint authority). It also distinguishes itself from 'multiple lookups,' making clear this is an aggregator tool rather than a single-purpose lookup, which helps separate it from siblings like solana_token.

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?

States a clear use case: 'Use for token research instead of multiple lookups.' This implies it is the preferred choice when broad token data is needed and that narrower tools may be more appropriate for single metrics, though it does not explicitly name alternatives or when not to use it.

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

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

Annotations are absent, so the description carries the full burden. It discloses pay-per-call cost and the notion of being a live feed, but does not state whether the operation is read-only, what error handling or rate limits exist, or how the response is structured. For a tool that agents will call, these are significant omissions.

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 concise, with three short sentences that front-load the core purpose first. The second sentence about being a fresh feed adds a slight redundancy but still conveys usage context. The cost mention is important and well placed. There is minimal fluff, and it is easily skimmable.

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?

Given the tool has no output schema, the description should at least indicate the nature of the returned data (e.g., an array of pair objects with volume fields), but it only says 'DEX pairs' without structural details. It also omits any authentication or setup prerequisites. For a simple tool with no parameters, this is still incomplete for an agent that needs to consume the response 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?

The tool has zero parameters, so schema coverage is 100% by default. The description does not need to explain parameters. The baseline for 0 parameters is 4, and no additional parameter information is required.

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 states the tool returns live trending/new Solana DEX pairs ranked by 24h volume. The resource and sorting criterion are specific, and the purpose is distinct from sibling tools like solana_token or solana_account. Even though the verb is implicit, the meaning 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?

The description implies this tool is for retrieving current market data (trending/new pairs) and mentions it is a 'fresh feed for agents', suggesting repeated polling. However, it gives no explicit guidance on when to use this tool versus the siblings (e.g., solana_health for network status, solana_token for token details) nor any exclusions. Usage context is implied but not 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. It does disclose a meaningful behavioral trait: pay-per-call with a specific cost ($0.003 USDC), which is valuable for an agent deciding whether to invoke it. It also describes the output categories, but it does not mention potential errors, signature format requirements, or whether the call is read-only.

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 concise single sentence that front-loads the core output information and appends the pay-per-call cost. Every clause adds useful information, and there is no wasted wording.

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 tool with one required parameter and no output schema, the description is largely complete: it tells the agent what data will be returned and warns about the cost. It could be improved by noting any special formatting requirements for the signature, such as base58 encoding or mainnet specificity, but these are not critical gaps.

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 schema already documents the single 'signature' parameter. The description adds confirmation that the signature is for a Solana transaction, but it does not add format details, network context, or example values beyond what the schema 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?

The description clearly identifies the resource: a Solana transaction signature, and lists the exact data it returns (status, slot, fee, block time, transfer summary). It lacks an explicit verb like 'retrieves' or 'gets', but the noun-phrase style is still unambiguous and distinguishes it from the sibling tools, which cover health, token, account, and trending data.

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 versus the siblings solana_health, solana_token, solana_account, or solana_trending. The use case is implied by the resource type, but no explicit context, prerequisites, or exclusions are provided.

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 it does add useful facts: the tool is keyless (no auth), it returns a derived 'depeg-risk band' rather than raw numbers, and it has a stated cost basis. However, it says nothing about rate limits, error behavior for unknown symbols, or data freshness beyond the 24h/7d 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?

The purpose and output list are front-loaded in one dense clause, but the trailing pricing fragment is garbled ('Keyless, from D From $0.005 USDC.'), which reads as corrupted boilerplate and dilutes clarity. The core is efficient but the tail is not.

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 single-parameter, read-only lookup with no output schema and no annotations, the description enumerates the return fields so the agent knows what it gets back and confirms no auth is needed. Missing usage routing and error semantics are minor gaps rather than blocking ones.

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 0% and the single 'symbol' parameter has no schema description, so the description must compensate. The examples '(e.g. USDC, USDT, DAI)' establish that symbol is a stablecoin ticker, which is meaningful guidance, though format/validation rules are not stated.

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 ('stablecoin peg health') and enumerates the concrete outputs (price, peg deviation in bps, 24h/7d change, market cap, depeg-risk band), which clearly separates it from generic siblings like crypto_price or token. It does not name any sibling explicitly, so differentiation is implicit rather than explicit.

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 statement of when to use this tool versus alternatives such as crypto_price, token_report, or trust_check, and no prerequisites or exclusions beyond the passing 'Keyless' note. The agent must infer usage from the purpose sentence alone.

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 are provided, so the description carries the full burden. It usefully discloses the pay-per-call cost (from $0.002 USDC), which is real behavioral context the schema cannot express, but it omits read-only/mutation semantics, authentication requirements, rate limits, and 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?

Three compact sentences with the payload (what is returned) front-loaded, followed by routing detail and pricing. No filler, though the raw path strings are slightly noisy for a description field.

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 only two well-documented required parameters and no output schema, the description covers what is returned, which chains are supported, and the cost model. It is largely complete, with only the sibling-differentiation gap holding it back.

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 path listing does reinforce that 'id' is a mint on solana and an address on EVM chains, but adds little beyond the schema's own 'SPL mint or ERC-20 address' description.

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 resource (token) and enumerates what it returns: live price, liquidity, 24h volume, DEX pairs. However, it does not distinguish itself from siblings like solana_token, token_report, and solana_token_report, leaving the agent to guess which token-lookup tool is appropriate.

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 chain-to-path mapping implies which chains are queryable, but there is no explicit guidance on when to choose this tool over solana_token or token_report, nor any exclusions or prerequisites. 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?

With no annotations, the description carries the full burden and does disclose two non-trivial behaviors: pay-per-call billing ($0.01 USDC) and the chain-to-endpoint routing. It omits auth requirements, return shape, and rate/error behavior for a multi-chain aggregator, so transparency is partial rather than rich.

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 value proposition, followed by the returned fields, routing, and price in dense but ordered fragments. No filler sentences; slightly telegraphic endpoint syntax is the only mild readability cost.

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 no annotations, the description compensates by enumerating the returned data fields and the cost model, which is the key information an agent needs before paying. Auth requirements and response format remain inferable but unstated, leaving a small 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 the enum for chain plus the token format are both documented in the schema, so this is the baseline 3. The description adds only the per-chain endpoint paths, which restates the chain enum rather than deepening parameter meaning.

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 ('Full token due-diligence') and enumerates the payload (price, liquidity, 24h volume, DEX pairs, supply, EVM contract metadata), so an agent knows exactly what it gets. It does not, however, distinguish itself from close siblings such as token, trust_check, risk_check, or solana_token_report, which likely overlap on the same asset.

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 'in ONE call' implies this is the aggregate/everything option and the stated $0.01 USDC pay-per-call is a real selection consideration. But there is no explicit when-to-use vs when-not, and no routing guidance against token/trust_check/solana_token_report, leaving the agent to infer the choice.

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 disclosure burden. It usefully reveals the data providers and that the tool is paid ('From $0.015 USDC'), which is real behavioral context, but says nothing about auth requirements, rate limits, or failure modes.

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?

Purpose is front-loaded in a single sentence, but the text is visibly malformed/truncated ('pair count, and From $0.015 USDC'), suggesting a broken sentence that undercuts structure and 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?

No output schema and no annotations, so the description must carry everything. The output list is cut off mid-sentence and the return shape, coverage limits, and cost mechanics are left ambiguous for what is a paid multi-source aggregation 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 0% and the single 'address' parameter has no description, so the schema does not help. The description partially compensates by specifying accepted formats ('EVM 0x or Solana base58'), which is meaningful, but adds nothing about validity or edge cases.

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 clear verb+resource ('One-call research summary for a token') and enumerates the returned data (price/liquidity/volume, market cap/rank/supply, pair count) with named sources (DexScreener, CoinGecko). It does not differentiate itself from close siblings like token_report or token, 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?

The description never says when to choose this over the many overlapping siblings (token, token_report, solana_token, solana_token_report, crypto_price). It implies a broad 'one-call' use but provides no conditions, exclusions, or 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 the whole behavioral burden and does a good job: it discloses the data source (DexScreener), the static (non-live) nature of the read, the supported chains (Base/Polygon), the output shape (0-100 score, pair count, liquidity depth), and the per-call cost ($0.010 USDC). It stops short of describing auth/payment flow, error behavior for unknown tokens, or rate limits.

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?

One front-loaded sentence that leads with the purpose, then the scope, then the outputs, then the price. Nothing is wasted, though the stacked parentheticals make the middle slightly 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?

The enumerated output fields partially compensate for the absent output schema, and pricing is disclosed. However, the tool takes only an 'address' yet claims Base/Polygon coverage with no chain parameter, leaving unclear how the chain is determined — a real gap for a one-parameter tool with no annotations and no output schema.

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 0% on the single 'address' property, so the description must compensate. It implicitly tells the agent this is an EVM token contract address (not a wallet or Solana address) by scoping to 'an ERC-20 on Base/Polygon', but gives no format, checksum, or validation guidance.

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 verb+resource and scope: a static risk read for an ERC-20 token on Base/Polygon, and even enumerates the outputs (liquidity depth, pair count, 0-100 score). The 'EVM' qualifier cleanly separates it from solana_risk_check, but it does not distinguish itself from risk_check or trust_check, which are plausible alternatives.

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?

'Static risk read' implies a point-in-time snapshot rather than continuous monitoring, which is useful context, but there is no explicit when-to-use framing, no statement of when to prefer trust_check/risk_check/token_report instead, and no prerequisites for calling it.

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 useful behavioral trait absent from structured fields — pay-per-call at $0.02 USDC — which establishes cost/read nature. It says nothing about result limits, ordering guarantees, or what happens on an unsupported chain, leaving real gaps for a paid endpoint.

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 purpose in the first clause, then the routing and cost details. The path list is somewhat dense and arguably internal, but every sentence carries information; nothing is redundant 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?

For a single-parameter, no-annotation tool with no output schema, the description covers what it returns, how chains route, and the cost model. It is largely self-sufficient; only return-shape and pagination details are unaddressed.

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 the enum already defines the allowed chains, so baseline is 3. The description adds meaning beyond the schema by mapping each chain value to its concrete endpoint path, clarifying that the parameter selects backend routing, not just a filter.

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 ('Trending DEX pairs by 24h volume'), which is far more precise than the bare name. However, it does not distinguish itself from the sibling solana_trending, and in fact references the solana path that likely belongs to that sibling, leaving the boundary ambiguous.

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: pick a chain and call this to get trending pairs. The path mapping hints that this tool spans multiple chains, but there is no explicit when-to-use vs when-to-use-solana_trending guidance and no stated exclusions.

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 burden and does disclose meaningful traits: pay-per-call pricing ($0.02 USDC), the data sources used (existence, activity, USDC settlements, contract code), and that facts are re-verifiable on-chain. It omits failure behavior, latency, and what happens if payment/verdict fails, so it is not fully transparent.

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?

Compact and front-loaded: the call-to-action constraint ('BEFORE paying') leads, followed by the verdict, scope, and cost. Every clause adds information, with no 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?

For a low-complexity verdict tool with full schema coverage, the description covers trigger timing, verdict outcomes, supported chains, data provenance, and cost. No output schema exists, so return-shape detail is not required, though the integration context (how to pay the call) is left implicit.

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 'target' (address format) and 'chain' (enum, optional/inferred) are already documented in the schema. The description adds no format or inference detail beyond that baseline, so 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?

Clear verb+resource+output: it returns a 'safe|review|avoid verdict' for a wallet/payee, and it names the covered chains (Solana, Base, Polygon) and the fact basis. It does not, however, differentiate itself from the near-identical sibling 'risk_check' (and 'solana_risk_check'), so an agent cannot tell the two apart from the text alone.

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 paying a wallet/payee' gives a clear situational trigger, which is useful context. But it never says when NOT to use it or points to the obvious alternative (risk_check/solana_risk_check), leaving the agent to guess which checker to invoke.

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 it does add real behavioral context: pricing ('Pay-per-call from $0.003 USDC') and per-chain endpoint routing. It stops short of stating read-only semantics, failure modes (e.g., unknown tx), or rate/limit behavior, so the profile is partial but not misleading.

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 purpose and kept to three compact sentences with no filler. The endpoint paths are somewhat internal-facing detail, but they are packed tightly and do not bloat the definition.

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 source for return content; 'status + transfer summary' gestures at it but does not enumerate the fields an agent would receive. For a simple two-parameter read tool this is adequate but leaves return shape and error behavior underspecified.

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 schema already explains that 'id' is a Solana signature or EVM 0x hash and enumerates chains. The description's path mapping (solana -> :signature, base/polygon -> :hash) only restates that distinction rather than adding format or validation detail.

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 verb+resource ('Transaction status + transfer summary') on a per-chain basis, which is clearer than the bare name 'tx'. However, it never distinguishes itself from the sibling 'solana_tx' even though both appear to cover Solana transaction lookups, leaving the agent to guess which to pick.

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 when-to-use or when-not-to-use guidance is given. The description lists chain paths but not the conditions under which this tool should be chosen over the similarly-named 'solana_tx' sibling, which is exactly the ambiguity an agent needs resolved.

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 are provided, so the description carries the full burden. It does disclose useful behavior: it is multichain (Base and Polygon only), returns specific fields, defaults limit to 25, and costs $0.010 USDC. It omits pagination semantics, auth requirements, and whether results are ordered by time.

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?

Compact and front-loaded: identity and scope first, return fields second, query/cost last. No filler sentences, though the phantom 'limit' mention wastes a clause.

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, no annotations, and 0% schema coverage, the description does cover the chain scope and returned fields reasonably well. It still leaves gaps on pagination, ordering, and auth, and the non-existent 'limit' parameter undermines completeness for a paid, single-param 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 0% and the single 'address' param has no schema description; the description does clarify it is an EVM address, which adds some meaning. However it references a 'limit' query parameter that does not exist in the schema (additionalProperties=false), a misleading detail that could cause a rejected call.

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 ('transaction history') with explicit scope: EVM addresses on Base and Polygon, and enumerates the returned fields. It does not explicitly differentiate itself from close siblings like 'tx' or 'tx_receipt', but the field list makes its identity clear.

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 no guidance on when to prefer this over siblings such as 'tx', 'tx_receipt', or 'solana_tx'. 'Recent transactions' implies a recency scope but there are no exclusions, prerequisites, or alternative-routing hints.

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 return payload (status, block/slot, from/to, gas), the auto-detection behavior ('auto-detects chain by hash shape'), and a pricing signal ($0.005 USDC). It omits failure modes for unsupported chains or missing hashes, but the core behavior is disclosed.

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?

One dense sentence that front-loads resource, scope, and return contents, with auto-detection and price trailing. No filler, though the pricing clause is the least essential element for correct invocation.

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 single-parameter read tool with no annotations and no output schema, the description covers what is fetched, which chains are supported, and how the chain is resolved. Missing only edge-case/error behavior, which is minor for this complexity level.

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 0% (bare 'hash' string), so the description must compensate. It clarifies the argument is a transaction hash and that chain is inferred from hash shape rather than passed in, which meaningfully constrains how the caller supplies the single parameter.

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 (normalized transaction receipt) and scope (a transaction hash on Solana, Base or Polygon), so an agent knows exactly what it fetches. It partially differentiates from chain-specific siblings by stating multichain coverage, though it never names tx/solana_tx/tx_history 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: provide a hash and the tool auto-detects the chain, so no chain argument is needed. There is no explicit when-not guidance or named alternative among the many tx-related siblings, so the agent must infer the boundary itself.

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 are provided, so the description carries the full behavioral burden. It discloses only the pay-per-call cost ($0.001 USDC); it says nothing about permissions, error conditions (e.g. invalid/unknown unit), rounding/precision behavior, or limits. These are meaningful gaps for a paid tool with zero 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?

The value/unit enumeration is front-loaded and efficient, but the embedded '-> /x/util/convert' and the pay-per-call cost are jammed into a single run-on line that mixes purpose, endpoint, and billing. It is compact but not cleanly structured.

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 annotations and no output schema, the description must cover behavior fully, yet it omits return format, error handling, and precision/rounding, and only mentions cost. For a paid conversion tool this leaves an agent without essential operational 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?

Schema coverage is 100%, so all three parameters are already documented with examples in the schema. The description's unit lists (verst/sazhen, pood/funt, etc.) add marginal value by signaling accepted unit synsets, but it does not document parameter syntax beyond what the schema provides. 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 (Convert) and resource (value between units), then enumerates the exact unit categories and members supported. This level of detail lets an agent distinguish it from every sibling, none of which perform unit conversion.

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 strongly implied by the enumerated unit families, but there are no explicit when-to-use/when-not-to-use rules and no alternatives named. For a single-purpose utility tool this is adequate, but it is not 4-5 quality guidance.

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 present, the description carries the full burden and does disclose two non-obvious traits: that the call is paid (pay-per-call $0.001 USDC) and exactly what the response contains. It stops short of covering error behavior or failure modes (e.g. invalid timezone or unparseable input).

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, front-loaded with the core action and input/output contract. The trailing endpoint path and price are compact and useful, though the endpoint path adds little for an agent selecting the tool.

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 two-parameter tool with no output schema, the description correctly compensates by spelling out return values and the timezone targeting, and adds the cost model. Only failure/error semantics remain uncovered, which is a minor gap for a pure conversion utility.

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 both parameters fully; baseline is 3. The description restates the accepted value formats (seconds, ms, ISO) rather than adding syntax or edge-case detail beyond the schema.

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 precise verb+resource (convert between unix epoch and human time) and enumerates both accepted inputs (seconds, milliseconds, ISO date) and produced outputs (epoch s+ms, ISO-8601 UTC, timezone-formatted value). This makes it clearly distinguishable from generic siblings like unit_convert without opening their schemas.

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 description implies usage by describing the input/output contract, but never states when to choose this tool over alternatives such as unit_convert, nor any exclusions or preconditions. Context 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?

No annotations are provided, so the description carries the full burden. It does add one genuinely useful behavioral trait – cost ('From $0.005 USDC'), signaling a paid x402-style call – but omits whether the operation is read-only, auth requirements, rate limits, and error 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 tight sentence front-loads the scope before the price tag; nothing is wasted. The pricing tail is partly promotional but still carries information, so it just misses 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?

For a one-parameter, no-output-schema tool the description adequately conveys what comes back (token balances across the listed chains), but with zero annotations and zero schema coverage it leaves the address-format and read-only questions unanswered.

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 single address parameter has 0% schema description coverage and the description does not compensate. It never clarifies the address format, which is a real ambiguity because the tool spans EVM chains (Base, Polygon) and Solana, whose address formats differ.

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 ('Token balances in one call') and enumerates exact scope: native + ERC-20 (USDC/USDT/DAI) on Base and Polygon plus all Solana SPL holdings. This clearly separates it from single-chain siblings like balance or solana_token without needing to name them.

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 'in one call' hints at an efficiency rationale, but there is no explicit when-to-use guidance, no exclusions, and no reference to alternatives such as the 'balance' or 'solana_account' siblings. An agent gets no rule for choosing this over a single-chain 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 and does well: it discloses the returned fields, the supported chains (Base/Polygon/Solana), and the cost floor ('From $0.005 USDC'). It does not explicitly state read-only semantics, auth requirements, or failure modes, but the enumerated behavior is unusually complete for a bare definition.

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?

One dense, front-loaded sentence that leads with the resource and name, then layers output fields, chains, and price. No filler, though the stacked clauses make it slightly 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?

For a single-param read with no output schema and no annotations, the description covers what it returns, which chains it supports, and its cost – enough for an agent to call it correctly. Minor gaps remain around return format and failure handling.

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 0% and the single 'address' param has no schema description, but the description compensates partially by stating the input is 'a wallet or contract,' clarifying that the address may be either an EOA or a contract. It adds meaning beyond the bare string type but not format/chain-specific detail.

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 ('reliability read for a wallet or contract') and enumerates the exact output fields (exists, has code, nonce, native balance, 0-100 score with reasons), so an agent knows what it produces. It does not differentiate itself from close siblings like risk_check, trust_check, or wallet_security, 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?

The 'Pre-payment reliability read' framing implies a usage context (before paying) but never states when to prefer this over risk_check, trust_check, or should_pay, nor any exclusions. Usage is only implied, matching a 3.

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 useful behavior: the underlying data source (GoPlus address security flags) and the exact checks returned (sanctioned, phishing, money laundering, mixer usage, honeypot exposure). It omits error/coverage behavior (chains, missing-data handling), and the trailing 'rolled From $0.010 USDC' appears truncated.

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 in one sentence, which is good, but the ending 'rolled From $0.010 USDC' is a broken fragment that reads as truncated rather than deliberate pricing disclosure.

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 single-parameter read tool with no output schema the description is adequate in coverage of what is checked, but it omits return shape, chain scope, and error behavior, and the garbled tail undermines confidence.

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?

One required parameter with 0% schema description coverage, so the description must compensate; it only implies the input is an EVM address with no format, chain, or checksum guidance. Adds minimal meaning beyond the schema.

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: a 'security/risk report for an EVM address' delivering a 'security score'. The '(EVM)' qualifier plus 'for an EVM address' distinguishes it from siblings like solana_risk_check and token_risk_evm (which covers tokens, not addresses).

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 vs the many adjacent risk tools (risk_check, trust_check, token_risk_evm, solana_risk_check). Usage is only implied by the scoping to EVM addresses.

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 are provided, so the description carries the full burden. It does disclose meaningful traits: the data is sourced live from public indexes and the call costs $0.005 USDC, and it sketches the return shape (a histogram with counts). It stops short of auth requirements, error behavior, or freshness/latency details.

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 return content, then the data source, route, and price. Every sentence earns its place with no 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?

For a zero-parameter read tool with no output schema, the description adequately conveys both the output nature (histogram with counts) and the cost/source context an agent needs. Nothing required to invoke it correctly 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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly indicates there is nothing to configure and instead describes the returned data dimensions.

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 resource (network and payment-asset histogram of the x402 ecosystem) and what it returns (which chains/CAIP-2 ids and USDC/other assets services accept, with counts). It is clearly distinct in kind from generic siblings, though it never names x402_ecosystem_stats as the alternative.

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 only implied by the purpose; there is no explicit when-to-use or when-not-to-use, nor any pointer to the sibling x402_ecosystem_stats. It does flag that the call is pay-per-call ($0.005 USDC), which is useful context for deciding whether to invoke.

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 it discloses several important traits: the data is LIVE with a per-source fetchedAt, the aggregation sources are named (402index.io, Coinbase CDP Bazaar, PayAI Bazaar), and invoking it is a pay-per-call operation costing $0.01 USDC. It stops short of describing caching/rate-limit behavior or how stale the snapshot can be between fetches.

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 paragraph that front-loads the value proposition and the metric list, with the endpoint path and price appended. Every clause carries information, though the '-> /x/x402/stats' arrow fragment is slightly awkward packaging rather than 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?

No output schema exists, so the description must convey the return shape, and it does list the returned dimensions plus the source URL and fetchedAt metadata. It is complete enough to call, with only minor gaps around response formatting and whether all metrics are always present.

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 and there is nothing for the schema to document. The description appropriately spends no words on inputs and instead covers what the no-arg call yields.

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 (x402 ecosystem adoption stats) and enumerates exactly which metrics are returned (service count, networks, payment assets, categories, USD price stats). It does not, however, explicitly differentiate itself from the sibling x402_ecosystem_networks, which an agent could plausibly confuse with the 'networks' dimension mentioned here.

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 context is implied: fetch this when you need ecosystem-wide adoption figures. There is no statement of when-not to use it and no mention of the sibling x402_ecosystem_networks tool, so an agent has to infer the split between a full ecosystem snapshot and a networks-only view.

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