RugShield 402

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

Annotations already declare readOnly, openWorld, non-destructive, so safety is covered. The description adds genuinely useful operational context beyond that: the tool is paid (0.020 USDC) and runs on Base and Solana Mainnet, which affects invocation planning. It stops short of noting latency, rate limits, or payment 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?

Two tight sentences: capability and scope first, cost/chains second. No filler, and the most decision-relevant 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?

Output schema exists, so return values need not be described. Between the description (scope, DEXs, chains, cost) and annotations (read-only, open-world), an agent has enough to call it correctly; only explicit sibling disambiguation is missing.

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

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

There is a single parameter with 100% schema description coverage, so the schema already carries the semantics; baseline 3 applies. The description reinforces supported chains but adds no new 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 specific verb ("Verifies") and enumerates the exact resources checked: LP token locking, vesting schedules, liquidity depth, unwrap risks, plus named DEXs (Aerodrome, Uniswap). However, it does not distinguish itself from the sibling rugshield_audit_liquidity_lock_verify, which appears to cover overlapping ground.

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?

Scope (Aerodrome/Uniswap, Base & Solana) implies when the tool applies, but there is no explicit when-to-use guidance, no exclusions, and no routing to the near-duplicate liquidity-lock sibling. The agent must infer selection from the description alone.

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, openWorldHint, and destructiveHint=false, and an output schema exists, so the description's remaining job is small. It does add genuinely non-schema context — a fixed 0.010 USDC cost on Base and Solana Mainnet — which an agent should know before invoking, but says nothing about latency, failure modes, or coverage limits beyond 'instant'.

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, front-loaded with the capability and followed by the pricing/chains qualifier. 'Instant' and the audience framing are mild marketing filler but occupy minimal 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?

For a single-param read-only check with a full output schema and annotations, the essential facts are covered. The gap is guidance on when this tool belongs in a screening workflow relative to the many sibling audit tools, plus any statement about what a positive honeypot result means.

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 single parameter's description already explains the ERC-20 vs Solana SPL address formats. The description's mention of 'Base & Solana Mainnet' loosely corroborates the supported chains but adds no new semantics for token_address; 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 pair and resource: honeypot verification and transfer fee detection on a token. This is distinguishable from sibling tools like analyze_liquidity or holder_cluster_map, though it never explicitly names those alternatives to sharpen the boundary.

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 only usage signal is the audience phrase 'for autonomous AI trading agents,' which implies a pre-trade safety gate but never says when to call this versus rugshield_pre_swap_scan or rugshield_audit_swap_simulation_proof. No exclusions, prerequisites, or alternative routing 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 readOnly, openWorld, and non-destructive behavior, so the description’s main added value is disclosing the 0.020 USDC cost and the specific audit dimensions. It does not describe turnaround, failure modes, or output format, but the output schema covers returns.

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 zero waste. The audit scope is front-loaded and the cost disclosure is separated cleanly.

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?

The output schema, annotations, and full parameter schema carry much of the burden, while the description adds audit scope and cost. It is nearly complete, though explicit guidance on when to choose this over adjacent token-audit siblings would make it stronger.

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 single parameter is fully documented in the schema. The description adds no additional parameter meaning beyond what the schema already provides, 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?

States a specific verb and resource: audits canonical Base bridge and CCIP/LayerZero endpoints. It also names the exact risk classes checked, distinguishing it from generic token-risk siblings such as check_honeypot or analyze_liquidity.

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 bridge/cross-chain focus gives clear implied usage context, and the cost line helps an agent decide whether to invoke it. However, it does not explicitly say when not to use it or name alternative sibling 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 cover the safety profile (readOnly, non-destructive, open-world), so the description's real contribution is the 0.020 USDC per-call cost on Base and Solana Mainnet and the explicit limit that only the top 50 holders are analyzed. That cost/payment requirement is material context an agent cannot get from annotations or schema. It omits latency, rate limits, or what happens on payment failure, 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 sentences, both load-bearing: the first states capability plus detection targets, the second states cost and supported chains. Zero filler and the capability 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?

An output schema exists, so return-value explanation is unnecessary; the description supplies the two things structured fields don't — the paid-cost model and the top-50 sampling limit that bounds the analysis. It could say more about how payment is transacted and whether results are cached, but for a one-parameter read tool this is close to 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?

There is a single parameter with 100% schema description coverage, so the schema already carries full parameter meaning (ERC-20 on Base vs Solana SPL mint). The description adds the top-50-holder scope but nothing about address validation or format 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 states a specific verb and resource — analyzing funding origins of the top 50 token holders — plus three named detection targets (sybil clusters, dev dump risks, wash-trading rings), which clearly separates it from siblings like rugshield_tgm_holders or rugshield_tgm_who_bought_sold. It does not name a sibling as an alternative, so it stops 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?

No explicit when-to-use or when-not-to-use guidance appears; the agent must infer that this is a pre-trade due-diligence step alongside the other rugshield_audit_* tools. The stated cost and chain scope imply context but don't route the agent between this and the neighboring holder/flow 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, destructiveHint=false, and openWorldHint=true, so safety profile is covered. The description adds genuinely new behavioral context the annotations cannot convey: the price (0.020 USDC), the payment chains (Base and Solana Mainnet), and the exact lock providers inspected.

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 zero waste: the verification scope and providers lead, and the cost/payment detail follows. 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?

For a single-parameter read tool with an output schema present and safety covered by annotations, the description supplies what is needed: scope, providers checked, and cost. Only minor gap is no note on what happens when liquidity is found unlocked, which the output schema presumably handles.

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

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

Only one parameter (token_address) and the schema documents it at 100% coverage, including Base ERC-20 vs Solana SPL Mint formats. The description adds no format or syntax 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?

States a specific verb (verifies) and resource (LP token ownership/liquidity lock) with the exact protocols checked (Uncx, Team.Finance, Aerodrome slipstream), plus the outcome it proves ('liquidity cannot be pulled'). It is clearly distinct from siblings like check_honeypot or analyze_liquidity, though it never explicitly names which sibling this replaces.

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 a pre-trade safety check on locked liquidity, and the cost line signals it is a paid call. There is no explicit when-to-use/when-not guidance or comparison against analyze_liquidity, so selection still requires inference from the sibling 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond that: it is a paid call costing 0.020 USDC, it uses state-override simulation, and it computes exact slippage, gas, and MEV exposure. It stops short of explaining payment mechanics or whether amount_usd defaults to the three named tiers.

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 tightly written sentences that front-load what the tool does and then state the cost. No wasted words, and the most important operational detail (price) is included.

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

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

An output schema exists, so the description need not explain the returned slippage/gas/MEV values. Annotations cover safety and openness. The remaining gap is the lack of sibling routing guidance and the ambiguity around amount_usd tiers versus arbitrary amounts, but the core context an agent needs is present.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds that simulations focus on $1k, $10k, and $50k orders, but it is ambiguous whether amount_usd is optional and defaults to those tiers or accepts arbitrary values as the schema implies.

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: executes state-override simulation of swap orders on Base Mainnet, with concrete outputs (slippage, gas overhead, MEV exposure). It is clearer than most sibling audit tools, but it does not explicitly differentiate itself from alternatives like rugshield_pre_swap_scan.

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 simulation framing: an agent can infer it should call this before executing a swap to estimate slippage and MEV. However, there is no explicit 'when to use this vs pre_swap_scan' guidance, no prerequisites, 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?

Annotations already establish readOnly and non-destructive behavior; the description correctly reinforces this by explaining the mechanism (simulation via state overrides, so no real swap occurs). It also adds cost (0.010 USDC) and supported chains (Base, Solana Mainnet), which are valuable behavioral facts not in the annotations. An output schema exists, so return values need not be described.

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: the core behavior is front-loaded, and the cost/chain constraint is isolated. Dense but not padded; only minor gain from splitting the long first sentence.

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-only scan with an output schema and clear annotations, this covers the essentials: mechanism, what it detects, cost, and supported chains. The main omission is sibling differentiation, which an agent needs in this crowded tool family.

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 token_address parameter is fully documented in the schema as a Base ERC-20 or Solana SPL Mint. The description reinforces the chain scope but adds no format or validation detail beyond the schema, 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?

States specific verbs and resources: simulates buy/sell orders via state overrides, detects honeypots, computes transfer taxes in bps, verifies liquidity depth. This is clear and concrete, but it never distinguishes itself from sibling tools like check_honeypot, analyze_liquidity, or rugshield_audit_swap_simulation_proof, which appear to overlap heavily.

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_swap' framing implies the usage context (checking a token before trading), and the cost line implies a paid scan. However, there is no explicit when-to-use/when-not guidance and no mention of when to prefer check_honeypot or analyze_liquidity instead, leaving the agent to infer routing.

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

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

Annotations already cover the safety profile (readOnly, openWorld, non-destructive), so the description's job is to add what they don't say — and it does, disclosing a 0.010 USDC cost on Base and Solana Mainnet, i.e., a paid, cross-chain call. It omits payment mechanics (how the fee is settled, prerequisites if unpaid), which is why it falls 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 dense sentences: purpose and outputs first, cost second. No filler, and the highest-value constraint (price) is placed where it will be seen.

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

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

An output schema exists, so return-value detail is unnecessary, and the single parameter is fully documented in the schema. The remaining gap is substantive, though: the wallet-vs-token-address discrepancy means an agent could pass the wrong kind of address with no way to resolve it from the definition.

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 would be 3, but the description actively conflicts with the schema by describing the input as a 'wallet address' when the sole parameter is a token contract address / SPL Mint. That is not just silence but a misleading characterization of the only parameter, so it scores below 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?

The description names a specific verb ('Profiles') and enumerates concrete outputs (token balances, USD valuation, historical win-rate, drainer/OFAC taint), which is more than a tautology. However, it says the target is a 'wallet address' while the schema requires a 'token_address' (ERC-20 contract / SPL Mint), so the agent cannot be sure what resource is actually being profiled. That internal ambiguity keeps it at minimum-viable rather than clearly differentiated from the audit 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?

No guidance on when to choose this over siblings such as rugshield_pre_swap_scan, check_honeypot, or analyze_liquidity, nor any when-not conditions. The only contextual statement is the price, which tells the agent nothing about 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 establish read-only, non-destructive, and open-world behavior, so the description mainly needs to add operational context. It does so by disclosing the 0.020 USDC cost and the supported networks (Base and Solana Mainnet), plus the report's coverage areas. It still omits latency, payment flow, and freshness details.

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 tightly written sentences with no filler. The report scope is front-loaded and the cost/network constraint follows immediately.

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

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

With an output schema available, the description need not explain return values, and annotations cover the safety profile. It supplies the key missing context: what the report aggregates, where it can run, and what it costs. Minor gaps remain around report generation time and whether the report is point-in-time.

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 single parameter is fully documented as an ERC-20 address on Base or a Solana SPL Mint. The description only restates the two supported networks and adds no extra syntax, validation, or format guidance 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 uses a specific verb and resource ('Generates an end-to-end cryptographic audit report') and enumerates the concrete checks the report covers. That scope implicitly separates it from sibling component tools like check_honeypot and analyze_liquidity, 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?

The phrase 'end-to-end' and the listed coverage imply this is the comprehensive option versus individual sibling audits, but the description gives no explicit when-to-use or when-not-to-use guidance. The cost and network note is useful context, 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?

Annotations already cover safety (readOnly, non-destructive, open-world), so the description adds real value by disclosing the paid cost (0.010 USDC), the supported chains, the real-time nature, and the pre-trade honeypot verification. What it does not disclose is how payment is settled or whether a wallet/auth is required before the call succeeds.

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: capability first, commercial/latency constraint second. Zero filler and nothing important buried at the end.

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 an output schema, this is nearly complete: chains, cohort, freshness, safety check, and price are all stated. The remaining gap is operational context around the paid endpoint (how the 0.010 USDC is charged, whether repeated calls are billed, any latency or rate limits), which matters when an agent decides whether to invoke it.

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

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

With a single parameter at 100% schema coverage, the schema already explains the accepted formats (Base 0x contract or Solana SPL mint). The description adds only the chain framing ('on Solana and Base'), which the schema effectively already conveys, so it neither compensates for nor extends 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 ('Returns real-time DEX trades') with clear scope: only trades by labeled smart-money/whale wallets, only on Solana and Base. It implicitly differentiates from siblings like rugshield_smart_money_netflow (aggregate flows) and rugshield_tgm_who_bought_sold (holder-level trades), but never names them, so the distinction is inferential rather than explicit.

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: this is the tool for watching what labeled smart wallets are actively buying/selling in a token. There is no explicit when-to-use or when-not-to-use guidance, and no routing to the closely related siblings (netflow, who_bought_sold, pre_swap_scan) that an agent would need to choose 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?

Annotations already declare read-only, non-destructive, open-world behavior, so the description's main added value is the explicit 0.010 USDC cost on Base and Solana Mainnet — real, non-obvious behavior an agent must budget for. It does not, however, disclose the time window over which netflow is aggregated, which is a meaningful behavioral 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?

Two short sentences, purpose first and cost second, with no filler. Every clause carries information an agent needs.

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 a 1-parameter schema, full coverage, an output schema present, and the cost disclosed, the definition is nearly complete for a read-only analytics tool. The one omission is the aggregation window for netflow, which an agent would need to interpret results correctly.

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

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

Schema coverage is 100% and the single token_address parameter is fully described there. The description restates the accepted chain formats but adds no syntax or constraint details 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?

Names a specific verb and resource — whale/institutional wallet net inflow and outflow — plus the two supported chains (Solana SPL, Base ERC-20). It implicitly distinguishes itself from trade-level siblings like rugshield_smart_money_dex_trades by focusing on net flow, but never names an alternative 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?

Usage is only implied by the 'netflow' framing; there is no explicit statement of when to pick this over rugshield_smart_money_dex_trades or rugshield_tgm_who_bought_sold. The cost note hints at a pay-per-call context but gives no 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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by disclosing the paid cost of 0.010 USDC and the supported networks, which is not present in 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 two tightly written sentences with no wasted words. The core outputs and network scope are front-loaded, and the cost detail is placed after the capability 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?

An output schema exists, annotations cover the safety profile, and the input schema is fully documented, so the description need not explain return values or parameter syntax. It is largely complete for invocation, though it could do more to clarify when this combined holder/lock/sybil view should be chosen over related sibling tools.

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

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

Schema description coverage is 100% and there is only one required parameter, token_address, which the schema fully documents. The description adds no new parameter-level meaning beyond the schema, so the baseline score 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 a specific verb, 'Returns', and specific resources: top-10/top-50 holder distribution, LP lock percentage, and coordinated sybil cluster detection. It also states the supported networks, making the tool's purpose clear, though it does not explicitly distinguish itself from overlapping siblings such as rugshield_audit_holder_cluster_map or rugshield_audit_liquidity_lock_verify.

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 says the tool works 'for any Solana or Base token' and gives a cost, but it provides no explicit when-to-use guidance, no exclusions, and no comparison to alternative sibling tools. An agent must infer usage context from the output list alone.

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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely non-obvious behavioral context: the call is metered at 0.010 USDC and settles on Base & Solana Mainnet, which an agent needs to know before invoking a paid endpoint. It stops short of 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?

Two sentences, both load-bearing: the first carries the analytic scope and segmentation, the second the cost and chain coverage. No filler and the core capability 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?

An output schema exists, so return-shape explanation is not required, and the description plus annotations give an agent everything needed to call it correctly. Minor gap: no note on unsupported addresses or latency for a paid analytics call.

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

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

Only one parameter and schema coverage is 100%, so the schema already explains the 0x/SPL address format. The description reinforces the dual-chain scope (Solana or Base) but adds no format or validation 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?

States a specific verb+resource (who bought/sold a token) with concrete scope: last 24h, segmented into Smart Money, Whales, Fresh Wallets and Dev Clusters. That distinguishes it in substance from sibling tools like rugshield_tgm_holders or rugshield_smart_money_dex_trades, though it never names them 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 intended usage (inspect buy/sell flow composition for a token) is implied by the description, but there is no explicit when-to-use, when-not, or routing to alternatives such as tgm_holders or smart_money_netflow.

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/openWorld/non-destructive, and the description adds a genuinely decision-relevant trait the annotations lack: a fixed 0.010 USDC per-call cost with the supported payment networks. It does not describe latency, rate limits, or failure behavior, but the cost disclosure is the key missing piece an agent needs before calling a paid 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?

Two tight sentences with the capability front-loaded and the cost constraint second; every clause carries information and nothing is 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?

An output schema exists so return values need not be explained, and the cost is disclosed. However, for a paid tool sitting among several overlapping audit/screener siblings, the definition never resolves which one to pick or whether it works on non-trending tokens, leaving a real selection 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 the token_address format for Base ERC-20 and Solana SPL mints is already documented in the schema. The description reinforces the two supported chains but adds no format, validation, or edge-case 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?

States a specific verb (screens) and resource (trending Solana/Base tokens) and enumerates the metric families it bundles: honeypot, tax, liquidity depth. It is distinguishable from single-metric siblings like check_honeypot only by inference from the metric list, not by an explicit contrast.

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 statement of when to use this composite screener versus the overlapping siblings rugshield_pre_swap_scan, check_honeypot, or analyze_liquidity, and no prerequisites or exclusions. The only implied usage cue is that it targets 'trending' tokens, which is not elaborated.

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