DeFade — Multi-Chain Memecoin Analyzer

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond annotations by disclosing the API-unit cost and explaining how to interpret the output states, including which pattern is the strongest rug signal. This is meaningful behavioral context without contradicting 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?

Four sentences, each earning its place: the first defines the output, the second provides interpretive guidance, the third routes to siblings, and the fourth covers arguments and cost. It is front-loaded with the core purpose and contains no filler or repetition.

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

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

The description is complete given the rich schema and annotations: it explains what the tool returns, how to interpret the result, when not to use it, which alternatives exist, and what the API call costs. The presence of an output schema and read-only/idempotent annotations means no critical behavioral or return-format information 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 input schema covers both parameters at 100% and includes rich detail such as address formats, chain enum values, defaults, and rejection behavior. The description only briefly mentions 'address and chain; one API unit on any chain,' adding little beyond the schema, so the baseline score of 3 applies.

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

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

The description states a specific verb and resource: it reports what a token's creator did with their supply, including share still held, sales versus transfers, and transfer destinations. It also distinguishes itself from sibling tools by explicitly stating it is not for arbitrary wallets and that creator launch history is covered by get_token_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?

The description gives explicit when-not-to-use guidance: it is not for wallets other than the creator, and get_whales/get_wallet_links are named as the alternatives for those cases. It also routes adjacent needs (earlier launches) to get_token_scan's creator block, leaving no ambiguity about which tool to choose.

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 readOnly/idempotent annotations: matches can occur days apart, it is corroboration only, and an unsupported chain is rejected before an API unit is spent. However, the claim that EVM chains are rejected conflicts with the input schema's EVM support, so the behavioral disclosure is not fully reliable.

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 and front-loaded with the core concept, then adds family context, limitations, and usage guidance. It earns most of its length, but the Solana-only point is repeated in slightly different forms and the parameter note is tangled with the misleading EVM claim.

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

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

For a two-parameter tool with an output schema and strong annotations, the description is otherwise remarkably complete: it covers purpose, use cases, alternatives, caveats, and cost. The unresolved contradiction between the description's 'Solana only / EVM rejected' stance and the schema's explicit EVM support leaves the agent without a trustworthy complete picture.

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 already documents address and chain in detail, so the baseline is 3. The description's 'chain must be solana or omitted' and 'EVM chain is rejected' notes directly contradict the schema's enum of ethereum/base/robinhood and its guidance for 0x addresses. Instead of adding useful parameter semantics, this mixed guidance is likely to mislead an agent.

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 what the tool computes — wallets sharing an identical fee-setting fingerprint — and explicitly positions it as the shared-CONFIGURATION member of a known tool family. It also distinguishes it from timing-link analysis by stating it never proves bundling. This is specific enough to select correctly 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?

Usage guidance is explicit: use it to corroborate get_lookalike_clusters and to catch operators who re-entered through fresh wallets. It also says when not to use it — not as proof of bundling or coordinated buying — and names sibling alternatives. The exclusion of EVM calls is stated clearly, even if it conflicts with the schema.

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 and idempotentHint, so the safety profile is covered. The description adds useful behavioral context: it walks funding chains back, tiers sources, answers 'provenance only — money in, one dimension', and notes the 5 API unit cost on EVM chains. This goes beyond what annotations express 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 core function is front-loaded in the first clause, and the lengthy sibling-exclusion list is justified given 14 sibling tools. Every sentence contributes distinct information: function, use case, exclusions, and cost, with no filler.

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

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

With a rich input schema, output schema, and read-only annotations, the only remaining contextual gaps are when-to-use and cost, both of which are addressed. The description fully equips an agent to select the tool correctly and anticipate the EVM charge.

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 parameters are already thoroughly documented with address formats, chain enum/default, and rejection conditions. The description only adds 'Arguments: address and chain' and the EVM cost note, which adds marginal value 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 specific verb and resource: 'Multi-hop tracing of where the money behind this token's key wallets actually came from', which clearly identifies the operation. It also names the differentiating behavior (tiering sources by KYC'd exchange) and explicitly distinguishes itself from several sibling tools.

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 ('test whether several "unrelated" holders share one funding source') and states what the tool does not do, naming alternatives: get_wallet_links, get_lookalike_clusters, get_fee_fingerprint, get_dev_tracker, get_launch_bundles, and get_launch_snipers. It also includes a cost caveat for EVM chains, helping agents decide whether to use it.

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

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

Annotations already establish this is a safe, read-only, idempotent operation. The description goes further by disclosing key behaviors: excluded wallet categories, the fact that each wallet's supply share is included, that the full result comes in a single response without pagination, and that it costs one API unit on any chain. This adds real context beyond the annotations and contains 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 compact but information-dense. Each sentence earns its place: one for what the tool returns, one for the no-pagination behavior, one for usage guidance with alternatives, and one for argument/cost summary. Nothing is wasted and the most important information is front-loaded.

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

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

Combined with rich parameter descriptions and annotations, the description fully equips an agent to call the tool correctly: what is classified out, what the response contains, cost, supported chains, and explicit sibling exclusions. There are no major gaps for a read-only list tool with a schema this detailed.

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 input schema already fully documents address format, chain enum, defaults, validation, and cross-chain ambiguity. The description merely names the arguments and adds the cost note; it does not need to compensate for a schema gap. 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 clearly states the tool's function: it produces a holder distribution for one token, with non-real holders (liquidity pools, burn addresses, lockers, exchange wallets, contracts) classified out. It also distinguishes itself from siblings like get_whales, get_wallet_links, and get_liquidity by explicitly saying 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?

The description tells the agent exactly when to use this tool (to assess supply concentration and whether a few wallets could collapse the chart) and when not to, naming alternatives: get_whales, get_wallet_links, get_lookalike_clusters, and get_liquidity. This is explicit, actionable routing guidance.

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

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

Beyond the readOnly/idempotent annotations, the description discloses the actual counting methodology ('accounted on peak net exposure rather than raw buy count, so wallets that bought and flipped are not counted as holders'), the interpretive significance (rug predictor), and the cost ('one API unit on any chain'). This materially changes how an agent should interpret the result and is exactly the kind of context annotations cannot express.

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: definition with methodology, why it matters, when to use versus alternatives, and arguments/cost. The core purpose is front-loaded before the differentiation and parameter summary, with zero 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?

Complete for a 2-parameter tool with an output schema and safety annotations: the description covers methodology, usage boundaries, cost, and named fallbacks, while the schema covers parameter formats and validation. 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?

Schema description coverage is 100%, so the schema already fully documents both parameters, including address formats, chain enum values, rejection behavior, and plan requirements. The description only summarizes them as 'address and chain,' which adds no meaning beyond the schema — hence 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 opens with a specific verb and resource: 'Bundle detection for one token: coordinated buys in the launch window plus delayed sweeps.' It defines the scope precisely (launch window, peak net exposure) and differentiates itself from three named siblings, so an agent can distinguish it 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 when-to-use rule ('Use it for any "was this launch bundled" question'), plus three explicit exclusions with the correct sibling names (get_launch_snipers, get_lookalike_clusters, get_dev_tracker). This is the gold standard for usage guidance — no inference required.

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 discloses the 120-second window, the 30-row cap with totalEarlyBuyers carrying the full count, and that migration-crank MEV bots are excluded but named rather than silently dropped. It also flags the partial-result condition via reachedGenesis=false and its cache-freshness consequence (10 minutes vs 2 hours), giving the agent real operational context for interpreting 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?

Six sentences, each load-bearing: definition, window/limits, exclusion policy, partial-result caveat, use case, and explicit non-use cases. Dense but front-loaded with the core purpose, with behavioral caveats ordered before routing guidance.

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 and annotations covering the safety profile, the description still covers limits, exclusions, partial-result detection, cache freshness, cost, and sibling differentiation. No important operational gap remains for an agent selecting or 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 coverage is 100%, with both address and chain fully documented (formats, examples, chain-matching requirement, plan requirement), so the baseline of 3 applies. The description only restates the two argument names and adds a per-call cost note (one API unit), which is operational context rather than new 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?

The description opens with a concrete statement of what the tool returns — first-block/first-seconds launch buyers and whether they are connected to the deployer — naming the resource and scope precisely. It further distinguishes itself from siblings by naming get_launch_bundles and get_wallet_links as what it is NOT, so an agent can disambiguate 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?

'Use it to tell an organic launch from a pre-arranged one' states the intended decision explicitly, while 'Not for coordinated multi-wallet launch buying (get_launch_bundles) or the deployer's funding of other wallets (get_wallet_links)' lists the named alternatives and the conditions that rule them out. 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 declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavior beyond annotations: a token with no pool returns empty liquidity data, which is itself a warning for a trading token, plus the API cost of one unit. 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 well organized: purpose first, then the exact questions it answers, exclusions with sibling names, edge-case behavior, and a one-line argument summary. Every sentence earns its place with no redundancy.

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

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

Given the rich input schema, full annotations, and an existing output schema, the description covers everything an agent needs to invoke the tool correctly: purpose, use cases, exclusions, no-pool behavior, and cost. There is no meaningful gap left for the agent to guess.

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?

Input schema coverage is 100%, with both address and chain having detailed descriptions including formats, examples, and constraints. The description only restates that the arguments are address and chain, adding the API unit cost but no new parameter-level semantics, so the baseline of 3 is appropriate.

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

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

The description states a specific resource and scope: liquidity pool analysis for a single token, including burn and lock verification and pool depth. It explicitly distinguishes itself from get_token_price and get_holders, so an agent can tell it apart from nearby siblings 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?

It gives explicit when-to-use guidance: answer whether liquidity is locked, how deep the pool is, and whether the position can be pulled. It also names what it is not for and names the alternative tools, providing clear routing.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds value beyond that by explaining the behavioral-inference nature of the result, noting that EVM calls cost 5 API units instead of 1 due to paid indexers, and stating that unsupported values are rejected before any request is spent. No contradictions 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 front-loaded with the core concept, then differentiates from siblings, gives usage and exclusion guidance, and ends with a cost note. Every sentence earns its place; the length is justified by the amount of actionable routing 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?

For a two-parameter tool with a detailed input schema and an output schema present, the description fully covers what the tool does, when to use it, when not to use it, and one critical cost caveat. Nothing an agent needs to correctly select and invoke this tool 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 input schema already documents both parameters thoroughly, including formats, examples, validation rules, and chain requirements. The description only mentions 'address and chain' in passing and adds cost context per chain, but does not materially improve on the schema's already excellent parameter explanations. Baseline 3 is appropriate given 100% schema coverage.

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 defines the tool's function: finding wallet clusters that behaviorally act as a single actor around one token, even without transfer/funding links. It explicitly distinguishes itself from get_wallet_links, which reports only proven links, so an agent can immediately tell what makes this tool unique.

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 conditions for use: when supply looks distributed across many small wallets and the insider graph comes back clean. It also names alternatives for excluded use cases — get_wallet_links, get_funding_sources, get_launch_bundles — and suggests corroboration with get_fee_fingerprint on Solana.

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/non-destructive, and the description adds value beyond them: the danger-score direction is inverted relative to get_token_scan, it names signals but does not list wallets, and it costs 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 dense, front-loaded sentences: purpose, direction, when-to-use, when-not-to-use, exclusions, and cost. Every sentence carries actionable routing information and there is 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?

With a rich input schema, output schema, and safety annotations, the description covers all that remains: when to call, when to avoid, what it does not provide, and cost. An agent has everything needed to select and invoke 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 fully documents address format, chain enum, defaults, and rejection behavior. The description merely repeats 'address and chain' and adds the API unit cost, which is marginal beyond the schema.

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

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

States a specific verb, resource, and output: rug pull probability with a 0-100 danger score, verdict label, and driving signals. It explicitly contrasts with get_token_scan's safety score, so an agent can immediately distinguish this tool from its closest sibling.

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 conditional: call ONLY when the user asks for rug probability/likelihood, and routes every general safety or buy question to get_token_scan instead. It also names alternative tools for wallet-level evidence, leaving no ambiguity about scope.

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 annotations (readOnly, idempotent, non-destructive), the description discloses the live computed and cached behavior ('Computed live from the current holder set and cached for about five minutes'), the classification threshold for 'verified' smart money (50% win rate), and an important interpretive caveat ('a clean result is not a buy signal'). This adds meaningful behavioral context not available from 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 every sentence earns its place: definition, behavioral caveats, usage guidance, and argument summary are all present. It is well-structured and front-loaded with the core purpose before moving to exclusions and cost. No filler or redundancy detected.

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 enumerate return fields. It covers what the tool does, when to use it, when not to, how results are computed, caching behavior, and required arguments. This is complete enough for an agent to invoke the tool correctly and interpret its role.

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 input schema already fully documents the address and chain parameters with format examples and validation rules. The description only restates 'Arguments: address and chain' and adds API cost information, but no additional parameter semantics. Baseline of 3 is appropriate given complete schema coverage.

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

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

The description clearly states that the tool identifies wallets with a track record of profitable entries, holding or trading a given token, based on historical win rates. It explicitly distinguishes itself from get_whales ('not for wallet size') and indirectly from risk-assessment tools ('not for risk assessment'). This is a specific verb-resource pairing with clear sibling differentiation.

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

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

The description explicitly states when to use the tool: 'Use it for the bullish side of a scan: who informed is in, and when they got in.' It also provides direct when-not guidance: 'not for risk assessment' and 'not for wallet size (get_whales),' naming an alternative tool. This gives an agent clear decision criteria for 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond those: caching for about a minute, near-live but not tick-by-tick, empty market data returned for a token with no liquidity pool rather than an error, and the one-API-unit cost per call.

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 edge-case behavior, usage guidance, exclusions, and cost in a tight sequence. Every sentence adds new information (or the cost detail absent from the schema), with no fluff or repetition.

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

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

Given the 2-parameter schema, rich annotations, and an output schema, the description covers all needed call-time context: what data is returned, staleness/caching behavior, empty-result edge case, intended usage, exclusions, and per-call cost. Nothing an agent needs to invoke 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%, with the schema already providing detailed meanings for `address` and `chain`. The description only restates 'Arguments: address and chain' and adds the cost detail, which does not deepen parameter understanding.

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 resource and scope: current market data for one token — price, market cap, liquidity, volume, and recent OHLCV candles. It explicitly carves out what it is not for ('Not for risk of any kind' and 'not for long price history'), which separates it from the sibling risk and analytics tools.

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 positive use case ('Use it for the market context around a risk verdict') and explicit negative use cases ('Not for risk of any kind... not for long price history'). This tells an agent both when to call it and when to look elsewhere, even without naming a specific 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 already establish read-only, open-world, idempotent, non-destructive behavior. The description adds important operational context beyond that: the risk.score semantics (100 = clean, low = dangerous), the one API unit cost, rejection before spending a request, and the All-Chains plan requirement for EVM chains. 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 front-loaded with the purpose and then systematically covers use cases, return semantics, alternatives, exclusions, and cost. Every sentence carries distinct information, and there is no filler or redundant restating of the title.

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 and the annotations cover safety semantics, the description provides everything an agent needs to decide when to invoke this tool and how to interpret its headline result. It covers input scope, cost, score direction, naming of sibling alternatives, and explicit non-use cases.

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 both address and chain, including formats, defaults, and the 'never a pool/wallet' rule. The description adds minimal parameter information beyond the schema, only restating that address and chain are the arguments, which matches the baseline of 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?

The description opens with a specific verb and resource: 'Run a full DeFade scan on one token contract' and then enumerates exactly what that scan covers. It clearly differentiates itself from siblings like get_rug_score, get_token_price, and get_usage by saying what this tool is and what each alternative is 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?

The description explicitly says 'Start here' for safety-related questions and names the inverse tool get_rug_score for the opposite framing. It also lists concrete exclusions: single modules, price/market-cap questions, and quota checks, telling the agent exactly when not to use this tool.

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 it read-only, idempotent, and non-destructive. The description adds useful context beyond annotations: the operation is scoped to the caller's key, takes no arguments, and reports quota/allowance state. It does not enumerate possible response fields, but the presence of an output schema lowers that burden.

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, each earning its place: the first states the core purpose, the second gives practical triggers, the third excludes token-related uses. It is front-loaded with the most important information and contains no filler.

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

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

For a zero-argument, read-only reporting tool with a rich output schema and annotations, the description covers purpose, usage triggers, scope, and exclusions. There are no meaningful gaps that would prevent an agent from selecting and invoking 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?

With zero parameters and 100% schema description coverage, the schema leaves nothing undocumented. The description reinforces 'Takes no arguments,' which is redundant but clear. Baseline for zero-parameter tools is 4, and nothing here reduces that.

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: 'Report the calling API key's plan, rate limits and how much of its monthly allowance is left.' It clearly distinguishes itself from the sibling tools by explicitly stating it reports on the API key itself, not on a token or address. This makes its role unambiguous.

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

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

It gives explicit trigger conditions: 'Use it when a call fails on quota, or when the user asks what their DeFade plan includes.' It also provides a clear when-not: 'Not for anything about a token — every other tool takes an address; this one reports on the key itself.' This is strong routing guidance relative to the sibling list.

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

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

Annotations already carry readOnlyHint, idempotentHint, openWorldHint, and an output schema exists, so the bar is lower. The description adds genuine context: the evidence standard ('call it only for PROVEN links'), the typical deception pattern the graph reveals (deployer supply fanned out to look organic), and the one-API-unit cost. Minor gap: no mention of graph depth limits or what an empty result means, though these are not critical given the output schema.

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

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

Longer than the archetypal two-sentence definition, but every sentence carries routing value: core output first, then trigger, then the four-way sibling disambiguation, then exclusions, then arguments/cost. The word 'proven' appears twice and the prose is dense, but the length is justified by the need to disambiguate four closely related sibling tools.

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 full output schema, 100% parameter schema coverage, and safety annotations, the description completes the operational picture: what the graph contains, when to call it, what it costs, and which siblings to use instead. Explicitly defining the proof criteria or graph size limits would make it fully airtight, but 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's parameter descriptions are already exceptionally rich (address formats, rejection behavior, EVM chain ambiguity, Solana default). The description only confirms the two arguments and adds the cost note, so it lands at the baseline 3 — the schema does the heavy lifting here.

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: builds a graph of proven on-chain links between wallets around one token, and enumerates exactly what those links are (who funded whom, who transferred to whom, coordinated timing). It also positions itself inside the four-tool 'who is really behind this token' family as the hard-evidence member, so an agent can distinguish it from siblings without opening their 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 an explicit trigger condition ('Use it when the holder list looks distributed and you want to know whether it really is'), then names each sibling with the condition that selects it (get_lookalike_clusters for mere behavioral similarity, get_funding_sources for money entry, get_fee_fingerprint for bot fee settings), and closes with clear exclusions (get_dev_tracker, market data). 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 this as readOnly, idempotent, and non-destructive, lowering the burden on the description. The description adds meaningful behavioral context beyond annotations: a 15-minute cache causing lag, an explainable empty state with largestHumanPct, and a one-API-unit cost. It does not mention any pagination or rate limits, but it is otherwise transparent.

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

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

The description is information-dense but well organized: definition, row contents, caching behavior, empty-state behavior, usage guidance, and cost. Every sentence adds value; it is slightly long but justified by the amount of useful context.

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

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

The description covers what the rows contain, what the summary verdict provides, caching lag, empty-state behavior, when to use it, and cost. Since an output schema exists, detailed return-value documentation is unnecessary; this description fully equips an agent to decide when to call it and what to expect.

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 input schema already fully documents address and chain, including formats, examples, and validation rules. The description only repeats 'Arguments: address and chain' and adds cost context, which is fine but adds no new parameter semantics beyond the schema.

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

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

The description defines exactly what the tool does: identifies wallets holding at least 1% of supply after removing pools, lockers, treasuries, and custodial accounts. It also distinguishes itself from siblings by explicitly naming get_holders, get_smart_money, and get_dev_tracker as different tools, so an agent can select it confidently.

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: call it after get_holders when the question is about who can dump and whether they are already dumping. It also states what it is not for, naming the alternative tools for those cases, which is ideal routing guidance.

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