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

No annotations are provided, so the description carries the full behavioral burden. It does disclose what the detection logic looks for, which is useful substance, but it says nothing about whether a trusted-address list is required for meaningful results, whether the check requires network/data access, whether results are heuristic or authoritative, or the risk of false positives/negatives — all critical for a security-detection tool.

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

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

A single front-loaded sentence with no filler; the detection scope is stated immediately. It is efficient, though the terseness is partly the source of the missing usage and parameter 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?

With no annotations, no output schema, and 0% parameter coverage, the description is the only source of information, and it stops at the detection taxonomy. An agent cannot tell from this definition what inputs to prepare, whether trusted addresses are needed, or what a result signifies.

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

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

Schema description coverage is 0% and the description supplies no parameter meaning at all. The relationship between the required candidate_address and the optional known_trusted_addresses list — arguably the core semantic of the tool, since poisoning detection is comparison-based — is never explained, nor is the accepted address format (chain, base58 vs hex).

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 ('Detects') and a precise resource ('address poisoning attacks'), then enumerates two concrete attack subtypes: zero-value transfer spoofing and prefix/suffix vanity lookalike spoofing. This is far more specific than a generic 'detect fraud' phrasing. It does not explicitly contrast itself with any sibling, but the sibling set (contract_audit, solana_risk, mev_risk, etc.) covers unrelated domains, so differentiation is implicitly clean rather than stated.

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 statement of the workflow in which this belongs (e.g., before sending funds), no prerequisites, and no mention of when the optional known_trusted_addresses list is required versus omitted. The agent is left to infer the trigger condition entirely from the tool name.

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 provided, the description carries the full behavioral burden. It says what it detects but not whether the operation is read-only, whether it requires network/permission access, expected latency, or how results are structured. Only the analytical scope is disclosed.

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

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

A single dense sentence, front-loaded with the resource and vulnerability classes. No filler, though it is a packed list rather than fully structured 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?

For a single analysis tool with no output schema and no annotations, the description specifies scope and coverage but omits what a result looks like, severity reporting, and routing against siblings. Adequate but with clear 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 both parameters are already documented in the schema. The description adds a bit of meaning by naming supported chain families (EVM, Solana, Move) that loosely map to the network parameter, but adds no format or syntax detail beyond the schema. Baseline 3 applies.

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

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

The description names a specific resource (smart contract) and enumerates the exact vulnerability classes it detects (honeypot, hidden transfer tax, proxy upgrade, mint backdoor) across EVM, Solana, and Move. This distinguishes it from sibling risk tools like solana_risk or mev_risk, though it lacks an explicit action verb ('audits').

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 several sibling risk detectors (solana_risk, mev_risk, address_poisoning_detector). No prerequisites, no exclusions, and no mention of when NOT to use it. Usage is only implied by the vulnerability list.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the non-KYC scope and providers, but does not say whether this is read-only, whether it executes or only quotes, what auth or rate limits apply, or what the response contains.

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 with no filler. It efficiently states the action, route type, providers, and asset universe.

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

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

With no annotations, no output schema, and 0% schema description coverage, the description is too thin for an agent to call the tool reliably. It does not explain the quote output, route selection criteria, or parameter formatting expectations.

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

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

Schema description coverage is 0%, so the schema provides only parameter names and types. The description names supported assets but does not map them to from_asset/to_asset, explain amount units, or specify whether assets should be symbols, chain IDs, or contract addresses.

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

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

The description uses a specific verb, 'Compares', and a specific resource, 'non-KYC cross-chain settlement routes', while naming providers and supported assets. It is clear what the tool does, but it does not explicitly differentiate itself from any sibling tool.

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 states the comparison scope but gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. An agent must infer usage entirely from the single sentence.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the specific checks (overcharge and recipient spoofing), but it omits whether the tool is read-only, what a failed verification looks like, what the return value is, and any permission or 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?

A single sentence front-loaded with the verb and the exact standards covered. It contains no filler and is appropriately sized for the stated purpose.

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 verification tool with no output schema, the description should explain the return shape or failure behavior. It also leaves both parameters undocumented and gives no when-to-use guidance, making it materially incomplete against the task 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 0% for both parameters. The description's mention of 'overcharge' loosely relates to advertised_max_sats and 'HTTP 402 challenges' loosely relates to www_authenticate_header, but it gives no format, units, or interpretation; with zero schema documentation, it fails to compensate.

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 ('Verifies') and resource ('inbound HTTP 402 payment challenges') plus named standards (L402 BOLT11, x402 Solana, MPP Base). It is clearly distinct from siblings like contract_audit or solana_risk, but it does not explicitly differentiate itself from any alternative tool.

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 guidance, no alternatives, and no prerequisites are given. It does not say under what circumstances to call this tool versus handling a 402 challenge manually, so the agent must infer usage entirely.

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 supplied, so the description carries the full behavioral burden. It does disclose the output conceptually ('optimal slippage in basis points') and implies a read/evaluation operation with no mutation, which is meaningful beyond structured data. It omits permissions, latency, determinism, and any side-effect profile, leaving notable gaps.

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

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

A single dense sentence with the evaluative purpose and the output value front-loaded, and no wasted clauses. It is efficiently sized for a one-line tool 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?

With no output schema and no annotations, the description should explain what the evaluation actually returns besides a slippage figure (e.g., a risk score or sandwich warning), and it should document the required token/dex inputs. As written, an agent could call it but would not know the full response shape or how to interpret a risk 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 description coverage is 0% across all four parameters, so the description must compensate. It hints at slippage_bps via 'slippage in basis points' but gives no meaning for dex, token_in, or token_out, which are the three required inputs. Coverage of parameter semantics is well short of what a 0%-coverage schema demands.

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-and-resource pair: a pre-swap MEV sandwich and frontrunning evaluator. It clearly scopes the tool's domain (MEV risk ahead of a swap), which an agent can distinguish from audit-oriented siblings like contract_audit or solana_risk. It stops short of explicitly contrasting itself with any named sibling, so a 4 rather than 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?

'Pre-swap' signals the timing context (call before executing a swap), which is useful implied guidance. However, there is no explicit statement of when-not to use it, what alternatives exist, or prerequisites for interpreting the result. Usage is inferable but not spelled out.

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully enumerates the four risk dimensions inspected, which is real behavioral content, but says nothing about whether the call is read-only, whether it touches external RPC/indexer services, rate limits, or what shape the findings take.

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, front-loaded with the verb and target, listing the checked dimensions without filler. Nothing could be removed without losing 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?

There is no output schema, so the description should set expectations about what comes back (a risk score, per-check flags, a verdict). It names the checks but not the resulting output, leaving the agent to guess the return shape for a tool whose entire value is the report.

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

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

Schema description coverage is 100% with a single documented parameter ('Solana mint or wallet pubkey'), so the baseline is 3. The description only loosely narrows the input scope to SPL tokens and adds no format, encoding, or validation detail beyond the schema.

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

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

States a concrete verb ('Audits') and a precise resource (Solana SPL token) and enumerates the exact checks performed (mint authority, freeze authority, holder concentration, LP lock). That is much more specific than a tautology. It does not, however, explicitly differentiate itself from the closest sibling (solana_whale_radar or contract_audit).

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

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

The description never says when to reach for this tool versus siblings like solana_whale_radar or contract_audit, nor does it name any prerequisite (e.g., that the input must be an SPL mint rather than an arbitrary account). Usage is only inferable from the tool name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It never states that this is a read-only lookup, what data source it draws on, how fresh the whale data is, or what happens when no whale activity is found — all significant gaps for an analytics tool with zero annotation coverage.

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

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

It is a single short sentence with no filler, which is structurally fine. But the brevity reflects under-specification rather than disciplined conciseness — nothing is front-loaded beyond a vague capability claim.

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 one required parameter, no output schema, and no annotations, the description needs to carry the full load and does not: it omits the input's meaning, the return shape, and any safety or freshness context. An agent could not call this correctly with confidence.

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

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

Schema description coverage is 0% and the sole parameter, token_address, is never mentioned in the description, so nothing explains its expected format (mint address vs. symbol) or scope. The description does not compensate for the undocumented parameter at all.

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 verb ('Tracks') and a resource ('Solana whale wallets and insider accumulation clusters'), so the general domain is clear. However, 'high-conviction' is vague marketing language and it never says what is actually returned or computed, nor does it differentiate itself from siblings like solana_risk or contract_audit that also concern Solana tokens.

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

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

There is no guidance on when to reach for this tool versus solana_risk or the other siblings, and no mention of prerequisites or the fact that a token address is mandatory. The agent must infer everything about invocation context.

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 says what it computes but not whether it is read-only, whether utxos must be spendable/sorted, what fee assumptions it makes, or what the returned plan looks like. For a computation tool with zero annotation coverage this is a meaningful gap.

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 tightly packed sentence with the verb front-loaded and no filler. Efficient, though it packs three distinct outputs into one clause rather than structuring them.

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

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

No output schema and no annotations, so the description must carry both input and output context. It sketches the computed outputs conceptually, which is useful, but leaves the required utxos input contract and the shape of the returned plan entirely 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 description coverage is 0% for both parameters. The description mentions 'mempool fee windows' which loosely hints at current_mempool_sat_vb, but never explains what the required utxos array must contain (raw txids? amounts? scripts?) or how current_mempool_sat_vb changes the result. The description does not compensate for the coverage gap.

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 (Computes) and concrete outputs (SegWit/Taproot vByte weights, dust thresholds, mempool fee windows) scoped to UTXO batching. An agent can distinguish it from the risk/audit siblings. It does not explicitly name a sibling alternative, keeping it short of 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?

No when-to-use guidance, no prerequisites, and no mention of when this is preferable to manual estimation or other siblings. The purpose is inferable but the trigger conditions are left entirely to the agent.

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