MAD Synapse · Wallets & Risk

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds real beyond-schema context: no network calls, that EVM addresses get a checksum fix, that Solana on-curve wallets are distinguished from PDAs, and that failures return isError without being charged. That pricing/error-billing disclosure is not derivable from any structured field.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core question, then chains, then guarantees, then cost/error semantics. Dense but every clause carries information; the separate 'Price' and 'Errors' fragments add slight sprawl but are justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. For a single-param validator, the description covers supported chains, the no-network guarantee, and error/charge behavior — everything an agent needs to select and call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter and schema description coverage is 100%, so the schema already documents it fully. The description's chain list adds minor framing but no new meaning about the 'address' string beyond what the schema description says.

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 (validate an address) and enumerates exactly which chain formats are handled (EVM, Solana on-curve vs PDA, Bitcoin legacy/P2SH/SegWit/Taproot, Tron, Cosmos bech32). This cleanly differentiates it from siblings like evm_address, ens_resolve, and counterparty_check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

States a clear use context ('catches the typo that would send funds to nowhere') and scopes itself as 'pure checksum and format validation, no network calls', which implicitly routes the agent away from network-dependent siblings. It does not, however, name an alternative tool or state an explicit when-not-to-use condition.

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

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior, so the description's main additions are the upstream source (mempool.space public API), the cost profile ('Price: free'), and the error contract (isError with message, not charged). These are genuinely useful beyond the annotations, though rate limits or caching behavior are unstated.

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 returned fields, then terse 'Price:' and 'Errors:' clauses. Dense and waste-free, though the fragment style is slightly clipped and the returned-field list partly duplicates the output 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 an output schema present, return values need not be described, yet the description adds source, cost, and error handling — enough for an agent to select and call a zero-param read safely. Only the absence of usage routing against sibling network tools is a 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?

The tool takes zero parameters, so the baseline is 4. The description correctly offers no parameter guidance and instead spends its words on return content, which is the right allocation here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (Bitcoin network status) and enumerates exactly what it returns: fee rates, mempool size, block height, difficulty adjustment, hashrate. The chain-specific framing clearly separates it from siblings like solana_network and gas_now.

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 'Bitcoin right now' framing implies a live-snapshot use case, but there is no explicit when-to-use or when-not, and no sibling is named as an alternative. An agent must infer that this is the Bitcoin counterpart to solana_network.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context the annotations do not: per-call price ($0.005, 10 free/day, x402 fallback), and error semantics (isError with message, not charged on upstream failure). This is exactly the cost/failure behavior an agent needs before committing to a paid call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the verdict and its inputs, then layers when-to-use, pricing, and errors in order of decision importance. Dense but nearly every clause earns its place; the server URL is slightly bulky but justified for a paid cross-server pointer.

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 an output schema handling return shape and annotations covering safety, the description only needs to add cost, error, and routing context — all of which it supplies. Nothing an agent needs to decide to invoke it or interpret a payment-required result 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% and the single 'wallet' parameter is fully documented with its Base58 pattern and length in the schema. The description adds no syntax or format detail beyond that, so the schema does the heavy lifting and the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('One-call verdict on a Solana wallet') and enumerates exactly what the verdict covers: serial launcher, fast dumper, bot, or clean, derived from pump.fun launch history and trading profile. This distinguishes it from generic siblings like wallet_holdings or token_risk without the agent needing to open other 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?

Explicitly names the triggering context ('Before sending to or trading with a Solana wallet') and routes to the alternative for a different need ('for full trade stats use pump_wallet'). Both the when and the when-not/alternative are stated.

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

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

Goes beyond the annotations (which already declare read-only/idempotent/non-destructive) by disclosing the resolution verification semantics, that lookups hit Ethereum mainnet, the cost ('free', errors 'not charged'), and the failure contract (isError on invalid input or upstream failure). Missing only rate-limit/caching nuance, so just 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-loaded with the core purpose and each sentence carries distinct information (records, network, verification, price, errors). The parenthetical verification clause and semicolon-chained pricing/error note make it slightly dense for a one-parameter 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?

With an output schema present and 100% param coverage, the description supplies everything else an agent needs: input forms, network, verification behavior, cost, and error semantics. Nothing material is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a single well-described 'query' param, so the baseline of 3 applies. The description's 'vitalik.eth or 0x address' restates the schema without adding syntax or format detail beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific bidirectional verb+resource: 'ENS name → address and address → primary name', plus the exact text records returned (avatar, twitter, github, url, email). Scoping to 'ENS on Ethereum mainnet' implicitly separates it from DNS/WHOIS siblings without opening a 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?

Usage is strongly implied by naming both accepted input forms ('vitalik.eth or 0x address') and the resolution direction, but there is no explicit when-to-use guidance and no named alternatives (e.g., dns_lookup, address_check). Adequate but leaves the agent to infer routing.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), yet the description adds real value beyond them: per-call price and free tier, the x402 payment-required path, and the error contract (isError on invalid input or upstream failure, and that failures are not charged).

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 what is returned, then labeled 'When to use', 'Price', and 'Errors' sections that make skimming easy. Slightly dense and dash-heavy in the opening sentence, but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is unnecessary. Combined with full parameter coverage, annotations, and the cost/error disclosure, an agent has everything needed 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 description coverage is 100%, so chain/token/wallet are fully documented in the schema and the enum is self-evident. The description only restates that a wallet balance is retrievable, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States exactly what is returned (name, symbol, decimals, total supply, USD price, wallet balance) and the mechanism (direct contract calls priced via DefiLlama). It distinguishes itself from the nearest sibling, evm_token_security, by 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?

Explicit 'When to use: For token facts; for scam/honeypot checks use evm_token_security' gives both the condition and the alternative. The 'works for any token, listed or not' clause further clarifies eligibility.

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

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

Annotations already cover read-only/idempotent/open-world, and the description adds substantial context beyond them: data is read straight from each chain's RPC, chain="all" runs in parallel and filters to chains where the address has balance/txs/code, cost is $0.002 per call with 10 free/day and an x402 payment-required result, and errors return isError uncharged. This is rich operational detail an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the payload description, then scoping behavior, then when-to-use, then price, then error handling. Dense but every sentence carries distinct 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?

An output schema exists so return values needn't be spelled out, and the description covers selection criteria, cost/payment path, and error semantics for what is otherwise a simple two-parameter read tool. Nothing needed to call 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 coverage is 100%, so baseline is 3, but the description adds real meaning: it explains that chain="all" is parallel and returns only active chains, which is behavioral semantics the enum alone does not convey. It adds no extra detail on the address parameter, which the pattern already documents.

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 exact data returned (native balance with USD, tx count, contract/wallet classification, ENS name), the resource (any EVM address), and the scope (17 chains, one or all). An agent can immediately tell this apart from evm_tx, ens_resolve, or wallet_holdings without opening a 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?

Includes an explicit 'When to use' clause and names the condition that routes elsewhere ('for Solana wallets use wallet_holdings'), plus explains the chain="all" discovery scenario. It does not mention other EVM-adjacent siblings such as evm_tx or ens_resolve, so routing is clear but not exhaustive.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds materially beyond them: per-call pricing and free-tier limits, the x402 payment-required result, isError behavior on invalid input or upstream failure (not charged), and precisely which flags drain buyers. This is rich disclosure of cost, failure, and output semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then flags, inclusions, use cases, pricing, and errors in a logical sequence; each segment is information-bearing. It is dense and somewhat long, but not padded, so it stays 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?

With an output schema present and annotations covering the safety profile, the description fills the remaining gaps: pricing/limits, error handling, which flags matter, and sibling routing. Nothing needed to invoke or interpret the tool 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 both parameters documented, including the full chain enum and the ERC-20 address pattern. The description only adds the '15+ EVM chains' framing, which is redundant with the schema's enum list, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Honeypot and scam check for any ERC-20') with concrete scope ('15+ EVM chains') and enumerates the exact checks performed. It explicitly distinguishes itself from the sibling token_risk by chain ecosystem, so an agent can route correctly without opening 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?

Includes a dedicated 'When to use' clause: ERC-20s here, Solana tokens via token_risk. It also gives cost context ($0.005/call, 10 free/day, x402 on payment-required) and error semantics, covering when to call and what to expect.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description adds genuinely non-structured behavior: cost ($0.003/call, 10 free/day), the x402 payment-required result after the free tier, and error semantics ('returns isError with a message for invalid input or upstream failure (not charged)'). This is exactly the extra context the annotations cannot convey.

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 and then labeled with 'When to use:', 'Price:', and 'Errors:' for easy scanning. The opening sentence is a long comma-separated list, but every clause earns its place; no 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?

An output schema exists so return values needn't be explained, and the description still covers scope, alternatives, cost model, and failure behavior. Nothing an agent needs to select and call this 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%, so both parameters are fully documented in the schema, and the pattern/default/enum are all present there. The description implies the hash input but never mentions the 'chain' selector, so it adds little beyond the schema; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Any EVM transaction in plain terms') and enumerates exactly what is decoded: status, from/to, value, fee in native and USD, method, and ERC-20 transfers with symbols/amounts. It also explicitly distinguishes itself from the sibling tx_explain (which handles Solana signatures).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use rule ('For 0x hashes') and names the alternative plus the condition that selects it ('for Solana signatures use tx_explain'). Nothing is left to inference, and it goes further by documenting pricing/free-tier behavior.

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

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

Annotations already declare readOnly/idempotent/openWorld/no-destructive, so safety is covered. The description adds genuinely useful non-structured behavior: pricing ($0.025/call, 10 free/day, x402 payment-required result) and error semantics (isError on invalid input or upstream failure, not charged).

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 benefit and 'When to use' are front-loaded, but the definition bloats itself by repeating the full sub-tool server URL and path three times for pump_token/pump_dev/pump_odds. That repetition adds length without adding decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description still usefully summarizes the verdict categories (strong/neutral/weak/avoid). Combined with pricing and error behavior, an agent has enough to invoke and interpret the call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and there is a single well-documented 'mint' parameter with a base58 pattern, so the schema carries the parameter meaning. The description adds no syntax or format detail beyond what the schema already 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 and resource ('one call, one verdict on a pump.fun launch') and enumerates the concrete payload: 0-100 score, positives/risks, graduation odds, dev record, snipers, holders, flow. It also names the exact sub-tools it bundles (pump_token, pump_dev, pump_odds) so an agent understands it is an aggregator rather than a primitive.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'When to use' framing positions it as the one-call verdict and notes it is cheaper than calling the sub-tools separately, which is real routing guidance. It stops short of naming when NOT to use it or comparing directly to sibling token_risk, so it is clear context without 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?

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds real behavioral context: the $1,000 liquidity floor that flags 'dead' tokens, the reason round-trip quotes mislead on dead curves, and that errors return isError without charging. This goes well beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads output and key behavior, then routing, then cost/errors. Mostly earns its place, though the 'Price: free' and error sentences add some parenthetical density that could be tightened without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation. The description still covers scope, routing to the alternative, the liquidity-floor semantics, cost, and error behavior, leaving no material gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single well-documented 'mints' array (pattern, 1-100 items), so the schema carries the parameter burden. The description's 'up to 100 Solana mints' largely restates the schema's maxItems/address constraints, adding little syntax or format detail beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (price) and resource (Solana token mints by address), plus the exact returned fields (USD price, 24h change, liquidity) and the illiquid-token flag. It clearly separates itself from crypto_price for majors/other chains.

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?

Explicitly says when to use it ('For Solana mints by address') and names the alternative with its condition ('for majors or other chains by symbol use crypto_price'), even pointing to the sibling server. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable operational context beyond annotations: the data source ('mainnet RPC: recent performance samples, epoch info, prioritization fees'), pricing ('free'), and error behavior ('returns isError with a message for invalid input or an upstream failure (not charged)').

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 dense but front-loaded with the returned metrics, followed by source, usage guidance, pricing, and errors. The external URL parenthetical is slightly heavy, but every paragraph carries actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value documentation is not required in the description. The description still clearly enumerates the metric coverage, data source, pricing, and error behavior, making it complete for a read-only, zero-parameter network-status 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 takes zero parameters, so parameter semantics are not applicable. Per the baseline for 0-parameter tools, this is a 4.

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 uses a specific resource and metric set: 'Solana right now: TPS (total and non-vote), slot and block height, epoch progress and ETA, priority-fee percentiles, cluster version.' It explicitly distinguishes Solana fee/TPS usage from EVM and BTC fee tools by naming gas_now 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?

It provides an explicit when-to-use section: 'For Solana fees/TPS; for EVM and BTC fee costs use gas_now.' This directly routes the agent between this tool and a relevant 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?

Beyond the read-only, idempotent, non-destructive annotations, the description discloses live data sources (Solana contract state, largest accounts, DexScreener), pump.fun curve-flag merging, pricing with a free tier and x402 payment flow, and error behavior including that failures are not charged. This is unusually rich operational context for an agent.

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 score and risk factors, then cleanly separates 'When to use', 'Price', and 'Errors'. Every sentence contributes useful selection or invocation information without filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return values. It covers purpose, usage, data sources, pricing, and error handling, and the annotations already declare the safety profile, leaving no material gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter is fully documented in the schema with its Base58 pattern and length. The description adds no additional syntax or format detail beyond what the schema already provides, so the 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 and resource ('0-100 rug-risk score for any Solana token') and immediately enumerates the risk dimensions it covers. It also distinguishes itself from siblings by explicitly naming pump_token for curve-stage detail and evm_token_security for EVM tokens.

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 provides an explicit 'When to use' section covering all Solana tokens, pump.fun or not, and directs agents to the correct alternative for pump.fun curve-stage detail and EVM tokens. The conditions selecting each sibling are clearly 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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered; the description adds genuinely new behavior: per-call pricing ($0.003, 10 free/day, x402 payment listing), and error semantics (isError on invalid input/upstream failure and that errors are not charged). These are concrete traits an agent needs and cannot get from the 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?

Front-loaded with what it returns, then scoping alternatives, then cost and error handling. The dense semicolon-separated phrasing packs high information value with 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 single-param read tool with an output schema and full annotation coverage, this description supplies everything else an agent needs: scope, alternatives, cost, and failure behavior. Nothing material 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% and there is a single required parameter whose pattern and format (base58, 64-90 chars) are fully documented in the schema. The description confirms the input is a Solana signature but adds no syntax or format detail beyond the schema, 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?

Opens with a specific verb+resource ('Turns any Solana transaction signature into plain facts') and enumerates the concrete outputs (status, fee, programs, balance changes, summary). It also names the type of transactions covered (swaps, pump.fun trades, LP moves, transfers, failures), making it unmistakable against 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?

Explicitly states 'When to use: For Solana signatures; for 0x hashes use evm_tx', giving both the condition and the named alternative. Nothing about tool selection is left to inference.

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

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

Annotations already cover read-only, idempotent, open-world and non-destructive semantics. The description adds genuinely non-structured traits: the data source (OSV.dev and its aggregated feeds), the per-call price with a 10/day free tier and x402 payment-required result, and error behavior (isError, not charged). Return format is left to the output schema, which is reasonable.

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 but front-loaded: capability, data source, batch usage, when-to-use, pricing, errors. Every sentence carries information, though the pricing/error clauses make it slightly long for a lookup 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?

An output schema exists, so return values need not be described. The description fully covers scope, batch semantics, alternatives, cost, and failure modes — nothing an agent needs 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?

Schema description coverage is 100%, so the baseline is 3, but the description adds real semantic value the schema lacks: the batch string syntax 'ecosystem:name@version', the intent (auditing a lockfile), and the up-to-50 constraint framed as a workflow rather than a bare maxItems.

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 (vulnerability lookup for a package version) and enumerates the returned content: severity, CVE/GHSA ids, and fixed version. It also names the supported ecosystems, which pins down scope precisely.

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?

Explicitly routes the agent: 'When to use: For CVEs in one package version; for general package facts use package_info' — naming the alternative and the condition that selects it, including the sibling's server. This is exactly the when/when-not/alternative structure.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: pricing model ($0.003/call, 10 free/day, x402 options), empty-account handling as reclaimable rent, and isError semantics for invalid input or upstream failure (not charged). This is more than the annotations provide.

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 capability, then scoping, then usage, pricing, and errors in a compact structure. Every sentence carries information, though the pricing clause is somewhat dense and could be split for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return values. It complements the schema by covering chain scoping, pricing, error semantics, and empty-account treatment — everything an agent needs to invoke correctly is 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?

Schema coverage is 100% with only one parameter (wallet) fully documented in the schema, so the description does not need to add parameter detail. The description implies input validation via its error clause but adds no syntax or format beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: it returns everything a Solana wallet holds, enumerating SOL, SPL, and Token-2022 tokens, with USD valuation and value sorting. It distinguishes from the EVM sibling by naming evm_address for EVM wallets. However, it doesn't name its closest Solana siblings (e.g., pump_wallet, solana_network), so the differentiation is good but not fully sharp.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'When to use' guidance is provided: use for Solana wallets, and switch to evm_address for EVM wallets. It also discloses pricing and error semantics. It lacks guidance on when-not-to-use beyond the chain selector, but the chain-specific routing is clear.

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