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

Annotations already declare readOnlyHint and idempotentHint, so the safe read-only nature is covered. The description adds meaningful context beyond annotations: the interpretive meaning of the results and the cost ('one API unit on any chain'). No contradiction with annotations exists.

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 with the core function, followed by interpretation, exclusions, and cost. Every sentence contributes essential guidance; the only minor redundancy is repeating 'address and chain' when the schema already lists them, but the API unit detail justifies that 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 selecting and invoking the tool correctly, the description plus schema cover everything needed: purpose, interpretation, exclusions, parameter formats, defaults, and cost. An output schema exists, so return values need not be described. There are no significant 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 description coverage is 100%, so the schema already thoroughly documents address and chain, including formats and chain requirements. The description adds only the note about one API unit, which is cost-related rather than parameter semantics. 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 names a specific verb and resource: analyzing what the token's creator did with their supply, covering retained share, sales vs transfers, and transfer destinations. It explicitly differentiates itself from siblings like get_whales and get_wallet_links by stating it is not for non-creator wallets or the creator's earlier 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?

Gives clear when-to-use and when-not-to-use guidance: it is for the creator's behavior on the current token, not for other wallets or earlier tokens, with named alternatives. It also explains how to interpret the output (neutral holding, warning on full exit, strongest rug signal for fresh-wallet transfers), helping an agent decide when this tool is the right choice.

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

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

Annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds useful behavioral context: matches can occur days apart, EVM chains are rejected before any request is spent, and this is corroboration only. However, the claim that EVM chains are rejected conflicts with the schema's EVM enum and plan note, making that particular behavioral disclosure unreliable.

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 concept, then gives usage and invocation constraints. It is a bit repetitive around the Solana-only and not-proof-of-bundling caveats, but the warnings are important enough that the redundancy is minor.

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 tool is simple with only two parameters and one required, and an output schema exists, so the description does not need to explain return values. It covers purpose, usage, caveats, and cost, but the unresolved contradiction about EVM support between the description and the schema means an agent still cannot confidently invoke it for all advertised chain values.

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

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

Schema coverage is 100%, so the baseline is 3, but the description narrows chain handling to 'solana or omitted' and says EVM chains are rejected, directly contradicting the schema's chain enum and its note about EVM chains requiring an All-Chains plan. This conflicting guidance makes it harder, not easier, for an agent to correctly set the chain 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 states a specific verb and resource: it identifies wallets that pin identical compute-unit prices or Jito tips, i.e. a shared fee-setting fingerprint. It also explicitly distinguishes this from a timing link and positions it as corroboration for get_lookalike_clusters, so an agent can tell what this tool uniquely does.

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 says exactly when to use it: corroborate get_lookalike_clusters and catch operators who re-entered through fresh wallets. It also gives explicit negative guidance: do not call for EVM addresses, do not read a match as proof of coordinated buying, and pass chain solana or omit 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?

Beyond the read-only/idempotent annotations, the description reveals important behavior: it walks funding chains back, tiers sources by KYC status, answers provenance only, and charges 5 API units on EVM chains due to paid indexers. This is valuable operational context not present in annotations or 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?

The description is information-dense but every sentence earns its place: core behavior, use case, exclusions with sibling names, and cost implications. It is well front-loaded and avoids 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 tool with a complete input schema and an output schema present, the description covers the remaining contextual needs: what problem it solves, what it intentionally does not do, when to use alternatives, and cost behavior. Nothing essential is missing.

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

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

Schema coverage is 100%, so the description does not need to re-explain address and chain formats. It does add the cost implication tied to EVM chains, which is useful, but the parameter meaning itself is fully carried by the input 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 opens with a specific verb and resource: 'Multi-hop tracing of where the money behind this token's key wallets actually came from.' It clearly differentiates from siblings by explicitly naming get_wallet_links, get_lookalike_clusters, get_dev_tracker, get_launch_bundles, and get_launch_snipers as what this tool is not.

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 concrete use case: testing whether several 'unrelated' holders share one funding source. It also names exclusions and alternatives explicitly, so an agent knows when not to select this tool and which sibling to pick instead.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: addresses are classified (liquidity pools, burn addresses, lockers, exchange wallets, contracts are filtered out), the return comes in a single response with no pagination, and the API unit cost is one on any chain. This exceeds the baseline for a read-only tool, though it stops short of detailing the exact response format.

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 dense but efficient: first sentence defines the tool and its classification behavior, second sentence explains the output shape and use case, third sentence routes to alternatives, and the final sentence covers arguments and cost. It is slightly long, but every clause earns its place and the most important distinguishing behavior 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 two-parameter read-only tool with a full output schema present and 100% parameter documentation, the description covers everything needed to select and invoke correctly: purpose, exclusions, sibling routing, chain/address matching rules, response shape, and cost. The output schema covers return details, so the description doesn't need to. No 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 schema already documents both parameters thoroughly. The description adds meaningful cross-parameter context: the address parameter is tied to chain selection ('Set chain to match the address'), and it reinforces that pool/pair/wallet/deployer addresses are not accepted. This supplements rather than repeats 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 states a specific verb and resource ('Holder distribution for one token') and distinguishes itself from several siblings by naming what it is not: get_whales, get_wallet_links, get_lookalike_clusters, and get_liquidity. The phrase 'so the top-holder list reflects actual holders' clarifies the core value proposition, making the tool's purpose unmistakable.

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 explicit when-to-use guidance ('Use it to answer how concentrated the supply is and whether a few wallets could collapse the chart') and explicit when-not-to-use guidance with named alternatives ('Not for what large holders are doing right now (get_whales), whether holders are secretly one actor (get_wallet_links or get_lookalike_clusters), or pool depth and locks (get_liquidity)'). This is exactly the kind of routing information an agent needs.

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 mark this read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond those: bundles are counted on peak net exposure rather than raw buy count, wallets that flipped are excluded, and heavy bundling that is still held is a rug predictor. It also discloses API-unit cost. This is rich, non-obvious behavioral disclosure with no contradiction.

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 one focused paragraph that front-loads the core definition, explains why the metric matters, gives explicit use and non-use cases, and closes with arguments and cost. Every sentence earns its place without repetition or 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?

Given the output schema exists, annotations cover safety, and the schema covers both parameters at 100%, the description is complete. It adds the missing contextual layer: when to use it, when not to, what the signal means, and what it costs. No important gap remains for an agent selecting and invoking this tool.

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

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

Schema description coverage is 100%, and both the chain enum/descriptions and the address format guidance are already fully detailed in the input schema. The tool description only names 'address and chain' and adds an API-unit cost note, which is useful but not needed for parameter semantics. 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 and resource: 'bundle detection for one token'. It also explains the methodology (coordinated buys plus delayed sweeps, accounted on peak net exposure) and explicitly distinguishes itself from sibling tools like get_launch_snipers, get_lookalike_clusters, and get_dev_tracker. No ambiguity about what this tool does.

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

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

It gives an explicit use case: any 'was this launch bundled' question. It then states what it is not for, naming concrete alternatives for lone fast buyers, post-launch clusters, and creator selling. It also adds cost context with 'one API unit on any chain', which helps an agent decide when to invoke 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?

The description adds substantial behavioral context beyond the read-only/idempotent hints: partial results when reachedGenesis is false, caching duration differences (10 minutes vs 2 hours), a 30-row cap with totalEarlyBuyers holding the full count, and the explicit handling of migration-crank MEV bots. These details are valuable and 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?

Every sentence carries operational value: scope, window, row limits, exclusion behavior, caching caveats, use case, alternatives, and cost. The description is front-loaded with the core purpose and then layers constraints and guidance in a logical order without repetition or 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?

The tool is fully contextualized: it explains what the result means, how to interpret a partial result, when to use alternatives, what arguments are needed, and the API cost. With an output schema present and rich annotations, this description leaves no important gap for an agent invoking 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 is 3; the schema already thoroughly documents the address and chain parameters, including formats, defaults, and rejection behavior. The description only restates 'Arguments: address and chain' without adding new parameter-level semantics, so it does not justify a higher score.

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 (bots that bought in the first block/seconds of a token launch) and the specific information returned (whether they are connected to the deployer). It further distinguishes itself from siblings by explicitly naming get_launch_bundles and get_wallet_links as the tools for different cases, so an agent can tell this tool apart without inspecting schemas.

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

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

The description states the intended use: 'Use it to tell an organic launch from a pre-arranged one.' It also gives explicit exclusions: 'Not for coordinated multi-wallet launch buying (get_launch_bundles) or the deployer's funding of other wallets (get_wallet_links).' This gives clear when-to-use versus when-not-to-use guidance, including named alternatives.

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 signal readOnly and non-destructive behavior. The description adds valuable edge-case behavior: a token with no pool returns empty liquidity data, which is itself a warning. It also notes the API cost of one unit on any chain. This goes beyond what annotations alone provide, though it stops short of describing exact response structure or rate limits.

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 with the core purpose, followed by usage boundaries and a key edge case. Every sentence earns its place, and there is no redundant restating of the title or schema.

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

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

For a two-parameter, read-only analysis tool with a rich schema and output schema present, the description fully covers purpose, alternatives, common failure mode, and cost. An agent has enough context to select and invoke this 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 is 3. The schema already explains chain enum values, defaults, address formats, and validation rules. The description only restates that the arguments are address and chain and adds a cost hint, which does not materially expand parameter semantics.

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

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

The description opens with a specific verb and resource: "Liquidity pool analysis for one token, including burn and lock verification and pool depth." It clearly distinguishes this tool from likely confusable siblings by naming get_token_price and get_holders and stating what it is not for.

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 explicitly states when to use the tool: to answer whether liquidity is locked, how deep it is, and whether the position could be pulled. It also names alternatives for price/market cap/volume and holder concentration, giving clear exclusions.

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

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

Annotations already declare readOnly/openWorld/idempotent hints, and the description adds meaningful context beyond them: the EVM cost multiplier (5 API units vs 1), the All-Chains plan key requirement for EVM chains, and the guarantee that unsupported values are rejected before any request is spent. This is exactly the cost/auth/validation context the rubric credits.

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?

Approximately 100 words covering definition, differentiation, usage, exclusions, and cost—appropriately sized for the tool's complexity and front-loaded with the core concept. Minor redundancy: get_wallet_links differentiation appears twice ('That behavioral inference is what separates it...' and 'Not for proven transfer or funding links (get_wallet_links)').

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 rich output schema, detailed param schema, and safety annotations in place, the description completes the picture: what the tool infers, when to prefer it, what to corroborate with, what it is not for, and the cost/plan caveats. No critical gap remains for an agent to call it correctly.

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

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

Schema coverage is 100%, with both address and chain fully documented (formats, examples, defaults, rejection cases), so the baseline is 3. The description adds only marginal value—'Arguments: address and chain' and the cost implication of choosing an EVM chain—over what the schema already states.

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

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

The description opens with a specific, vivid definition—clusters of wallets behaving as a single actor via buyssized and timed alike, even without transfer/funding trails—and explicitly separatees itself from get_wallet_links which only reports proven links. The verb+resource (identify behavioral sybil clusters around a token) is unambigous and distinguishes the tool from its 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?

Gives explicit when-to-use conditions ('when supply looks distributed across many small wallets and the insider graph comes back clean'), a corroboration suggestion (get_fee_fingerprint on Solana), and explicit when-not-to-use exclusions naming the alternatives (get_wallet_links for proven links, get_launch_bundles for launch-window coordination). Nothing is left to inference.

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

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

Annotations already mark readOnly, idempotent, openWworld, and non-destructive, so the safety profile is covered. The description adds valuable context beyond annotations: the score direction (higher = more dangerous), what the verdict/signals do and do not include (no wallet list), and a cost/unit hint ('one API unit on any chain'). No contradiction with 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?

Four sentences, each earning its place: core result, directional contrast, explicit routing to siblings, and a brief argument/cost note. The key scope and danger direction are front-loaded. Slightly long but no wasted words; could be trimmed by merging the argument sentence, yet it remains tight.

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 rich input schema, present output schema, and annotations, the description covers what the tool returns (score, label, signals), what it does not return (wallet evidence), when to use it, and cost. The only minor gap is that it does not describe pagination or additional output details, but the output schema and the explicit 'does not list wallets' caveat keep it complete enough for correct invocation.

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

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

Schema description coverage is 100%, and the schema already gives thorough details for address (format, length, example, invalid input warnings) and chain (enum, default, why it is required for EVM). The description merely says 'Arguments: address and chain' and adds an API cost note, which is useful but does not add semantic meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description names a specific verb and resource ('Rug pull probability for one token') and gives the precise output shape: a 0-100 score with direction (HIGHER MEANS MORE DANGEROUS), a verdict label, and the driving signals. It also explicitly differentiates from the get_token_scan safety score, so an agent can tell them apart without opening the schema.

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

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

It states exactly when to call ('ONLY when the user explicitly asks for a rug probability or rug likelihood') and explicitly routes all general safety/buy questions to get_token_scan. It also names alternatives for the wallet evidence use case (get_wallet_links, get_dev_tracker, get_launch_bundles), giving clear when/when-not and alternative 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, idempotentHint, openWorldHint, and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: it is computed live from the current holder set, cached for about five minutes, and the 'verified' tag has a defined win-rate threshold. No contradiction with 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 dense but efficient: definition, freshness, usage, exclusions, and cost all in a compact paragraph. The trailing 'Arguments: address and chain; one API unit on any chain' is slightly redundant with the schema, but every other sentence earns its place.

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

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

For a read-only, 2-parameter tool with full schema coverage and an output schema, the description is complete: it covers purpose, freshness, threshold logic, when to use when not to, and cost. Return-value details are delegated to the output schema, which is appropriate.

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 is 3; the schema already documents address format, chain enum, defaults, and validation rules. The description only names the arguments ('address and chain') and the API cost, adding no meaning beyond the schema.

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

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

The description opens with a precise definition: wallets with a track record of profitable entries that are holding or trading this token, classified from historical win rates. It also specifies the 'verified' threshold (50% win rate), which sharpens the concept beyond the tool name. It distinguishes itself from siblings by explicitly stating what it is not (risk assessment, wallet size).

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

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

It gives an explicit use case: 'Use it for the bullish side of a scan: who informed is in, and when they got in.' It names the sibling for the excluded use case (get_whales for wallet size) and states that informed presence never offsets a rug signal, so an agent won't misuse it for risk decisions.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the near-live cached nature ('cached for about a minute, so figures are near-live but not a tick-by-tick trading feed') and the empty-data behavior for tokens with no liquidity pool ('returns empty market data rather than an error'). This is genuinely useful for an agent deciding whether to call this 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?

The description is compact, information-dense, and logically ordered: what it returns, freshness, edge behavior, usage context, exclusions, and cost. Every sentence earns its place, and the most decision-relevant facts (what data, non-live nature) are front-loaded. No filler or repetition of schema fields.

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 annotations cover read-only/idempotent safety, the schema covers parameters, and the output schema presumably defines the return shape, the description covers all remaining operational context: freshness, empty-result behavior, use cases, exclusions, and cost. An agent has everything needed to invoke it correctly and avoid the risk-specific siblings.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds value by giving context about the market-data aggregation source and by connecting the parameters to usage context ('Arguments: address and chain; one API unit on any chain'), but most parameter semantics are already in the schema. A 4 reflects that the description doesn't materially extend param meaning but does reinforce the cost implication.

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 opens with a precise verb-resource pairing ('Current market data for one token') and enumerates the exact fields returned (price, market cap, liquidity, volume, recent OHLCV candles). It clearly distinguishes this tool from siblings like get_liquidity or get_rug_score by stating what it is not: not a risk signal and not a long price history feed.

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

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

Explicit when-to-use guidance is given: 'Use it for the market context around a risk verdict.' It also provides explicit when-not-to-use guidance: 'Not for risk of any kind — market data carries no forensic signal — and not for long price history beyond the recent candles.' With sibling tools like get_rug_score and get_token_scan, this exclusion is essential and it is clearly stated.

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

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

Annotations already cover readOnly/idempotent/non-destructive safety. The description adds valuable behavioral context beyond that: the safety-score orientation ('risk.score as a SAFETY score where 100 is clean and low numbers are dangerous'), the rating label, and cost semantics ('one API unit on any chain'). This materially changes how the agent should interpret results and plan calls.

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 action, then adds usage guidance, score semantics, exclusions, and cost in a compact sequence. Every sentence carries distinct information and nothing is redundant or 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?

Given the output schema exists, the description covers the non-obvious aspects: when to choose this tool, how to interpret risk.score, what it is not for, and API cost. Combined with the rich parameter schema and annotations, nothing critical is missing for an agent to correctly 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?

Schema description coverage is 100% and the schema already documents chain enum and address formats in detail. The description only restates 'Arguments: address and chain' without adding new parameter meaning, so the baseline 3 applies.

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

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

The description states a specific verb and resource: 'Run a full DeFade scan on one token contract' and enumerates what is included (metadata, holder distribution, creator info, risk verdict). It also distinguishes itself from siblings by naming get_rug_score for the inverse question and listing exclusions like get_token_price and get_usage.

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 explicitly tells the agent to 'Start here for any "is this token safe", "is this a rug pull" or "should I buy this" question,' then gives precise when-not-to-use cases: single modules, price/market-cap queries, and quota checks, each with the alternative tool named.

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 convey read-only, idempotent, and non-destructive behavior. The description adds context that the tool reports on the API key itself, not an address, and explains its diagnostic value for quota failures. This exceeds the annotation baseline without contradicting it.

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 sentences: the first delivers the core function, the second gives usage triggers, the third clarifies the boundary versus siblings. No filler words, with the most important information 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 parameterless, read-only tool with an output schema and comprehensive annotations, the description covers purpose, scope, and usage conditions. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool has zero parameters, so the schema already covers everything. The description confirms this with 'Takes no arguments,' adding no unnecessary detail while reinforcing the schema's emptiness.

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 ('Report') and resource ('calling API key's plan, rate limits and monthly allowance'), immediately distinguishing it from all sibling token-focused tools. The explicit exclusion of token functionality ('Not for anything about a token') further eliminates ambiguity.

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 explicit trigger conditions: 'Use it when a call fails on quota, or when the user asks what their DeFade plan includes.' It also states what it is not for ('Not for anything about a token') and clarifies the contrast with every other tool in the suite.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds extra behavioral context: this is the 'hard-evidence tool' with provable links, and calls cost 'one API unit on any chain.' That goes beyond the annotations without contradicting them.

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 purpose, then gives usage context, sibling differentiators, exclusions, and arguments in a logical order. Every sentence earns its place without 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 two-parameter tool with a rich input schema and an output schema, the description covers why, when, and when not to use it, plus cost. Nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so the parameter meanings are fully documented in the input schema itself. The description only says 'Arguments: address and chain,' adding no semantic detail beyond the schema; baseline 3 is appropriate.

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

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

The description states a specific deliverable — 'the graph of proven on-chain links between wallets around one token' — and explains the investigative intent behind it ('deployer's supply fanned out to look like organic demand'). It also names related siblings, making the tool's niche unmistakable.

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

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

Explicitly tells the agent when to use the tool ('Use it when the holder list looks distributed and you want to know whether it really is'), and names alternatives for different situations: get_lookalike_clusters for unproven behavioral similarity, get_funding_sources for chain entry, and get_dev_tracker for creator wallet activity. It also excludes market data.

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

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

Beyond the readOnly/idempotent annotations, the description discloses a 15-minute cache lag, the empty-state behavior with largestHumanPct, and the summary outputs including dangerous/active whale counts and a risk verdict. This adds substantial behavioral context the annotations do not provide.

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

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

Every sentence earns its place: definition, row contents, cache behavior, empty state, usage guidance, exclusions, and arguments/cost. The description is dense but well-organized and front-loads the core definition before routing and parameters.

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 description covers what the tool returns, how results are scoped, caching constraints, empty-state behavior, when to use it, when not to use it, and parameter notes. Combined with the output schema and annotations, an agent has everything needed 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%, and the schema already documents address format, chain enum, and validation behavior in detail. The description only mentions 'address and chain' and adds the API-unit cost note, which is useful but not a meaningful semantic expansion over 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 states a specific, well-defined resource: wallets holding at least 1% of supply after removing pools, lockers, treasuries, and custodial accounts. It clearly differentiates the tool from siblings like get_holders, get_smart_money, and get_dev_tracker by stating what it is not for.

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

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

Explicitly says to use it after get_holders when the question is about who can dump and whether they are already dumping. It also names the alternatives it is not for, giving the agent clear routing guidance.

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