A.U.G.U.R 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?

Goes well beyond the annotations (which only cover read-only/idempotent/open-world) by disclosing the pricing model ($0.005 per call, 10 free/day, x402 payment-required result) and the error contract (isError with message for invalid input or upstream failure, and that failures are not charged). These are exactly the behavioral facts an agent needs before calling a paid, open-world tool.

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

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

Front-loaded with the verdict, then usage, price, and error behavior in a single dense paragraph; every section carries information. It is slightly overstuffed with parenthetical server/URL detail, which 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?

An output schema exists, so return-shape explanation is not required, and the description still summarizes what the verdict contains (risk level and reasons). With annotations covering the safety profile and pricing/errors covered explicitly, an agent has everything needed to call this 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% and there is only one parameter, whose pattern and Base58 format are fully documented in the schema. The description adds only the framing that the wallet is a Solana counterparty, which the schema already implies — 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 the outputs (serial launcher, fast dumper, trading bot, clean) plus the inputs combined (pump.fun launch history + trading profile). It also distinguishes itself from the trade-stats tool (pump_wallet) and, by scope, from siblings like token_risk or address_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?

Explicit 'When to use: Before sending to or trading with a Solana wallet', and it routes the agent elsewhere for a related need ('for full trade stats use pump_wallet'). The trigger condition and the alternative are both named, leaving little 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?

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, open-world, non-destructive, so the safety profile is covered. The description still adds real behavioral context the annotations cannot: pricing ($0.025/call, 10 free/day, x402 options surfaced on payment-required results) and failure semantics (isError with message, not charged). What it does not add is any note on output size or latency for a multi-source bundle.

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 verdict summary is well front-loaded, but the 'When to use' sentence repeats the full server name and URL three times for pump_token, pump_dev, and pump_odds, which is pure redundancy on a single-server tool. Much of the sentence could be one clause 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?

An output schema exists, so return structure need not be specified, yet the description still enumerates the folded signals and verdict tiers. Safety is covered by annotations, cost and error behavior are explicit, and the single required param is fully documented, leaving no material gap for calling 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% (base58 Solana mint, 32-44 chars, with a regex pattern), so the schema carries the parameter semantics entirely. The description adds no format or constraint detail beyond what the schema already states, 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?

States a concrete verb and resource plus the exact output: a 0-100 score with positives/risks, graduation odds, dev record, snipers, holders, and flow, folded into a strong/neutral/weak/avoid verdict. It explicitly positions itself as a bundle over pump_token, pump_dev, pump_odds, so an agent can distinguish it from a single-signal sibling 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?

Provides an explicit 'When to use' section and names the alternatives it replaces (calling pump_token/pump_dev/pump_odds separately), with a stated selection reason: bundling is cheaper and yields one actionable verdict. The routing decision is fully determined by the description.

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 behavior beyond them: a $1,000 liquidity floor with the rationale for flagging, explicit error semantics (isError on invalid input or upstream failure, not charged), and a free-cost note. That is rich disclosure that the annotations alone would not 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 core purpose and the dead-token rule, then usage and error/pricing details. Dense but every clause earns its place; the billing and error notes add slightly to the length without being wasteful.

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, and the description still covers scope, liquidity semantics, error behavior, cost, and alternative routing. Nothing an agent needs in order 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 description coverage is 100% for the single mints parameter, so the schema fully documents base58 format and the 1-100 range. The description corroborates the 100-mint cap and the 'by address' framing but adds no syntax or format detail beyond the schema. Baseline 3.

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 (USD price, 24h change, liquidity) and scope (up to 100 Solana mints) plus the flagging behavior for illiquid tokens. The mention of the liquidity floor and 'dead' flagging distinguishes it from generic price tools in the sibling list.

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' section: Solana mints by address, and names the alternative (crypto_price on the A.U.G.U.R Synapse · Chain server) with the exact condition (majors or other chains by symbol) that selects it. No inference required.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine non-annotation context: the mainnet RPC sources it reads, that it is free, and that failures surface as isError without charge. It stops short of describing freshness/latency or rate limits, hence a 4 rather than 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 payoff (what data you get) before sources, usage routing, price and errors, and every clause carries content. It is written in a dense telegraphic style with several comma-spliced fragments, which costs a bit of readability but not substance.

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 shape need not be explained, and the description still summarizes what is returned plus data provenance, routing, pricing and failure behavior. For a zero-parameter, read-only status tool this leaves nothing an agent needs 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 there is nothing for the description to disambiguate and the baseline is 4. No parameter-level claim in the description misleads.

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 (Solana network status) and enumerates exactly what is reported: TPS, slot/block height, epoch progress and ETA, priority-fee percentiles, cluster version. It also names the sibling it is not (gas_now for EVM/BTC), so an agent can distinguish it 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?

Has an explicit 'When to use' clause that routes Solana fee/TPS queries here and directs EVM/BTC fee queries to gas_now, including where that sibling lives. The condition for selection is unambiguous rather than inferred.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), but the description adds substantial context beyond them: live data sources (chain state, largest accounts, DexScreener), how bonding-curve liquidity is treated (curve field), cost model ($0.005/call, 10 free/day, x402 payment-required result), and error behavior (isError, not charged). One gap: it does not state freshness/caching or whether results are latency-bound despite 'read live'.

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 (score meaning and inputs) in the first sentence, then layers sourcing, routing, price, and error semantics in discrete clauses. Dense but every block is functional; the data-source enumeration is slightly heavier than strictly needed for 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?

With an output schema present, return values need no explanation, and the description still covers cost, free tier, payment flow, error semantics, data provenance, and cross-server alternatives. 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?

Only one parameter (mint) at 100% schema coverage, so the schema already documents the Base58 format and length. The description adds no extra meaning about the mint beyond noting the returned `curve` field, so the baseline 3 for schema-does-the-work 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 concrete deliverable (0-100 rug-risk score) for a specific resource (any Solana token) and enumerates exactly what feeds the score: mint/freeze authority, Token-2022 extensions, holder concentration, liquidity depth, pump.fun curve flags. It also names the sibling it is not (evm_token_security for EVM, pump_token for curve-stage detail), so the agent can distinguish it 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?

Explicit 'When to use: For any Solana token, pump.fun or not' plus conditional routing to two alternatives — pump_token for pump.fun bonding-curve detail and evm_token_security for EVM tokens. Both the when and the when-not are stated, leaving nothing to inference.

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

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

Annotations already declare readOnly/idempotent/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 only cover the read-only/idempotent/open-world profile; the description goes further by disclosing the upstream source (OSV.dev and its aggregations), the pricing model ($0.002/call, 10 free/day, x402 payment-required result), and error semantics (isError, invalid input or upstream failure not charged). That is exactly the operational context annotations cannot carry.

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 and ecosystems lead, then bulk usage, then the when-to-use rule, then pricing and errors — a sensible front-loading of decision-critical info. It is dense but each clause carries weight; only the ecosystem list is mildly 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?

An output schema exists, so return values needn't be re-explained, yet the description still names the key return fields. Coverage of pricing, sources, limits, and failure modes leaves nothing an agent needs missing before invoking it.

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

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

Schema description coverage is 100% and the schema already lists ecosystems, examples, the 50-item cap, and the "ecosystem:name@version" string format, so the description largely restates it. It adds only marginal meaning (the lockfile-audit framing) and does not clarify how the single-package name/version params interact with the packages array.

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 and resource (known vulnerabilities for a package version), lists supported ecosystems, and enumerates the returned fields (severity, CVE/GHSA ids, fixing version). It explicitly distinguishes itself from package_info, so an agent can route between facts and CVEs unambiguously.

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?

"When to use: For CVEs in one package version; for general package facts use package_info" names both the trigger condition and the alternative, including the server where that alternative lives. The bulk-audit case (up to 50 packages to audit a lockfile) is also spelled out.

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

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

Annotations already 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.