DeFade — Multi-Chain Memecoin Analyzer

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

Annotations already cover read-only and idempotency, but the description adds real interpretive and cost context: how to read statusColor signals (gray = standard launch, red = strongest rug signal), the creatorInferred caveat about launchpad authorities, and the cost ('one API unit on any chain'). That is behavior an agent cannot get from structured fields.

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

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

Front-loaded with the resource, then a dense interpretation guide, then exclusions, then arguments — a sensible order. It is long, and the statusColor taxonomy is the wordiest section, but nearly every sentence carries decision-relevant information.

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

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

An output schema exists, so return values need not be spelled out, and the description still goes further by explaining how to interpret the verdict fields (statusColor, creatorSource, creatorInferred). Nothing needed to call it correctly or to read the result 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 baseline is 3, but the description adds the causal rule that the deployer is read from contract creation on a given chain, which is why a 0x address needs its chain. It stops short of enumerating the chain enum values the schema already lists, so it is additive rather than exhaustive.

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?

Opens with a specific verb-and-resource statement: what the token's creator did with their supply (still held, sold vs transferred, destinations of transfers). It is clearly distinguishable from siblings by naming get_whales, get_wallet_links and get_token_scan's creator block as serving other scopes.

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 states the exclusion ('Not for wallets other than the creator') and routes the agent to the right alternatives for those cases. It also pins the identity rule (mint creator on Solana, contract deployer on EVM) so the agent knows exactly which address this tool accepts.

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/open-world, but the description adds substantive behavior beyond them: cost ('one API unit on any chain, because it reads what the bundle scan already computed'), the semantics of the 'pending' flag ('nothing has looked rather than nothing was found'), and an explicit epistemic limit ('two wallets can match days apart'). That is real interpretive context, not restated 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?

Front-loaded with the definition, then the family/anti-confusion clause, then usage, then argument cost — a sensible order with no filler. It is a dense, dash-heavy single block that takes effort to parse, which costs it a point on readability.

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 lookup with a full schema and an output schema, everything an agent needs is present: what it computes, how it differs from adjacent tools, how much it costs, how to read a match, and how to interpret the pending state. Return-value shape is rightly left to the output schema.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds a small amount on top by framing the two arguments and explaining that cost is flat across chains because results are derived from a prior scan. It does not add syntax or format detail beyond the schema, so it stops short of 5.

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

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

Names a specific resource and mechanism: wallets whose transactions pin an identical fee setting, with the concrete signals per chain (compute-unit price / Jito tip on Solana, priority fee / legacy gas price on EVM). It also explicitly places itself in the family and names the sibling it is not (not a timing link like the bundle tools), so an agent can discriminate without opening 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?

Gives explicit when-to-use ('corroborate get_lookalike_clusters', catch operators who re-entered through fresh wallets) and when-not ('never proves bundling', 'read a match as corroboration, never as proof of coordinated buying'). It even names the three sibling tools covering the other evidence types (get_wallet_links, get_funding_sources, get_lookalike_clusters), which is exactly the 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 cover safety (readOnly, idempotent, non-destructive), and the description adds what they cannot: a 30-minute cache with computedAt/fromCache, a 5-vs-1 API-unit cost on EVM because the trace hits paid indexers, and the crucial caveat that untraced supply is not evidence either way. That last point materially changes how an agent should interpret results.

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

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

Front-loaded with the core operation and tightly written — nearly every sentence carries distinct guidance (scope, output reading order, cache, cost). It is a dense single paragraph, though, and the combined exclusions and cost note could be split for faster scanning.

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 structure needn't be explained, yet the description still tells the agent to read coveragePct before origins and how to interpret dexPct/bridgedPct — the interpretive layer schemas don't provide. Nothing needed to call this 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?

Schema coverage is 100%, so both parameters are already documented, and the description largely restates the address/chain pairing rule. It does add one decision-relevant fact not in the schema: the chain argument determines whether the call costs 5 API units or 1. Slight redundancy elsewhere keeps this below a 5.

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 — multi-hop tracing of the money behind a token's key wallets, tiered by KYC'd-exchange status — and explicitly contrasts itself with the three siblings that do adjacent graph work (get_wallet_links, get_lookalike_clusters, get_fee_fingerprint). An agent can tell exactly which question this tool answers without opening any schema.

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

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

Gives an explicit use case ("test whether several 'unrelated' holders share one funding source") plus explicit exclusions routed to named alternatives: creator activity → get_dev_tracker, launch-window buying → get_launch_bundles/get_launch_snipers. It even names the pre-flight check (get_usage) before batching across tokens.

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/idempotent/non-destructive/openWorld, so the bar is lower; the description still adds real value by disclosing the classification-and-filtering behavior, that results come back in a single non-paginated response, and the cost ('one API unit on any chain'). It stops short of describing ordering or edge cases (e.g. what a token with very few holders returns), so not a full 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?

Front-loaded with purpose, then returns, then use case, then exclusions — a sensible order. A bit dense as one long sentence chain, and the trailing 'Arguments: address and chain' is largely redundant with the schema, but nothing is wasted elsewhere.

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, annotations cover the safety profile, and the schema documents both parameters exhaustively. The description adds only what structured fields cannot convey: the classification logic, non-paginated single response, and query cost. Nothing an agent needs to call 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?

Schema coverage is 100% and the chain enum with its EVM-address caveat is fully documented in the schema itself. The description only restates 'Arguments: address and chain', adding nothing beyond naming them plus the unit cost. Baseline 3 is correct when the schema carries the 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?

States a specific verb+resource ('Holder distribution for one token') and immediately qualifies scope: liquidity pools, burn addresses, lockers, exchange wallets and contracts are classified out. An agent can tell exactly what this returns versus get_whales or get_liquidity without opening a schema.

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

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

Gives a positive use case ('answer how concentrated the supply is and whether a few wallets could collapse the chart') and then explicitly excludes three sibling tools by name with the condition that selects each (get_whales, get_wallet_links/get_lookalike_clusters, get_liquidity). Routing is fully determined.

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, idempotent, non-destructive), so the description spends its space on what annotations cannot say: the detection methodology, the interpretive warning that held bundling is a strong rug predictor, and the cost (one API unit on any chain). It does not mention latency or empty-result behavior, which keeps it just 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?

Front-loaded with the core definition, then usage, then exclusions, then arguments — a sensible order. It is a single dense paragraph with some redundancy in the caveat clauses, but no sentence is truly wasted.

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

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

With an output schema present, the description need not explain return values, and it does not try. Instead it covers the interpretive frame (why peak exposure accounting matters), the sibling boundaries, and the unit cost — everything an agent needs to select and call it confidently.

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 explains the chain/address matching rules, formats, and rejection behavior in depth. The description's "Arguments: address and chain" plus the cost note add almost nothing beyond what the schema states, so this lands at the baseline 3.

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 (bundle detection for one token) and immediately qualifies the scope: coordinated buys in the launch window plus delayed sweeps. It even clarifies the accounting model (peak net exposure vs raw buy count), which is what makes this tool distinct from a naive buy-count 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?

Explicitly names the question it answers ("was this launch bundled") and then lists three exclusions mapped to named siblings: get_launch_snipers for lone fast buyers, get_lookalike_clusters for post-launch clusters, get_dev_tracker for creator selling. Nothing is left to inference about when to pick this over an alternative.

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

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

Annotations only cover the read-only/idempotent safety profile, and the description adds genuinely non-obvious behavior: the 120-second window, a 30-row cap with totalEarlyBuyers as the true count, exclusion of migration-crank MEV bots (named, not dropped), the reachedGenesis partial-result flag, and differential caching (one hour vs two). This is exactly the operational context an agent needs before trusting the numbers.

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

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

Front-loaded with what the tool returns, then constraints, then a usage-routing sentence, then arguments — a logical order with no filler. It is on the dense side and could be broken up for readability, but every sentence carries information.

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

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

An output schema exists, yet the description still surfaces the two result fields an agent must interpret (totalEarlyBuyers for truncation, reachedGenesis for partial data). Combined with the cost and caching notes, nothing needed to call or trust the call 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% and both parameters are documented in the schema in far greater detail than the description, which only says "Arguments: address and chain." The description does add the useful "one API unit on any chain" cost note, but it contributes little to parameter meaning beyond the schema.

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

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

The first sentence names a specific resource (bots that bought in the first block/seconds of a token's launch) plus the deployer-connection angle, which no sibling covers. It is immediately distinguishable from get_launch_bundles and get_wallet_links, which are named later.

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 ("Use it to tell an organic launch from a pre-arranged one") and explicit when-not-to-use with the two correct alternatives named for each adjacent intent. Nothing is left to inference 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 cover readOnly/idempotent safety, and the description adds real operational context: ~2-minute caching, one API unit cost, and the semantic meaning of 'LP UNLOCKED means it can be pulled at any time'. It also discloses the edge case that a token with no pool returns empty liquidity data, which is a warning signal, not an error.

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

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

It is dense but front-loaded: purpose first, then the lpStatus verdict vocabulary, then usage, then exclusions, then arguments. The lpStatus enumeration is long but earns its place by defining the return codes. A single long paragraph rather than structured lists slightly reduces scannability.

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 present, the description need not explain return shape, yet it still defines every lpStatus verdict and names the evidence fields (lpBurnPct, lpLockPct, poolLocks) that support them. Combined with caching, cost and the no-pool edge case, an agent has everything needed to call and interpret 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?

Schema coverage is 100%, so baseline is 3; the description still adds the cross-chain reasoning that a 0x address needs its chain and that a Base pool is not found under ethereum, which is a concrete failure mode worth restating. It does not add more than that, and the parameter names themselves are only enumerated briefly ('Arguments: address and chain').

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 opening sentence states a specific verb and resource ('Liquidity pool analysis for one token') plus the exact scope: deepest pool, depth in USD, LP burn/lock status. This is clearly distinguishable from get_token_price, get_token_scan and get_holders, which are named in the exclusions.

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 stated positively ('Use it to answer whether liquidity is locked, how deep it is, and whether the position could be pulled') and negatively with named alternatives ('Not for price or volume (get_token_price), market cap (get_token_scan) or holder concentration (get_holders)'). The routing decision is fully determined.

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, idempotent, openWorld and non-destructive, so the safety profile is covered. The description's real addition is the cost asymmetry — 5 API units on EVM versus 1, because tracing hits paid indexers — which is genuine behavioural context an agent budgeting calls needs. It stops short of describing result shape or what an empty cluster set means, though an output schema 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?

Front-loaded with the definition, then differentiation, then when-to-use, then exclusions, then arguments — a deliberate and useful order. Despite its density, every clause carries information the agent would otherwise have to guess.

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 inference tool with rich annotations, a 100%-covered two-parameter schema and an output schema, this description covers the remaining gaps: what makes this inference distinct, when it is worth the extra cost, and which sibling to use otherwise.

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 thorough chain and address semantics (0x vs base58, chain-matching requirement) are already fully documented in the schema. The description only restates the two argument names and adds a cost note, which is a baseline-3 contribution rather than added 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 resource and mechanism: clusters of wallets acting as one actor, inferred behaviourally even without transfer or funding links. It explicitly contrasts that inference with get_wallet_links' proven links, so an agent can separate the two without opening either schema.

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

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

Gives a concrete triggering condition ('supply looks distributed across many small wallets and the insider graph comes back clean'), a recommended corroborating call (get_fee_fingerprint), and an explicit exclusion list naming three siblings with the condition each covers instead. 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?

Goes well beyond the readOnly/idempotent annotations: it discloses that `complete: false` yields a partial score and that the correct behavior is to disclose partiality and re-call, and it states the cost differential (1 API unit on Solana vs 5 on EVM, with a pointer to get_usage before bulk EVM scoring). These are exactly the operational facts an agent needs and none are in the schema or 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?

Purpose and score direction are front-loaded, and almost every clause carries routing, cost, or partial-result information. A few sentences pack multiple ideas (the get_usage cost warning, the evidence-tool list), and some phrasing is clunky, which keeps it just short of a 5.

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

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

Output schema exists, yet the description still frames what comes back (score, verdict, driving signals) and, critically, handles the incomplete-result case the schema cannot express. Combined with cost, chain scope, and sibling handoffs, nothing an agent needs to invoke this 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?

Schema description coverage is 100%, so the schema already carries address format, chain enum values, and the 0x-requires-chain rule. The description's "Arguments: address and chain" plus the per-chain cost note adds pricing context but no new per-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?

States a specific verb and resource (rug pull probability for one token) and immediately pins the semantics: a 0-100 score where higher means more dangerous, plus a verdict label and driver signals. It explicitly distinguishes itself from get_token_scan by noting the inverse direction of that tool's safety score, so an agent can't confuse the two.

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 sequencing (call after get_token_scan), the question classes that select it ("is this safe", "is this a rug", "should I buy"), the chain scope (every chain, and the EVM case where get_token_scan carries no score). It also names where not to use it — for the underlying evidence, deferring to get_wallet_links, get_dev_tracker, or get_launch_bundles.

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?

Goes well beyond the readOnly/idempotent annotations: discloses that results are computed live from the current holder set, cached for about five minutes, and cost one API unit on any chain. It also pre-empts the most likely misreading by stating that informed wallets present never offsets a rug signal — behavioral context the annotations cannot carry.

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

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

Purpose and the bullish-scan use case are front-loaded, then exclusions, then arguments and cost — a sensible order with no filler sentences. Slightly dense with em-dash parentheticals, and the "Arguments: address and chain" clause is redundant with the 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?

An output schema exists, so return values need not be explained; what remains — what the tag means, how fresh the data is, what it costs, and how not to interpret it — is all covered. For a two-parameter read tool, an agent has everything needed to call it and interpret 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 description coverage is 100%, so both parameters (address, chain) are already fully documented including formats, enum values and EVM/Solana mismatch rejection. The description only adds "Arguments: address and chain; one API unit on any chain," which is a cost note rather than new 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?

States a specific verb+resource (wallets holding or trading this token) and defines the classification rule precisely — historical trade win rate, with a "verified" tag requiring 50%+. It explicitly names the sibling it is not (get_whales) for wallet size, so an agent can distinguish it without opening a schema.

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

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

Gives an explicit positive case ("the bullish side of a scan: who informed is in, and when they got in") plus two explicit exclusions with rationale — not for risk assessment, and a clean result is not a buy signal. It also routes the size question to get_whales by name.

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

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

Beyond readOnly/idempotent annotations, the description discloses caching (~1 minute), omission of trade-less intervals rather than zero-filling, the absence of start/end arguments, the empty-result shape for tokens with no liquidity pool, and a one-API-unit cost. These are non-obvious behavioral traits that materially affect interpretation of the returned candles.

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 return contents and caveats are front-loaded, and most sentences carry real information. It is somewhat long and the final argument recap plus timeframe-window repetition duplicates the schema, which keeps it short of a 5.

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

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

Given an existing output schema, the description need not explain return values, yet it still covers the key edge case (no pool → empty candles), interval gaps, window sizing, cost and sibling alternatives. Nothing an agent needs to call 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?

Schema description coverage is 100%, and the schema already documents the chain defaults, address formats and timeframe windows in detail. The description restates the same window mapping and the 0x-needs-chain rule, adding mainly the one-API-unit cost note rather than new per-parameter meaning, so the 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 precise verb and resource — OHLCV price history plus latest price, window high/low and percent change — and explicitly excludes siblings, naming get_liquidity and get_token_scan's token block. An agent can distinguish it from every other price/market tool without opening a schema.

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

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

It gives explicit when-to-use guidance: 1D for peak/drawdown/history questions, the default for market context around a risk verdict. It also states when-not to use it: not for risk, not for pool depth or lock status (get_liquidity), not for market cap (get_token_scan), which is exactly the 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 declare read-only, idempotent, open-world, but the description adds substantial context: per-chain return composition, the fact that the safety score weighs only holders/creator/authorities, the inverted-scoring distinction vs get_rug_score, and the 'one API unit' cost with the All-Chains plan requirement for EVM.

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

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

It is front-loaded and dense with useful routing, but it is long and references get_rug_score three times with overlapping explanation, which is somewhat redundant. Still, nearly every sentence carries actionable meaning.

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-param, read-only scan tool with an output schema present, the description covers scope, per-chain return differences, scoring semantics, and follow-up tools. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already fully documents address and chain with examples and enum guidance. The description only restates 'Arguments: address and chain; one API unit on any chain,' adding little 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 opens with a specific verb+resource ('Run a full DeFade scan on one token contract') and then divides behavior by chain (Solana vs EVM), making clear exactly what the tool does and how it differs from siblings like get_holders and get_rug_score.

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 start here ('is this token safe', 'is this a rug pull'), names the follow-up/alternative tools (get_rug_score for the verdict, get_token_price for price, get_usage for quota), and lists exclusions ('not for a single module in isolation'). Routing is unambiguous.

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, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds useful scope context: it operates on the calling key, takes no arguments, and is orthogonal to the token-address tools. It stops short of stating anything about the returned allowance window beyond 'monthly', but that is minor given 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?

Three tight sentences, front-loaded with the purpose and followed by usage triggers and an exclusion. No filler.

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

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

An output schema exists, so return values need not be described. Purpose, trigger conditions, scope boundary, and argument count are all covered — nothing an agent needs to call this 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?

Zero parameters, so the baseline is 4. The description reinforces this with 'Takes no arguments', matching the empty schema with additionalProperties=false.

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 ('Report the calling API key's plan, rate limits and remaining monthly allowance') and explicitly scopes it to the key rather than a token, which cleanly separates it from every sibling tool that takes an address.

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 two concrete trigger conditions ('when a call fails on quota', 'when the user asks what their DeFade plan includes') plus an explicit exclusion ('Not for anything about a token'). The agent can route without 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 declare the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely non-obvious behavior: scope is the top 25 real holders with pools/lockers/exchanges excluded, results capped at 50 rows with connectionsTotal as the true count, and an empty graph means 'no link found' rather than independence. It also discloses cost (one API unit on any chain). This is beyond what any structured field conveys.

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

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

Front-loaded with the core concept and the routing comparison, which is the right order. It is dense — the sibling enumeration runs long — but nearly every clause carries decision-relevant information; only the four-way sibling sweep is slightly heavier than needed.

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 needn't be explained, and the description still covers the interpretation trap (empty graph ≠ independent) and the connections/connectionsTotal relationship. For a graph tool with two params, nothing an agent needs to call or interpret it 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% and the chain enum plus address format rules are already fully documented in the schema, including the 0x-needs-chain rule. The description's 'Arguments: address and chain' restates rather than adds. Baseline 3 is appropriate when the schema does all the work.

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

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

States a specific verb+resource (the graph of proven on-chain links between wallets around one token) and immediately names the mechanism — funding, transfers, coordinated timing. It explicitly distinguishes itself from three named siblings, so an agent can route without opening any schema.

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

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

Gives an explicit trigger ('when the holder list looks distributed and you want to know whether it really is'), names the alternative for each adjacent case (get_lookalike_clusters for behavioral similarity, get_funding_sources for first money on chain, get_fee_fingerprint for bot fee settings), and states exclusions (not get_dev_tracker, not 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds context they cannot carry: single response with no pagination, a 15-minute cache that can make activity figures lag, an explainable empty state returning largestHumanPct, and a cost of one API unit on any chain. That is exactly the operational detail an agent needs before deciding to re-query or interpret staleness.

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

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

Front-loaded with the eligibility definition, then returns, then empty state, then routing, then arguments — a sensible order with no filler sentences. It is on the long side and the final 'Arguments: address and chain' clause is redundant against a fully documented schema, costing a point.

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 needn't be enumerated, yet the description still frames the summary and empty-state fields. Combined with the cache/lag note, cost, and sibling routing, an agent has everything needed to call this correctly and interpret the result.

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

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

Schema coverage is 100% and the schema itself already explains the chain/address coupling, base58 vs 0x formats, and EVM plan requirements. The description only restates 'Arguments: address and chain; one API unit on any chain', adding no semantics the schema lacks, so baseline 3 applies.

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

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

States a specific resource with its defining rule: wallets holding at least 1% of supply after pools, lockers, treasuries and custodial accounts are removed. The return shape (balance, share, attribution label, 24h tx count, buys/sells, summary verdict) is spelled out, so an agent knows exactly what question this answers.

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 an explicit trigger ('Use it after get_holders when the question is about who can dump and whether they are already dumping') and three explicit exclusions naming the correct siblings: get_holders for the full ranked list, get_smart_money for profitable wallets, get_dev_tracker for the creator's wallet. No inference required.

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