47620 Multichain On-chain Data API

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

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

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

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

Two tight sentences with the core payload (what balances are returned) front-loaded and the cost caveat last. Slightly marred by the bracketed '[Solana by default]' prefix, which is cryptic without the sibling context.

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

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

For a one-parameter read tool with no output schema, the description should explain the return shape more than 'native SOL plus every SPL token balance'. It covers the essentials and pricing but leaves chain-variant behavior (the 'by default' claim) and failure modes unexplained.

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

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

There is only one parameter and schema coverage is 100% ('Solana wallet address'), so the schema already documents it fully. The description adds no format, chain-variant, or address-validation detail, making the baseline 3 appropriate.

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

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

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

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

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

No guidance on when to pick this tool over solana_account, snapshot, or token — despite an overlapping sibling set. The only conditional information is a pricing note ('Pay-per-call'), which is cost data, not usage direction.

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

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

With no annotations, the description carries the full burden. It usefully discloses the pay-per-call cost ($0.002 USDC), which an agent needs for budgeting, but says nothing about return shape, pagination, failure modes, or whether stablecoin balances are limited to specific tokens.

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

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

Front-loaded with the payoff (what balances, for what input) followed by routing and pricing. Efficient overall, though the three literal endpoint paths consume space without helping tool selection.

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

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

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

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

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

Schema coverage is 100%, so both parameters are already documented in the schema with format hints (base58 vs 0x). The description adds margin by mapping each chain value to a path, but that is routing detail rather than added parameter meaning, so the baseline 3 holds.

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

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

States a specific resource and scope: native plus stablecoin balances for an address on a chosen chain. It is clear what the tool returns, though it does not explicitly distinguish itself from siblings like 'account' or 'solana_account', leaving some overlap to inference.

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

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

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

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

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

With no annotations, the description carries the full burden. It usefully discloses the pay-per-call model and $0.01 USDC cost, plus the per-chain endpoint paths, which are real behavioral facts. It does not state that this is a read-only operation, nor does it cover rate limits, auth requirements, or behavior for non-contract/EOA addresses.

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

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

Two sentences, front-loaded with the primary purpose and return payload, followed by routing and pricing. Dense but efficient; the inline path strings are slightly cryptic but do not waste space.

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

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

With no output schema and no annotations, the description compensates well by naming the three return concepts (is-contract, bytecode size, ERC-20 metadata) and the pricing model. Missing only edge-case behavior and error handling, which is acceptable for a 2-parameter read tool.

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

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

Schema coverage is 100%, so both parameters and the chain enum are already fully documented, giving a baseline of 3. The description adds the endpoint mapping for base vs polygon, but that is routing detail rather than parameter meaning, and it adds no format hints beyond what the schema's address description already provides.

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

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

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

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

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

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

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

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

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

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

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

Front-loads the core value proposition in the first clause, then adds routing and pricing details. The path strings are somewhat noisy internal routing detail, but nothing is truly wasted and it stays to a few lines.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Three short, front-loaded sentences with no filler; the core purpose and the pricing fact both land early. The per-chain path listing is slightly internal/technical filler for an agent, keeping it from a 5.

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

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

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

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

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

Schema coverage is 100% and the enum plus 'Chain to query' already documents the single parameter, so the baseline is 3. The description maps each enum value to a backing path, which adds minor meaning but not much that helps the agent choose a value.

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

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

States a specific verb+resource ('Network health for a chosen chain'), so the agent knows exactly what it retrieves. It does not differentiate from the overlapping sibling solana_health, which appears to be a chain-specific variant of the same capability.

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

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

There is no when-to-use or when-not-to-use guidance and no named alternative. The phrase 'for a chosen chain' only weakly implies scope, and the description never tells the agent when to prefer this over the sibling solana_health.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the pay-per-call cost ($0.02 USDC), the re-verifiable on-chain fact basis, and the output verdict, but it never explicitly states read-only status, rate limits, or auth beyond payment.

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

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

The description is front-loaded with the primary use case and output, then compactly lists chain endpoints and cost. Every line carries information; the endpoint mapping is dense but purposeful, so it is efficiently structured.

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

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

For a no-annotation, no-output-schema tool, the description covers the essential context: when to use, what it returns, which chains, and the cost. It leaves minor gaps (read-only status, error behavior), but an agent has enough to invoke it correctly.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds a chain-to-endpoint mapping, but doesn't add syntax or constraints beyond the schema's enum and address description, so baseline 3 is appropriate.

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

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

The description states a specific verb ('get') and resource ('risk score') with output detail ('0-100 risk score with reasons and a proceed/review verdict'). It does not explicitly distinguish from siblings like trust_check or should_pay, so it is clear but lacks sibling differentiation.

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

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

It gives a clear usage context ('BEFORE paying an address'), which is when to use it. It offers no when-not guidance or named alternatives among siblings, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden, and it does add real behavioral context: this is a paid call at $0.02 USDC and it condenses multiple on-chain facts into one verdict. However, it never states whether it is read-only, what the verdict contains, or latency/caching behavior.

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

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

Two tight sentences, front-loaded with the purpose before routing and cost details. Nothing is wasted, though the raw endpoint template line is somewhat implementation-oriented for an agent-facing description.

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

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

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

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

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

Schema coverage is 100% with both parameters fully described and chain constrained by an enum, so the schema already does the work. The description adds only the endpoint routing per chain, which is marginal beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific decision verb and resource: a 'Pay-vs-do-not-pay decision for a payee' that aggregates on-chain facts into 'a single verdict.' This is distinctive from the raw-fact siblings (balance, tx, gas) and the narrower risk_check/trust_check tools, though it never names those alternatives directly.

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

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

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

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses pay-per-call cost ($0.01 USDC) and the data returned, but does not state that the operation is read-only, nor describe auth requirements, rate limits, or error behavior.

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

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

The description is front-loaded with the core benefit ('Whole-network picture in ONE call') and uses compact sentences. Endpoint mapping and cost are included efficiently, with little wasted language.

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

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

For a one-parameter query tool with no output schema and no annotations, the description explains what data is returned, the per-call cost, and the endpoint mapping. It is complete enough to select and invoke correctly, though it omits usage alternatives.

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

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

Schema description coverage is 100%, giving a baseline of 3. The description adds value by mapping each enum value to a specific endpoint path, clarifying chain-specific behavior beyond the schema's 'Chain to query' text.

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

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

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

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

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

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

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

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

With no annotations, the description carries the burden of behavioral disclosure. It usefully discloses the monetary cost ($0.002 USDC) and the comprehensive scope of the balance lookup, but it does not state whether the operation is read-only, how errors are surfaced, or any rate-limit constraints.

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

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

The description is a single, front-loaded sentence that conveys the core behavior, scope, and cost with no filler. Every clause earns its place.

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

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

For a simple one-parameter read tool with no output schema, the description sufficiently explains what the call returns (native and SPL balances) and the cost. It does not detail response formatting or failure modes, but the low complexity and full schema coverage keep the gap minor.

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

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

Schema description coverage is 100% and the single parameter is adequately described as 'Solana wallet address'. The tool description adds no further semantic detail beyond the schema, so the baseline of 3 applies.

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

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

The description clearly identifies the resource (a Solana address) and the exact data returned: native SOL balance plus all SPL token balances including USDC. It is distinguishable from sibling tools by content focus, though it does not explicitly name an alternative.

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

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

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

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

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

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

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

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

The description is a single sentence that front-loads the resource, immediately lists the three returned metrics, and ends with the pricing detail. There is no filler and every phrase earns its place.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description is compact and front-loaded: it states the triggering condition first, then lists outputs, then the purpose and cost. Every sentence provides necessary information and there is no filler or repetition.

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

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

For a single-parameter tool with no annotations and no output schema, this description is complete. It explains when to use it, what it returns, why it matters, and even discloses the per-call cost. An agent has enough context to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline applies. The single 'address' parameter is already described as 'Solana address to check before paying' in the schema. The tool description adds context about SOL/USDC and risk, but does not add new parameter-level semantics beyond the schema.

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

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

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

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

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

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

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

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

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

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

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

The description is compact, front-loaded with the core value proposition, and every sentence provides distinct information: what the tool returns, why it is advantageous, and what it costs. There is no filler or redundancy.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description is extremely concise: one clause states the returned data and input scope, and one clause states the cost. There is no redundant or filler content, and the most important information is front-loaded.

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

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

For a simple one-parameter read-style tool with no output schema, the description covers the input, the returned fields, and the cost model. It does not describe response format or failure cases, but the tool's low complexity and the description's directness make it largely complete.

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

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

Schema coverage is 100%, so the schema already documents the single 'mint' parameter as an SPL token mint address. The description adds only 'any' and 'Solana' context, which does not materially improve understanding beyond the schema. A baseline of 3 is appropriate.

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

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

The description names the resource (Solana SPL token mint) and the data returned (price, liquidity, 24h volume, DEX pairs), which clearly distinguishes it from the account, transaction, health, and trending siblings. It lacks an explicit verb like 'get' or 'fetch', but the intent is unambiguous.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description clearly states the tool returns live trending/new Solana DEX pairs ranked by 24h volume. The resource and sorting criterion are specific, and the purpose is distinct from sibling tools like solana_token or solana_account. Even though the verb is implicit, the meaning is unambiguous.

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

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

The description implies this tool is for retrieving current market data (trending/new pairs) and mentions it is a 'fresh feed for agents', suggesting repeated polling. However, it gives no explicit guidance on when to use this tool versus the siblings (e.g., solana_health for network status, solana_token for token details) nor any exclusions. Usage context is implied but not explicit.

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

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

With no annotations, the description carries the full burden. It does disclose a meaningful behavioral trait: pay-per-call with a specific cost ($0.003 USDC), which is valuable for an agent deciding whether to invoke it. It also describes the output categories, but it does not mention potential errors, signature format requirements, or whether the call is read-only.

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

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

The description is a concise single sentence that front-loads the core output information and appends the pay-per-call cost. Every clause adds useful information, and there is no wasted wording.

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

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

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

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

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

Schema coverage is 100%, so the baseline is 3. The schema already documents the single 'signature' parameter. The description adds confirmation that the signature is for a Solana transaction, but it does not add format details, network context, or example values beyond what the schema conveys.

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

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

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

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

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

There is no guidance on when to use this tool versus the siblings solana_health, solana_token, solana_account, or solana_trending. The use case is implied by the resource type, but no explicit context, prerequisites, or exclusions are provided.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the pay-per-call cost (from $0.002 USDC), which is real behavioral context the schema cannot express, but it omits read-only/mutation semantics, authentication requirements, rate limits, and failure behavior.

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

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

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

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

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

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

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

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

Schema coverage is 100%, so both parameters are already documented, giving a baseline of 3. The path listing does reinforce that 'id' is a mint on solana and an address on EVM chains, but adds little beyond the schema's own 'SPL mint or ERC-20 address' description.

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

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

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

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

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

The chain-to-path mapping implies which chains are queryable, but there is no explicit guidance on when to choose this tool over solana_token or token_report, nor any exclusions or prerequisites. Usage is left entirely to inference.

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

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

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

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

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

Front-loaded with the value proposition, followed by the returned fields, routing, and price in dense but ordered fragments. No filler sentences; slightly telegraphic endpoint syntax is the only mild readability cost.

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

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

With no output schema and no annotations, the description compensates by enumerating the returned data fields and the cost model, which is the key information an agent needs before paying. Auth requirements and response format remain inferable but unstated, leaving a small gap.

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

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

Schema coverage is 100% and the enum for chain plus the token format are both documented in the schema, so this is the baseline 3. The description adds only the per-chain endpoint paths, which restates the chain enum rather than deepening parameter meaning.

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

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

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

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

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

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

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

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

With no annotations, the description carries the full burden. It does disclose a genuinely useful behavioral trait absent from structured fields — pay-per-call at $0.02 USDC — which establishes cost/read nature. It says nothing about result limits, ordering guarantees, or what happens on an unsupported chain, leaving real gaps for a paid endpoint.

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

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

Front-loaded with the core purpose in the first clause, then the routing and cost details. The path list is somewhat dense and arguably internal, but every sentence carries information; nothing is redundant padding.

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

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

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

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

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

Schema coverage is 100% and the enum already defines the allowed chains, so baseline is 3. The description adds meaning beyond the schema by mapping each chain value to its concrete endpoint path, clarifying that the parameter selects backend routing, not just a filter.

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

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

States a specific verb and resource ('Trending DEX pairs by 24h volume'), which is far more precise than the bare name. However, it does not distinguish itself from the sibling solana_trending, and in fact references the solana path that likely belongs to that sibling, leaving the boundary ambiguous.

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

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

Usage is implied: pick a chain and call this to get trending pairs. The path mapping hints that this tool spans multiple chains, but there is no explicit when-to-use vs when-to-use-solana_trending guidance and no stated exclusions.

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

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

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

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

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

Compact and front-loaded: the call-to-action constraint ('BEFORE paying') leads, followed by the verdict, scope, and cost. Every clause adds information, with no filler.

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

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

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

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

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

Schema coverage is 100%, so both 'target' (address format) and 'chain' (enum, optional/inferred) are already documented in the schema. The description adds no format or inference detail beyond that baseline, so 3 is appropriate.

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

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

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

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

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

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

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

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

With no annotations, the description carries the full burden, and it does add real behavioral context: pricing ('Pay-per-call from $0.003 USDC') and per-chain endpoint routing. It stops short of stating read-only semantics, failure modes (e.g., unknown tx), or rate/limit behavior, so the profile is partial but not misleading.

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

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

Front-loaded with the core purpose and kept to three compact sentences with no filler. The endpoint paths are somewhat internal-facing detail, but they are packed tightly and do not bloat the definition.

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

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

There is no output schema, so the description is the only source for return content; 'status + transfer summary' gestures at it but does not enumerate the fields an agent would receive. For a simple two-parameter read tool this is adequate but leaves return shape and error behavior underspecified.

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

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

Schema coverage is 100%, so the baseline is 3; the schema already explains that 'id' is a Solana signature or EVM 0x hash and enumerates chains. The description's path mapping (solana -> :signature, base/polygon -> :hash) only restates that distinction rather than adding format or validation detail.

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

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

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

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

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

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

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