Coinlight: pay-per-call crypto data for agents (x402)

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

Annotations already establish that this is read-only and open-world. The description adds useful behavioral context beyond annotations: it discloses the $0.005 USDC x402 cost and the endpoint, plus what validation result the caller gets back. It does not contradict the annotations.

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

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

The description is short and front-loaded: it explains the validation result first, then the practical reason to use it, then the payment detail. No sentence is wasted.

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

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

For a simple validator with no output schema, the description sufficiently covers the returned concepts (address kind, validity, checksum form). It also discloses the x402 payment model, which is important 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%, so both the address and payment parameters are already well documented in the input schema. The description reinforces what the address input is used for, but does not add syntax or payment semantics beyond the schema and pricing note.

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: it reports the address type (Solana base58 or EVM 0x), validity, and EIP-55 checksum form. This is precise enough for an agent to distinguish it from sibling crypto/balance/transaction tools.

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

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

The phrase 'Catch typos before sending funds' gives a clear intended use case. It does not name competing tools or explicit when-not conditions, but the context is sufficiently clear.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds real value on top: it is a live on-chain read (not cached) and costs $0.005 USDC per call via x402, with the payment endpoint URL. It stops short of describing failure behavior or response shape, but the cost/freshness disclosure is exactly the kind of 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?

Two compact sentences, with the core capability front-loaded ahead of the pricing note. Nothing is redundant with the title or 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?

A read-only tool with no output schema needs the description to hint at return shape, and it doesn't — an agent cannot tell whether it gets two numbers, formatted strings, or token metadata. Pricing and freshness are complete, but the response contract is left open.

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

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

Schema coverage is 100%, so both parameters are already documented, which sets a baseline of 3. The description goes further by explaining the x402 payment model and per-call price, giving the agent the context needed to decide whether to supply the payment header or take the free-trial path.

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: reads live ETH and USDC balances for any address, scoped to Base mainnet. The chain qualifier implicitly separates it from the Solana siblings (solana_sol_balance, solana_usdc_balance), though no sibling is named outright.

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?

Nothing says when to pick this over wallet_portfolio (multi-chain) or the Solana balance tools; the agent must infer routing from the words 'Base mainnet'. No exclusions, prerequisites, or fallback guidance are given.

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=true and openWorldHint=true, and the description adds meaningful operational context: the call costs $0.005 USDC via x402 and provides a payment URL. It does not detail freshness guarantees or rate limits, but the pricing and payment mechanism are important behavioral disclosures beyond annotations.

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

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

The definition is compact and front-loaded: the first sentence states the returned data, and the parenthetical adds payment context without burying the primary purpose. Every part earns its place.

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

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

For a simple read-only tool with one optional parameter, a fully documented schema, and no output schema, the description is complete. It names the key returned values (wei, gwei, latest block, ETH transfer cost, ERC-20 transfer cost) and explains the paid x402 access path.

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 optional payment parameter, so the baseline is 3. The description adds the x402 pricing context but does not otherwise elaborate on the payment parameter beyond what the schema already 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?

The description states a specific resource and verb-like read: current Base gas price, latest block, and transfer costs. It is clearly distinguishable from sibling Solana tools such as solana_priority_fees and covers the returned units explicitly.

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

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

The description implies when the tool is useful by listing gas price, latest block, and transfer-cost outputs, but it does not explicitly state when to use it versus alternatives or when not to use it. Usage is inferable from the resource description rather than guided.

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=true and openWorldHint=true, so the safety and external-lookup profile is covered. The description adds useful behavioral context beyond annotations by disclosing the $0.005 USDC per-call x402 payment and the payment endpoint URL.

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 two sentences and front-loads the core action before appending payment details. There is no wasted text, and every sentence contributes to understanding the tool.

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

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

For a simple read-only lookup with a fully described schema and no output schema, the description is complete enough. It states the chain, the lookup input, the returned fields, and the payment model.

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

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

Schema description coverage is 100%, so the schema already documents both the required hash and optional payment parameter. The description mentions the hash lookup and pricing, but it does not add syntax or format details beyond what the schema provides.

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

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

The description states a specific verb and resource: looking up a Base transaction hash. It also enumerates the exact status and detail fields returned, which clearly differentiates it from chain-specific siblings like solana_transaction and from tx_explain.

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

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

The description implies usage by saying it looks up a Base transaction hash, which gives enough context to know it is for Base chain transactions. However, it does not explicitly say when to use this instead of tx_explain or solana_transaction, nor does it state 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 declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely new context the annotations cannot carry: the cost ($0.005 USDC per call via x402) and the payment endpoint, which the agent needs before invoking. It does not describe behavior on invalid input or mismatched encodings, keeping it short of a 5.

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

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

Two compact clauses: the capability first, then the pricing/payment pointer. No filler, and the most decision-relevant information (what it converts, what it costs) is front-loaded.

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

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

For a simple deterministic conversion tool with full schema coverage and no output schema, the description covers purpose, cost, and the payment flow pointer. The main residual gap is not stating that output is a single encoded string and what happens on invalid input, but the omission is minor at this complexity.

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

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

Schema description coverage is 100% and the from/to enums are fully self-documenting, so the description adds little beyond restating the four encodings. The only extra semantic value is the note that base58 is what Solana keys and signatures use, which suggests valid inputs but not formats or error cases.

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

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

States a specific verb (Convert) and resource (data between utf8, hex, base64, base58), and the parenthetical that Solana keys/signatures use base58 grounds the tool in a concrete use case. It's easy to distinguish from siblings like hash or uuid, though it never names an alternative explicitly.

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

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

Usage is implied rather than stated: the Solana base58 note hints at the main scenario, but there is no explicit 'use this when…' or 'prefer X instead' guidance, and no mention of when a different tool (hash, uuid, units_convert) would be the right choice.

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

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

Annotations already declare readOnly and open-world, so safety is covered. The description adds genuinely non-obvious behavior: dual output formats (hex and base64), and a per-call price with the x402 payment endpoint, which annotations cannot convey. It stops short of explaining the free-trial/payment-requirements fallback documented in 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?

One sentence plus a parenthetical price note; the capability is front-loaded and the algorithm/output detail follows naturally. The pricing parenthetical is slightly clunky but earns its place by flagging a cost constraint.

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

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

With no output schema, the description usefully tells the agent that both hex and base64 are returned, and it discloses pricing. What an agent still has to dig for — the free-trial behavior and the payment-requirements response — lives in the schema, which is acceptable at full coverage.

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

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

Schema coverage is 100%, so all three parameters including the algo enum and the payment header are already documented. The description's algorithm list restates the enum rather than adding format or defaulting nuance, so baseline 3 applies.

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

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

States a specific verb (hash) and resource (string) plus the exact algorithm set and output encodings, which clearly separates it from siblings like encode or text_stats. An agent can tell at a glance this is a pure cryptographic digest, not an encoder.

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 three concrete use cases (commitments, idempotency keys, checks), which implies when to reach for it. However, it never states when NOT to use it or names an alternative (e.g., encode for non-cryptographic transforms), so selection guidance is only implied.

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 say read-only and open-world; the description goes much further by naming the ordering guarantee (newest first), the specific red-flag heuristics triggered (no liquidity, sells far below buys, extreme FDV/liquidity), and a real cost gate ($0.005 USDC per call via x402 with a URL). Cost and payment-gating disclosure is exactly the kind of behavior 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?

One dense paragraph, front-loaded with the resource and ordering, then filters, then the follow-on action, then pricing. Every clause carries information; nothing is repeated or padded.

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

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

There is no output schema, and the description compensates by enumerating the returned fields (age in minutes, liquidity, 5m/1h volume, buy/sell split, red flags). Combined with pricing and the recommended next call, an agent has everything needed to invoke it and interpret results.

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 all four parameters are already documented with defaults and ranges. The description only restates the liquidity/age filters in prose and adds nothing about the chain or payment parameter, so the baseline 3 applies.

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

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

States a specific resource ('Freshest DEX pools on Solana or Base, newest first') plus the exact fields returned (age, liquidity, 5m/1h volume, buys/sells, red flags). That is enough to separate it from sibling feeds like token_pairs, token_new_profiles, or token_boosted 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?

Gives concrete operating instructions ('filter by minimum liquidity and maximum age') and a follow-on step ('pipe results into token-sell-check before buying'), naming a sibling explicitly. It never states when NOT to use it versus a broader pool feed like token_pairs, so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds important behavioral context beyond annotations by disclosing the per-call price and x402 payment endpoint, which is material for invocation.

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

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

The description is front-loaded with the core question and a compact list of returned account attributes. The price and payment URL add useful detail without excessive verbosity, though the question-style opening is slightly informal.

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

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

There is no output schema, but the description compensates by listing the main fields and parsed account types returned. Combined with the fully documented input schema and read-only annotations, it gives enough context for an agent to call the tool correctly.

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

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

Schema description coverage is 100%, and both parameters are documented in the schema, including the base58 address format and the optional payment signature. The description does not add parameter-level syntax or semantics beyond mentioning the price/payment mechanism, so baseline 3 is appropriate.

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

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

The description states a specific resource and enumerates what the tool returns: owner program, lamports, executable flag, data size, and parsed account type. It clearly identifies the operation as inspecting a Solana address rather than fetching balances or transactions, though it does not explicitly name sibling alternatives.

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

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

The opening question implies the use case: inspect a Solana address to learn what kind of account it is. It does not explicitly say when to choose this over siblings like solana_sol_balance, solana_token_balances, or solana_transaction, leaving alternatives 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 and openWorldHint, so the safety profile is partly covered; the description adds genuinely new behavioral context — deterministic/offline computation, dual program support, and per-call cost ($0.005 USDC via x402). The pricing and payment model is valuable disclosure beyond annotations.

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

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

Two compact sentences front-load the core purpose and follow with program support and payment detail. No wasted text, though the payment URL is somewhat dense within a single line.

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 deterministic derivation tool with a fully documented schema and no output schema, the description covers purpose, supported programs, and the payment model. It does not explicitly state the return shape (a base58 address), but that is strongly implied by 'derive the address'.

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

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

Schema coverage is 100%, so the schema already documents owner, mint, program, and payment. The description only reiterates owner/mint/program support and adds nothing about parameter format or defaults 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?

States a specific verb and resource — 'derive the associated token account (ATA) address' — for a given owner and mint, and notes spl-token/token-2022 support. An agent can immediately understand what it computes, though it does not explicitly differentiate itself from siblings like solana_token_balances or address_validate.

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 notes the operation is 'offline and deterministic', which implies when it is appropriate (pure derivation, no network state), but it gives no explicit when-to-use vs alternative guidance or exclusions relative to sibling token-address tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context by disclosing the $0.005 USDC per-call cost and the x402 payment endpoint, which is information not present in the annotations. It does not cover data freshness, rate limits, or failure behavior, but it adds substantial payment and access context.

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 two sentences and is front-loaded with the tool's purpose and returned metrics. The second sentence adds necessary payment context without unnecessary detail, so every sentence earns its place.

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

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

For a read-only network status tool with one optional parameter and no output schema, the description is largely complete. It names the key metrics returned and explains the payment mechanism, though it does not describe the response shape, units, or data freshness in detail.

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

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

There is only one optional parameter, and the input schema fully documents the x402 PAYMENT-SIGNATURE usage, including how omitting it triggers a free trial or payment requirements. The description does not discuss the payment parameter directly, but schema coverage is 100%, so the baseline of 3 is appropriate.

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

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

The description states a specific resource and scope: Solana mainnet health, with explicit metrics including current slot, block height, epoch progress, and recent TPS. It is clear what the tool returns, though it does not explicitly differentiate itself from sibling Solana tools such as solana_recent_transactions or solana_priority_fees.

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

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

The phrase 'in one call' implies this is an aggregate health snapshot rather than a tool for querying individual metrics, which gives some usage context. However, it does not explicitly say when to use this tool instead of sibling Solana tools, nor does it state exclusions or prerequisites beyond the payment note.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description earns credit for adding the paid-call model ($0.005 USDC via x402) and the endpoint, plus the percentile return shape. It omits the freshness/window of 'recent' data and failure or rate-limit behavior, keeping it below 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?

A single front-loaded sentence states the resource, unit, and return distribution, with the pricing footer clearly bracketed as a separate concern. No redundant restatement of the name or annotations.

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

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

For a zero-required-parameter read tool with no output schema, the description supplies the return shape, units, and cost model, which is most of what an agent needs. The one gap is the time window behind 'recent' fees, which matters for pricing decisions.

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 `account` (scoping to a pool/program) and `payment` (x402 signature, free-trial fallback) are already documented in the schema. The description adds no parameter-level detail beyond that, 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?

Names a specific resource (recent Solana prioritization fees) with units (micro-lamports per compute unit) and the exact output shape (p25/p50/p75/p90). An agent can distinguish this from sibling fee tools like base_gas purely on chain and output form without opening the schema.

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

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

Gives a concrete use case: 'so an agent can price a transaction that lands', which tells the caller this is for fee-setting before submitting a transaction. It stops short of stating exclusions or naming alternatives (e.g., when to use a network-status or transaction-inspection tool instead).

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 and openWorldHint, so the safety profile is covered. The description adds genuinely useful context beyond that: the per-call cost ($0.005 USDC via x402) and the endpoint, plus the shape of the returned fields. It does not explain what a free-trial call yields or how many calls are free, but the paid-call disclosure is a real value-add.

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

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

Two sentences, front-loaded with the resource and returned fields, then the limit constraint, then pricing. Nothing is wasted, though the raw pricing URL is slightly bulky for the information it carries.

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 read-only single-address query with no output schema, the description covers what is returned, the count constraint, and the payment model, which is enough for an agent to call it correctly. Only the free-trial/payment-requirement behavior is left entirely to the schema.

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

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

Schema description coverage is 100%, so the schema already documents address (base58), limit (1-50, default 10), and payment. The description only restates the limit range and default, adding no new semantics. Baseline 3 is appropriate when the schema does all the work.

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 (most recent transaction signatures for a Solana address) and enumerates the returned fields (slot, time, success flag, memo). It implicitly separates itself from the singular sibling solana_transaction, but never names that sibling, so sibling differentiation is left to inference.

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

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

Usage is only implied: an agent can infer this is the tool for recent activity on an address, and the limit default (10) hints at the common case. There is no explicit when-to-use vs when-not, and no mention of when solana_transaction or solana_account_info would be the better choice.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: live mainnet reads and a per-call cost of $0.005 USDC via x402, though it does not describe rate limits or error behavior.

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

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

The definition is front-loaded with the core purpose in one sentence, followed by a compact payment note. There is no redundant or filler text.

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

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

For a simple read-only balance lookup, the description covers the returned units, data source, and payment context, while the schema fully documents both parameters. No output schema exists, but the return units are stated clearly enough for this tool.

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

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

Schema description coverage is 100%, so both the address and payment parameters are already documented in the schema. The description adds no additional parameter syntax or constraints beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific resource and scope: native SOL balance for any Solana address, returned in SOL and lamports from mainnet. This clearly distinguishes it from sibling tools such as solana_usdc_balance and solana_token_balances.

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

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

The phrase 'Native SOL balance' gives clear context that this tool is for native SOL rather than tokens or USDC. However, it does not explicitly name alternatives or state when not to use it, leaving some routing inference to the agent.

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 and openWorldHint, and the description adds live mainnet data plus concrete x402 cost/payment endpoint context. It does not detail rate limits or pagination, but it adds meaningful behavioral context beyond annotations.

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

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

A single compact sentence front-loads the holdings scope and returned fields, with pricing as a short parenthetical. There is no wasted preamble.

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

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

No output schema exists, but the description enumerates returned fields (mint, amount, decimals, token account) and explains the payment model. For a simple read-only all-balances call this is nearly complete, with only minor gaps around pagination or error behavior.

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

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

Schema description coverage is 100%, covering both address (base58) and payment (x402 PAYMENT-SIGNATURE, free trial/payment requirements). The description reinforces pricing and the x402 endpoint but adds little parameter meaning beyond the schema.

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

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

States the exact resource and scope: all non-zero SPL and Token-2022 balances held by a Solana wallet, plus the returned fields. This distinguishes it from native SOL/USDC balance siblings by token standard and by excluding zero balances.

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

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

Implies use for enumerating SPL/Token-2022 holdings, but never explicitly says when to choose it over solana_sol_balance, solana_usdc_balance, or wallet_portfolio, nor states exclusions. Usage is inferable from the scope only.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds useful context: data comes from Solana mainnet, the call costs 0.01 USDC via x402, and the payment parameter supports an optional free trial. It does not cover failure modes or rate-limit behavior.

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

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

The purpose and returned metrics are front-loaded, which is good. However, the price is stated twice with essentially the same information, and the repeated x402 pricing parenthetical does not earn its place.

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

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

There is no output schema, but the description enumerates the returned safety metrics, data source, cost, and payment behavior. That is enough for an agent to call it correctly, though response format and error behavior are not described.

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 documents both the required mint and optional payment parameters. The description reinforces the mint input with an example but adds little semantic detail beyond what the schema already provides.

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

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

The description states a specific verb and resource, 'Solana token safety check,' and enumerates the exact safety signals returned. This distinguishes it from siblings like token_price or solana_top_holders, but it does not explicitly name an alternative.

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

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

It tells the agent to pass a mint address to get safety data, implying use when a token safety assessment is needed. However, it gives no explicit when-to-use versus alternatives such as solana_top_holders or token_sell_check, and no when-not-to-use guidance.

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

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

Annotations already cover read-only and open-world behavior, so the bar is lower; the description adds the concrete cost model ($0.005 USDC per call via x402) and the payment endpoint, which is material for deciding whether to call it. It does not state whether results are cached or how staleness is handled.

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

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

A single front-loaded sentence states what is returned, followed by a compact pricing note. The raw URL is slightly noisy but earns its place as the payment endpoint.

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

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

With only two parameters, full schema coverage and no output schema, the description covers the essential behavior and enumerates the returned fields well enough for an agent to know what it will get back. Missing only edge-case behavior for invalid or non-existent mints.

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 the mint address format and the payment header semantics already documented in the schema. The description adds nothing about either parameter, so the baseline 3 applies.

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

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

The description names the resource (SPL token mint) and the exact data returned: total supply, decimals, mint authority and freeze authority. That distinguishes it well from balance-oriented siblings such as solana_token_balances and safety-oriented solana_token_safety, though it never names an alternative explicitly.

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

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

Usage is implied by the returned fields (metadata/authority lookup rather than holder or balance data), but there is no explicit when-to-use or when-not-to-use guidance, nor any mention of the sibling tools an agent might confuse this with.

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 and open-world traits, yet the description adds genuinely new behavioral context: a hard cap of 20 results and a $0.005 USDC per-call x402 charge with the payment endpoint URL. It does not mention ordering or whether shortfalls below 20 accounts occur, so it is strong but not exhaustive.

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?

Results are described first, then the analytical use case, then pricing — a well front-loaded order with no filler. The trailing pricing parenthetical is slightly clunky but carries real cost information an agent needs before calling.

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

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

With no output schema, the description does the work of explaining the return: up to 20 accounts with owner and supply share. The main residual gap is result ordering and edge-case behavior, minor for a two-parameter read tool whose annotations already signal safety.

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

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

Schema coverage is 100%, with both the mint address format and the optional x402 payment header fully documented inline. The description only echoes the mint concept and the payment model, adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource: the largest 20 token accounts of an SPL mint, plus the returned fields (owner wallet, share of supply). That is clearly distinct from the balance-listing sibling solana_token_balances, but the description never names or contrasts with alternatives.

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

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

"Spot whale or insider concentration" gives a concrete analytical use case that tells an agent when this tool is the right pick over a plain balance query. It offers no explicit when-not conditions or named alternatives, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds genuinely new behavior: a metered $0.005 USDC cost per call and the x402 payment endpoint. It does not cover failure modes (invalid signature, unpaid request) or return shape beyond field names, which keeps it from 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?

One front-loaded sentence delivers the operation and returned fields, with the cost and endpoint appended as a compact second clause. No filler and nothing buried.

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

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

There is no output schema, and the description compensates by naming the decoded fields (status, fee, signer, programs, balance changes), so the agent knows roughly what comes back. Missing only error/payment-failure behavior for a paid, open-world lookup.

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

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

Schema coverage is 100%, with both the base58 signature format and the optional x402 PAYMENT-SIGNATURE header documented in the schema itself. The description only echoes that a signature is needed, adding no syntax or format detail beyond structured fields.

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 ('Decode a Solana transaction by signature') and enumerates the returned summary fields, which separates it from the list-oriented sibling solana_recent_transactions. The 'by signature' scope makes the distinction from other lookup tools explicit 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 only implied by the input requirement ('by signature'); there is no statement of when to prefer this over solana_recent_transactions or tx_explain, nor any exclusion. The pricing/payment note is operational context rather than guidance on tool selection.

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 and openWorldHint, so the safety profile is covered. The description adds genuinely useful context annotations cannot: the $0.005 USDC per-call cost and the x402 payment endpoint, which affects whether an agent can call it at all.

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

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

Two short sentences plus a pricing note, with the core purpose front-loaded. No filler, though the pricing detail is tucked in a trailing parenthetical rather than surfaced as a callability constraint.

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

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

With no output schema, the description leaves the return shape undefined — a decimal USDC amount, raw base units, or a per-account breakdown? It also doesn't say what happens when the wallet has zero USDC token accounts. Adequate for selection, incomplete for interpretation.

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

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

Schema coverage is 100%, with both 'address' and 'payment' documented in the schema itself, so baseline is 3. The description adds nothing about parameter behavior (e.g., what happens with an invalid base58 address or when the payment header is omitted) beyond what the schema states.

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

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

States a specific resource and scope: "USDC balance of a Solana wallet (sum of all USDC token accounts)." The parenthetical distinguishes it from solana_token_balances (per-token listing) and solana_sol_balance (native SOL), though neither sibling is named explicitly.

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

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

"Useful before paying or invoicing an agent" gives one implied use case but no when-not guidance and no routing to alternatives such as solana_token_balances for other SPL tokens or wallet_portfolio for a full picture.

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 declare readOnlyHint and openWorldHint, and the description adds genuinely new context: per-call pricing ($0.005 USDC via x402) and the payment endpoint. This exceeds what the annotations convey, though it doesn't describe the return shape.

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

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

Two tight sentences: the capability and its purpose come first, with pricing tucked into parentheses. Nothing is wasted.

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

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

No output schema exists, so the description should ideally hint at the returned stats, but the enumerated counts plus payment mechanics make it sufficient for correct invocation. Minor gap in return-value framing.

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

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

Schema coverage is 100% and both parameters (text, payment) are well documented in the schema, including the free-trial/payment-requirements behavior. The description adds little beyond that, so baseline 3 applies.

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

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

States a specific verb and resource — count characters, words, lines, bytes and estimate LLM tokens — plus the agent-facing reason (budget context). Unambiguously distinct from the blockchain/crypto 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 frames the use case: 'so an agent can budget context before sending it.' Clear context, but no exclusions or named alternatives for when not to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior: a per-call price ($0.005 USDC via x402) and a payment endpoint, which an agent must know before calling. It stops short of explaining failure modes when payment is missing or how granularity is auto-detected.

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

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

Two tight sentences: capability and return shapes first, the zero-arg default second, with the cost/payment note clearly appended as a call-to-action. Nothing redundant and 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?

With no output schema, the description carries the burden by naming all four returned formats, and it covers payment prerequisites and the default-input case. Together with the annotations, an agent has everything needed to decide and 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 coverage is 100%, so the baseline is 3, but the description adds the semantic that an absent 'value' means 'now' rather than an error, which the schema only calls 'Optional'. The accepted formats (seconds, ms, ISO) are repeated from the schema rather than extended.

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 ('Convert a unix timestamp ... or ISO date') and enumerates the exact output representations, which no sibling (e.g. units_convert) claims. An agent can tell instantly that this is the timestamp-normalization tool rather than a generic unit converter.

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?

'Omit input for the current time' gives a concrete invocation condition for the zero-argument case, and the schema note explains when to omit payment. It does not, however, contrast itself with the adjacent units_convert tool or state any exclusions, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description's added value is the pricing and payment mechanics ($0.005 USDC per call via x402 with a payment URL), which an agent cannot infer from structured fields. It also notes the data is real-time ('right now'). Return format and pagination are not described, keeping it below 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?

Two sentences with the core purpose front-loaded and the pricing parenthetical last, which is appropriate placement. The payment URL is somewhat bulky but earns its place as cost/auth information.

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

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

For a two-optional-parameter read-only listing with no output schema, the description covers what the data is, its recency, the optional filter, and the payment requirement. Only the shape of the returned list is unspecified, a minor gap.

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

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

Schema coverage is 100%, so both parameters are already documented, including the payment/free-trial nuance. The description reinforces the optional chain filter, adding marginal clarity but no new syntax or semantics beyond the schema.

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

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

States a specific resource and a precise data source: 'Tokens with the most active DexScreener boosts right now.' The 'boosts' concept is distinctive enough to separate it from siblings like token_price, token_pairs, and token_new_profiles, though no sibling is named explicitly.

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

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

The phrase 'optionally filtered by chain' gives minimal usage context, but there is no explicit when-to-use versus token_new_profiles or token_search, and no exclusions. Usage is implied by the description of the data rather than 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 cover read-only and open-world semantics, and the description adds substantive context they don't: a per-call price ($0.005 USDC via x402) and the endpoint, plus the notion that results are profile-publication events rather than price data. It stops short of describing result ordering or pagination, so not 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?

Two compact sentences with the core purpose front-loaded and pricing kept to a parenthetical. Every element earns its place, though the URL/pricing clause is slightly heavier than needed at the head of the definition.

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

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

With no output schema, the description still conveys what a result contains (token profile with logo and links) and discloses the paid x402 access path, which is the main failure mode for an agent. Ordering/limit behavior is unspecified, keeping it below 5.

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 'chain' and 'payment' are already documented in the schema with examples and an omit-for-free-trial note. The description adds only a restatement of the optional chain filter; baseline 3 applies.

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

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

States a specific resource ('latest tokens that just published a DexScreener profile') and what data it carries (logo, links), plus a scope constraint (optional chain filter). It does not explicitly differentiate from the sibling 'new_launches', so it falls short of a 5.

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

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

The 'early signal of new launches' framing implies when the tool is useful, and the payment note tells the agent how to call it. But there is no explicit when-to-use/when-not or named alternative (e.g. new_launches, token_pairs), leaving selection guidance implicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral context: the cost per call ($0.005 USDC via x402), chain coverage, sorting criterion, and returned fields. It does not detail rate limits or error behavior, but the key financial and scoping traits are disclosed.

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

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

The description is two sentences, front-loaded with the core purpose and followed by the cost detail. Every element earns its place: the chain examples clarify scope, the metric list specifies output, and the pricing sentence is essential for invocation.

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

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

Given moderate complexity, full schema coverage, annotations, and no output schema, the description provides enough for an agent to call the tool correctly: it states chain coverage, sorting, returned metrics, and cost. It omits details like pagination or result limits, but those are minor gaps for this type of tool.

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

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

Schema description coverage is 100%, so both parameters (token and payment) are already well documented in the schema. The description adds only high-level context ('for a token on any chain') and does not elaborate on the payment parameter or address formats beyond what the schema provides. Baseline 3 is appropriate when the schema carries the parameter semantics.

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

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

The description clearly states that this tool returns top DEX trading pairs for a token across multiple chains, sorted by liquidity, and lists the metrics included. It is specific enough to distinguish it from a simple price lookup, though it does not explicitly name sibling alternatives like token_price.

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 tool's intended use is implied by 'Top DEX trading pairs for a token on any chain,' but there is no explicit guidance on when to choose this over token_price, token_sell_check, or other token-related siblings. The payment context is mentioned, but no when-not conditions are provided.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious context: the Jupiter feed source, the 20-mint cap, the availability caveat on 24h change, and a $0.005 per-call x402 charge with an endpoint URL. Only return shape/pagination is left 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?

Two sentences, with the core capability front-loaded before the cost/endpoint parenthetical. Nothing is wasted, though the raw URL is marginally less useful than a plain cost statement.

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

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

For a two-parameter read-only pricing tool with no output schema, the description covers source, batch limit, what is returned (USD price plus optional 24h change), and the payment model. An agent has enough to invoke it correctly; only response structure is unspecified.

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

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

Schema coverage is 100%, so both mints and payment are already documented in the schema, including the comma-separated format and trial-call behavior. The description restates the 20-mint limit but adds no new syntax or format guidance, so the baseline of 3 applies.

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

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

States a specific verb and resource: live USD prices for Solana token mints, sourced from Jupiter, batched up to 20. That clearly separates it from market-data siblings like token_pairs or token_search, though those alternatives are never named.

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

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

The description implies usage (batch pricing lookups, per-call cost) but never says when to prefer it over token_pairs, token_search, or token_sell_check. Usage is inferable from the pricing model rather than 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 readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful non-schema context: a fixed cost ($0.005 USDC per call), the x402 payment mechanism, the free-trial/payment-requirements fallback, and that results are ranked by liquidity rather than arbitrary order.

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

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

Two sentences plus a parenthetical price note, with the core purpose front-loaded before the resolution example and the payment detail last. No sentence is redundant and the cost disclosure is compact rather than buried in prose.

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

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

With no output schema, the description carries the burden of describing returns and does so ('most liquid matching pairs with contract addresses'), and it explains the payment gate that would otherwise cause a surprising failure. It stops short of covering result counts, pagination, or what happens on no-match/multi-chain ambiguity.

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 q, chain, and payment are already documented in the schema, including the enum-like chain examples. The description adds no syntax or formatting detail beyond that, so the baseline of 3 applies; the 'most liquid matching pairs' note informs result ranking, not parameter behavior.

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

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

States a specific verb and resource ('Find tokens by name, symbol or address across chains') and clarifies the downstream outcome: resolving a ticker like 'BONK' to a contract address. It implicitly separates itself from price/pairs siblings by emphasizing identity resolution over market data, but never names an alternative explicitly.

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

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

The resolution use case ('so an agent can resolve BONK to a mint') gives an implied trigger for calling it, which is more than nothing. However, there is no guidance on when not to use it, and no pointer to siblings like token_price, token_pairs, or solana_token_safety that an agent might confuse it with.

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

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

With readOnlyHint already declaring the safety profile, the description still adds non-obvious behavior: it is keyless, chain is auto-detected, it performs real routing quotes with simulated loss and price impact, and it explicitly avoids false honeypot labels for bonding-curve tokens. It also discloses the $0.005 USDC x402 charge and the endpoint, which 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?

The most important facts (keyless, chain auto-detect, what is checked, verdicts, price) are front-loaded, and every sentence carries information. It is dense and runs long as a single block, so the per-chain detail could be tightened, but there is 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?

No output schema exists, and the description compensates by enumerating the verdict values (SELLABLE / RISKY / UNKNOWN / UNSELLABLE) and the reason categories that feed them. Combined with the per-chain check lists and the note about bonding-curve exceptions, an agent has everything needed to call it and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above baseline by tying the round-trip loss %, price impact and simulated trade size to the sizeUsd input and by making chain auto-detection from the token address explicit. The payment/x402 mechanics are also named inline, so an agent seeing the optional 'payment' field knows why it exists.

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 title and first sentence name the exact action ('pre-trade honeypot check'), the two chains covered, and what the call actually does (quote a real buy-then-sell round trip). It is clearly differentiated from siblings like solana_token_safety and solana_top_holders, which inspect static token/state data rather than simulating a sell.

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

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

The 'pre-trade' framing plus concrete guidance for pre-migration pump.fun / Raydium LaunchLab tokens tells the agent when the Jupiter-based verdict should and should not be trusted. It does not explicitly name a sibling alternative or state exclusions for tokens on other chains, so the routing guidance 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 only declare readOnlyHint and openWorldHint; the description adds genuinely useful non-obvious behavior: a per-call price ($0.005 USDC via x402) and a payment URL. It also enumerates the return contents (sentence, action type, net asset changes, fee). It does not cover failure modes such as unsupported chain or unparseable hash, which keeps it at 4.

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

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

A single tight paragraph, front-loaded with what the tool does and immediately followed by the return contract and pricing. Every clause carries information; only the trailing URL/price block is slightly dense, but it is operationally necessary.

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

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

With no output schema, the description correctly assumes the burden of describing return values and does so concretely (one-sentence explanation, action type enum-like list, net asset changes, fee). Payment semantics are left to the schema. Only error/edge-case behavior is unaddressed.

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

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

Schema coverage is 100%, so the schema already documents both parameters and the baseline is 3. The description adds meaning beyond the schema by noting chain auto-detection (i.e. the agent must not supply a chain) and by framing the paid-per-call model that governs the optional payment parameter.

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

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

States a specific verb (explain), resource (Solana/Base transaction), and the exact output shape with a concrete example ('Wallet X swapped 0.5 SOL for 1,203,442 BONK on Jupiter'). This clearly separates it from siblings like solana_transaction or base_transaction, which fetch raw transaction data rather than a natural-language summary.

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?

'Paste any Solana signature or Base tx hash' tells the agent exactly what input triggers the tool, and 'Chain auto-detected' removes a decision the agent might otherwise agonize over. It does not explicitly say when to prefer this over raw transaction-lookup siblings, so it stops short of a 5.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses two genuinely useful traits: results are exact and bigint-safe (no float precision loss), and each call costs $0.005 USDC via x402 at a specific endpoint. It does not explain rounding or behavior when from equals the target unit, so it stops 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?

Two sentences, both earning their place: the conversion scope and precision guarantee come first, the pricing/endpoint detail second. No filler and no repetition of the title.

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

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

There is no output schema, yet the description never states what a successful result looks like (a string? the converted amount plus unit?) or how payment failures surface. Annotations and 100% schema coverage handle the safety and input side, so the remaining gap is the return contract, which matters for a converter an agent must chain into further arithmetic.

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

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

Schema description coverage is 100%, so the schema already documents amount, from, payment, and decimals, giving a baseline of 3. The description adds some meaning by tying 'usdc' to 6 decimals and covering the generic units/atomic case with arbitrary decimals, but it does not clarify the payment-signature flow beyond what the schema 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?

States a specific verb ('conversion') and resource (human vs atomic units) and enumerates the exact currency pairs supported (SOL<->lamports, ETH<->gwei<->wei, USDC<->atomic). This lets an agent distinguish it from the similar-sounding sibling time_convert without opening either schema.

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

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

The enumerated pair list makes the applicable domain clear and implicitly excludes time_convert. However, there is no explicit 'when not to use' statement or a named alternative for edge cases such as passing identical from/to units.

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=true and openWorldHint=true. The description adds useful behavioral context beyond that: the values come from a cryptographic RNG, the output count is bounded to 1-50, and calls are paid via x402 unless a free trial is used.

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

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

It is a single well-structured sentence with the core behavior front-loaded and the pricing note in a compact parenthetical. Every clause contributes useful information.

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

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

For a two-parameter, read-only UUID generator with full schema coverage and clear annotations, the description supplies everything needed: count range, RNG quality, intended use, and payment model. No output schema is necessary because the result format is self-evident.

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. The description reinforces the count range and gives a use case but does not add syntax or semantics beyond what the schema already provides.

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

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

The description states a specific verb and resource ('Generate random v4 UUIDs') plus the allowed count range and RNG type. It is immediately distinguishable from all sibling tools, none of which generate UUIDs.

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

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

It gives an example use case ('idempotency keys') but does not explicitly state when to use this tool versus alternatives or any when-not conditions. Usage is implied rather than guided.

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 and open-world behavior, but the description adds real value: live DEX liquidity pricing, value-sorted output, dust and unpriced tokens flagged, and a concrete cost of $0.005 USDC per call via x402 with the endpoint URL. It does not disclose fallback behavior when a token has no liquidity or what the free-trial response looks like.

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?

Payload content is front-loaded in the first clause and the invocation guidance and pricing follow in short sentences. The opening sentence is dense with clauses (pricing source, sorting, dust flags) but every element carries 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?

No output schema exists, so the description must convey the return shape — and it does: per-asset USD values, live DEX pricing source, value-descending sort, and dust/unpriced flags. Combined with the payment model and endpoint, an agent has everything needed to call and interpret results.

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 parameter types and the optional payment header are already documented in the schema. The description contributes only the "solana, evm, or both" combination guidance and does not clarify the edge case of supplying neither, so it stays at the baseline.

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

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

States a specific verb and resource with explicit scope: a single call returning a USD-valued portfolio across Solana and Base, enumerating asset classes covered (SOL, SPL/Token-2022, Base ETH, USDC). This clearly distinguishes it from single-chain siblings like solana_token_balances and base_balance without needing their schemas.

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

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

"Pass solana, evm, or both" tells the agent how to invoke it for either or both chains, which implicitly covers the aggregation use case. It never explicitly says when to prefer this over solana_token_balances + base_balance, or what happens if neither wallet is passed despite zero required parameters.

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