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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds substantial behavioral context beyond annotations: it notes the cost per call, that quotes are only quotes (nothing is signed), that results are not cached, takes a few hundred milliseconds, and explains the verdict derivation (worst rung). This enriches the agent's understanding of latency, freshness, and non-transactional nature.

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

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

The description is compact and front-loaded: it starts with the cost, states the core question, lists what is returned, then covers caveats and performance. Every sentence adds value, no filler, and the structure leads with the most 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?

With an output schema present, the description doesn't need to detail return structure. It covers the cost, verdict levels, round-trip detail, survival fraction, quote-only nature, non-caching, and latency. Nothing an agent needs to correctly invoke and interpret the 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 documents the single parameter 'mint' with a clear description ('Solana token mint, base58.'), and schema description coverage is 100%. The tool description does not add any additional meaning or format details beyond what the schema already provides, so the baseline of 3 applies—the schema carries the parameter documentation.

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 explicitly states a specific verb+resource: 'Can this token be sold RIGHT NOW' and what a round trip costs, including Jupiter routes and survival fraction. It lists verdict levels and clearly differentiates from sibling tools like check_token or token_report by focusing on immediate sellability and cost rather than general token info.

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 clearly implies when to use the tool—when assessing whether a token can be sold immediately and what the round-trip cost is. It doesn't explicitly name alternatives or state when not to use it, but the purpose is so singular that an agent can easily select it over siblings without further 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?

While annotations already declare readOnlyHint=true and destructiveHint=false, the description adds substantial behavior beyond that: a per-call cost of $0.001, that the probability is a MEASURED frequency rather than a raw score (with a pointer to get_scorecard), and the notable limitation that it 'does not name holders.' These are meaningful behavioral disclosures not available in the annotations.

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

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

Every phrase earns its place: cost, purpose, output composition, cost-optimization routing, and limitations are each covered in a tightly packed 4-sentence definition. The core question is front-loaded, with operational details layered afterward. Dense but not bloated.

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

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

For a single-parameter tool with an output schema present, the description covers the semantic output (verdict, concentration, collapse speed), pricing, the calibration source (get_scorecard), its relationship to more expensive siblings, and a key limitation (holder anonymity). Nothing critical is missing for an agent to decide when and how to call 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 description coverage is 100% — the single `mint` parameter already documents itself as 'Solana token mint, base58.' The description adds no additional syntax or format details beyond the schema, landing 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?

The description leads with the core purpose — 'Is this Solana token dangerous?' — and then specifies the deliverable: a calibrated rug verdict with a measured probability, concentration facts, and band-collapse speed. It distinguishes itself from siblings by positioning this tool as the cheap gating check that decides whether inspect_token, token_identity, or token_report is worth the cost.

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 usage guidance is provided: 'Cheapest call, run it on every token; it decides whether inspect_token, token_identity or token_report is worth paying for.' This tells the agent when to invoke this tool (as a first pass on every token) and frames the alternatives as downstream follow-ups conditional on this tool's output.

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 readOnlyHint=true and destructiveHint=false, so the baseline burden is lower. The description adds valuable behavioral context: it is a read-only aggregate across all indexed tokens, works universally for any address, and includes a cost signal ('$0.006'). It does not disclose rate limits or latency, but the readOnly annotation covers the critical safety profile.

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 three compact sentences with no filler: it states cost, purpose, key outputs, universality, and sibling-tool distinctions. Every clause earns its place 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?

For a single-parameter read-only tool with an output schema present, the description covers the main operational facts: what the tool aggregates, which metrics are returned, that any address works, and how it differs from nearby siblings. The only minor gap is not stating explicit when-to-use/when-not-to-use rules, but the context signals and sibling definitions make it sufficient.

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 has 100% description coverage for the single address parameter ('Solana wallet, base58'), so the schema already carries the full weight. The description's 'Works for any address' adds only a minor clarification that there is no address restriction, which does not meaningfully extend 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 clearly identifies the resource (a single wallet) and the scope ('across every token we indexed'), then enumerates the specific data points returned: launches, how many ran, roles, and realised record. It also distinguishes itself from sibling tools by defining kol_record and wallet_network, so an agent can tell them apart immediately.

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

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

The phrase 'Works for any address' sets a clear inclusiveness condition, and the distinctions between kol_record and wallet_network tell an agent when this tool is the right choice versus when a per-trade history or network-level view would be more appropriate. It lacks an explicit 'use this instead of X when...' formulation, but the context is strong.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context: it weighs roles rather than counts, and it discloses that mints outside the index are returned as 'not_covered'. It also mentions a cost ($0.025), which is useful. This goes beyond the annotations by explaining the analytical approach and the coverage limitation.

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

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

The description is compact and information-dense. It front-loads the purpose with a direct question, then explains the output and the weighting logic, and ends with the coverage caveat. No fluff; every sentence earns its place. Slightly long but efficient.

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 tool has a single parameter fully described by the schema, an output schema exists (verified by context signals), and annotations cover safety, the description provides the missing analytical context: what the output means (roles, weighting) and edge cases (not_covered). It doesn't specify the exact output format, but the output schema likely covers that. Overall, complete for correct invocation.

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

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

Schema coverage is 100% — the 'mints' parameter is described as 'Solana token mint, base58.' The description reinforces that 2-4 mints are required and explains the purpose, but doesn't add much semantic detail beyond the schema. The example in the schema already shows the format. Baseline 3 is appropriate.

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

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

The description states a specific task — compare tokens for shared wallets — and frames it as a question ('Were these tokens run by the same people?'). It explains the output (wallets appearing in more than one mint, with roles). However, it doesn't explicitly distinguish itself from sibling tools like find_serial_insiders or wallet_network, though the focus on cross-token comparison is implicit.

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 clear input range (2-4 mints) and hints at when to use it: when investigating whether tokens share operators. It notes that shared holders are common and provides weighting guidance (roles over count), which helps an agent decide if the result is meaningful. It does not explicitly name alternatives or conditions when not to use this tool, but the guidance is reasonably clear.

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 and non-destructive (readOnlyHint=true, destructiveHint=false). The description adds pricing, content shape, and the prerequisite that the id must come from `search`. It does not claim any write or side effect, consistent with annotations. It enriches the behavioral profile without 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?

Two dense but efficient sentences. The first front-loads price and purpose, then enumerates the payload. The second ties the id source and disqualifies other clients. Every word adds value, no repetition or fluff.

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 a single required parameter, a read-only annotation, and an existing output schema, the description covers the output contents, the input source, the price, and the sibling distinction. An agent has everything needed to call it correctly; nothing important 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 schema already documents the single `id` parameter completely (100% coverage). The description adds the source of the id ('from search') and the price, but these are situational rather than parameter-meaning. No new parameter behavior is disclosed beyond what the schema already provides.

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 a specific verb ('fetch'), a resource ('one token as one document'), and enumerates the contents (verdict, hit rate, holders, sellability). It also distinguishes itself from the sibling token_report by Positioning itself as the 'ChatGPT entry point' and noting the same endpoint and price.

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 says the id comes from `search` and that other clients should call token_report instead, giving a concrete input source and a clear differentiation from the sibling. However, it doesn't provide a broader decision rule beyond 'I am ChatGPT, use this' — it assumes the agent knows when it is the ChatGPT entry point.

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 the tool as read-only and non-destructive, so the description doesn't need to cover that. It adds valuable behavioral insights: it explains why ranking on insider count alone is misleading (bots dominate) and instructs the agent on how to interpret the data (comparing insider_in vs also_held to distinguish real serial insiders from bots). This goes beyond the annotations.

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

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

The description is compact (about 60 words) and front-loads the core purpose and pricing. The interpretive guidance on reading the output is concise, but the phrase 'close is a real serial insider, far apart is a bot' could be clearer without losing brevity. Suitable for the tool's complexity.

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 the essential aspects: what the tool does, how to interpret the output (insider_in vs also_held), and the context of bot filtering. The use of examples within the schema and the absence of required parameters makes it easy to call. It does not mention the price per call in detail (only per 25), but that is not critical. Overall, an agent can effectively use this tool with the given description.

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 schema description coverage is 100%, so parameters are well-documented in the schema itself. The description does not add extra meaning to 'limit' or 'min_tokens' beyond what's in the schemaoo does not need to explain them further. Baseline 3 is appropriate because the description doesn't enhance parameter understanding but doesn't need to either.

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 purpose: 'find wallets that keep turning up as insiders across the whole index.' It distinguishes itself by focusing on cross-token insider detection, which is not evident from siblings. However, the verb 'find' is generic, and the description could more clearly state that it ranks wallets across multiple tokens.

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

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

The description provides clear context on when to use this tool (to identify serial insiders across the index) and implicitly contrasts with wallet-specific tools like 'check_wallet' or 'wallet_network'. It doesn't explicitly name alternatives or when not to use, but the context makes the usage clear.

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 indicate read-only, but description adds cost information ([$0.005]) and clarifies it's a time-ordered feed with no query, providing additional transparency beyond 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?

Two concise sentences that front-load purpose and include cost, filters, and alternative tool. Well-structured and no fluff.

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 tool's complexity and sibling tools, the description provides enough context: what it returns, when to use it, and when not to. Output schema exists, so no need to explain return values.

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

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

Schema provides full descriptions for each parameter. Description repeats them but adds context that these are filters, not search terms, which enhances 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 clearly states it lists recently analyzed tokens with verdicts for local ranking, and distinguishes from search_tokens. It specifies a verb and resource.

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 when to use this tool (for ranking locally before paying for depth) and when to use search_tokens instead (when you know name or mint).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: results are labelled with exchange names when known, ranking is based on seeded fresh wallets, and null-label high-count rows are called out as significant. It does not add pagination details, but the output schema covers return structure.

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

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

The description is compact and front-loaded: the first sentence delivers the core ranking and labeling function, the second clarifies the level of aggregation, and the third gives an actionable heuristic. Each sentence earns its place, 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?

Given the 100% schema coverage, an output schema, and read-only annotations, the description is largely complete. It explains what is ranked, how labels work, and even suggests what to look for. Minor gaps remain around domain terms like 'fresh wallets' and 'seeded', but they do not block correct invocation.

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

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

Input schema description coverage is 100%, so limit and min_wallets are already fully documented with types, defaults, and ranges. The description provides no additional parameter-specific semantics, though 'seeded' loosely maps to min_wallets. This meets the baseline for schema-covered parameters.

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 (funders) and a clear ranking action ('ranked by how many fresh wallets they seeded across the whole index'), and explicitly distinguishes this cross-index view from a single-token view ('inside one token is a line item; across the index it is a desk'). This makes the tool's purpose unambiguous and separated from token-scoped siblings.

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

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

The description implies the tool is for cross-index funder analysis, but it does not explicitly state when to use it over alternatives or mention any exclusions. The sibling list is provided, but the description itself does not name a specific alternative or routing condition.

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 annotations already indicate read-only and non-destructive behavior, and the description does not contradict this. It adds valuable insight into the meaning of a zero balance and the resulting 402 error, which goes beyond the basic annotations. It does not describe the exact output format, but that may be covered by 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?

The description is extremely concise—two sentences—and conveys all necessary information without redundant fluff. It is well-structured: first states the core purpose, then adds relevant context about the balance meaning. No filler or vague wording.

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 simple balance-checking tool, the description is complete: it defines the resource, the action, and the interpretation of the result. It also mentions the 402 scenario, which is useful contextual information. It does not discuss authentication or key handling, but those are likely implicit and not required for this tool's use.

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 has no parameters, so there is nothing to explain. The baseline for zero-parameter tools is 4, and the description does not need to add information about parameters. The description complements the schema by clarifying what the tool returns.

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 purpose: retrieving the remaining credits on the user's key. It names the resource (key) and the action (remaining credits), leaving no ambiguity about what the tool does. It is distinct from sibling tools focused on tokens, so no confusion arises.

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 provides useful context on when to interpret the balance (e.g., a balance of 0 means paid tools will return 402), implicitly guiding the user to check balance before using paid tools. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, though the clear purpose makes this unnecessary.

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 indicate readOnlyHint=true. The description adds a key behavioral nuance: the tool returns nothing for older tokens and guarantees a live example mint for testing. This goes beyond the safety annotation. It doesn't describe the exact output shape, but it does disclose the empty-result behavior, which is important.

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

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

Two sentences, front-loaded with the core purpose and a usage directive ('Call this first'), then a caveat. Every sentence earns its place.

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

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

Given low complexity and annotations covering safety, the description covers coverage and freshness, and the caveat for older tokens. It doesn't detail the output structure, but for a tool like this it's likely minimal. Slightly more detail on what it returns would help, but it's adequate.

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 schema has zero parameters)Skip. Description mentions a 'live example mint' that could be passed, but it's not a formal parameter. Since there are no parameters, the description doesn't need to explain themaiman. Per rubric, 0 params = baseline 4, and the description doesn't contradict or add param info, so 4 is appropriate.

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

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

States a specific verb and resource: 'what we hold and how fresh' — i.e., a coverage/freshness check. Includes a concrete behavior (returns nothing for older tokens) and a live example mint. Clearly distinct from siblings like check_token or token_report because it frames itself as the first call to gate subsequent lookups.

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

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

Explicitly says 'Call this first', giving a clear ordering instruction. Also explains the condition for use: if the token is from before the start date or not a pump.fun/letsbonk migration, results will be empty. This is actionable when-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond annotations by revealing that this is a cost-free sample served by the same handlers as paid tools, guaranteeing it returns real (not mocked) data, and that each response includes its price. This enriches the agent's understanding of behavior.

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

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

Three sentences, each carrying weight: it starts with the free/no-key advantage, explains what is returned (including pricing), and ends with routing guidance. No filler or 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 tool's role as a sample that aggregates three other tools' outputs, the description covers what is returned, why it can be trusted (same handlers), and how it relates to a sibling. An output schema exists, so there is no need to spell out the return structure. 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?

There are zero parameters in the schema, so schema coverage is effectively 100% (nothing to omit). The description clarifies that the tool uses a fixed token and returns specific outputs, which is more relevant than parameter details. Baseline for 0 params is 4, and the description appropriately compensates by describing the output semantics.

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

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

The description states precisely what the tool does: it returns the complete responses of check_token, inspect_token, and token_identity for one fixed token, along with pricing for each. This is a specific verb-resource combination and clearly differentiates it from siblings like get_coverage, which is about freshness rather than depth.

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 'Use get_coverage for freshness, this for depth,' providing direct guidance on when to choose this tool over an alternative. It also notes that it is free and requires no key, indicating a low-friction use case for testing or exploration.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: the '[free]' prefix discloses cost, and it explains the tool's purpose (showing past performance rather than producing a verdict). No contradiction with annotations exists.

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

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

Three sentences with efficient, front-loaded content: the deliverable first, then the use case, then the differentiator. The '[free]' prefix adds brief cost info without bloat. Slightly unusual placement of '[free]' but no wasted words.

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-parameter read-only tool with an output schema present, the description covers the essentials: what it returns, when to use it, and why it exists. Minor gaps exist — 'risk band' and 'collapse' are domain terms not defined — but for a niche tool they are likely understood in context. The presence of the output schema reduces the burden to explain return format.

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

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

The tool has 0 parameters with 100% schema coverage, so the baseline of 4 applies — there is nothing to document, and the description correctly avoids inventing parameter details. No additional parameter semantics are needed.

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 the specific resource (measured hit rate per risk band) and the exact content (hit rates and collapse speed per band). It clearly differentiates from siblings by noting 'Most risk APIs ask you to trust a score; this one shows how it performed,' positioning it as a performance/transparency tool rather than a scoring API like check_token or token_report.

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?

'Read this to decide how much weight to give our verdicts' provides a clear, actionable use case — the agent knows to call this when calibrating trust in other verdict outputs. However, it doesn't name explicit alternatives or state when NOT to use it, leaving a small gap in guidance.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds a cost of $0.005 per call. It also states 'Counts and structure only', which limits the output to aggregates. This transparency about scope and pricing goes beyond annotations. 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 at about 50 words and front-loads the cost and key topics. It efficiently contrasts with sibling tools in the second sentence. However, the phrasing 'Who is involved:' is a fragment that could be clearer, but overall it's concise and avoids 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?

With an output schema present, the description need not explain return values. It covers the tool's purpose, scope, pricing, and differentiates from alternatives. For a tool with one parameter and moderate complexity, this is adequate. It would benefit from an explicit statement of output, but the output schema likely handles that.

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 single parameter 'mint' is fully described in the schema as 'Solana token mint, base58.', which is clear. The description doesn't add additional semantic context about how the mint is used, but since schema coverage is 100%, the baseline is 3. There's no need for the description to elaborate further.

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 that the tool provides 'top holders and supply' and a 'sniper / fresh-wallet / insider / early-buyer split', indicating it analyzes token holder categories. It explicitly says 'Counts and structure only', which clarifies the scope. It also references sibling tools (token_wallets, token_graph, token_web) to differentiate, though it lacks a clear verb like 'retrieve'.

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 notes that 'token_wallets names them, token_graph draws the edges, token_web follows them to earlier launches', which implicitly tells the agent to use this tool for aggregate counts and structures only. It provides exclusions by stating what this tool does not do (name individuals, draw edges, trace launch history). However, it doesn't explicitly state a condition like 'use this when you need summary statistics', but the contrast with siblings is sufficient.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds cost information ($0.02/page) and details about the data included (lifetime realized SOL, win rate, activity window), which goes beyond the annotations. No contradictions found.

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

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

The description is compact and front-loaded with the cost, followed by the core functionality and a practical use case. Every sentence carries essential information 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?

Given the output schema exists (noted in context signals), the description doesn't need to explain return values. It fully covers what the tool does, the data it ranks, its sorting options, and a typical use case. 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%, with each parameter explained in the schema. The description reinforces the sort values (profit, success, activity) and the recent-activity window concept, but adds no new information beyond what the schema already provides. A 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 what the tool does: it ranks tracked KOL wallets by lifetime realized SOL, win rate, and activity, with sorting options. It also gives a concrete use case (build/refresh copy-trading watchlist). This distinguishes it from siblings like 'kol_record' which likely focuses on a single wallet's details.

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 it ('Use to build or refresh a copy-trading watchlist'), giving clear context. However, it doesn't mention when not to use it or compare with alternatives, so it stops short of the top score.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds notable behavior: it costs $0.02 for tracked addresses, returns null for untracked ones, and the scope of data (lifetime stats, per-token history, latest trades). This adds value beyond annotations, but it doesn't disclose details about pagination, rate limits, or what 'latest trades raw' entails, which are minor given the readOnly annotation.

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 concise, front-loaded with the cost and purpose, and every sentence adds value. It packs essential information—cost, output scope, null behavior, and alternative tool—into two efficient sentences without 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 that an output schema exists (though not detailed in this context, the description lists the key output types), the description covers what an agent needs to call the tool correctly: the resource type, cost, edge case (untracked), and alternative. The tool is a simple single-parameter lookup, and the description is complete for that purpose.

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

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

Schema coverage is 100%, and the single parameter 'address' is described as 'Solana wallet, base58.' The description adds context that the address must be a tracked KOL for meaningful results, but doesn't add syntax or format details beyond the schema. Baseline 3 is appropriate since the schema already fully documents the parameter.

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

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

The description clearly states the tool's purpose: it returns in-depth lifetime stats and per-token trade history for a tracked KOL (Key Opinion Leader). It specifies both the output content and the resource (a single tracked KOL address), and distinguishes it from the related check_wallet tool by noting that untracked addresses return null. The verb 'record' is specific, and the description makes clear this is a focused lookup, not a broad search.

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 provides clear context on when to use this tool: when you need in-depth data for a tracked KOL. It also explains what happens if the address is untracked (returns null, costs nothing) and explicitly points to check_wallet as the alternative for any wallet. It does not state 'when not to use' explicitly, but the alternative routing is strong and sufficient.

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 useful details beyond the read-only and non-destructive annotations, such as the cost per page and the output structure (rows with id, title, url, and id being a Solana mint for fetch). However, it does not mention potential errors, rate limits, or other side effects, so it only partially exceeds what annotations already convey.

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 verbose and includes redundant or confusing phrases such as 'ChatGPT entry point' and 'ChatGPT connects to nothing without this exact name'. The structure is somewhat disjointed, with multiple clauses in the first sentence and an awkward second sentence, detracting from clarity and conciseness.

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 provides essential output context by specifying the return format (rows with id, title, url) and the relationship of id to fetch, which is helpful in the absence of an output schema. However, it lacks details about pagination, edge cases, or error handling, leaving some gaps for an agent relying solely on this description.

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 schema already provides full descriptions for both parameters (query and limit), and the tool description does not add any additional parameter-specific information. Since schema coverage is 100%, the baseline score of 3 is appropriate.

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

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

The description states that this tool performs the same catalogue search as search_tokens and returns rows with id, title, and url, making its purpose clear. However, it does not explicitly use a verb like 'searches', and the phrase 'ChatGPT entry point' adds ambiguity, though the core action is still understandable.

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 tells ChatGPT to use this tool and directs other clients to call search_tokens instead, providing clear guidance on when to use this tool versus the alternative. It also notes that this is an alias with the same endpoint and price, leaving no room for confusion.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful context beyond that: per-page pricing, the fact that it searches an analysed catalogue, and that it is an alias of `search`. No contradictions or hidden side effects are indicated.

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

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

Two sentences carry the core purpose, filters, sibling distinction, and alias note with zero filler. The pricing informaton is front-loaded and the most decision-relevant facts appear first.

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 search tool with 100% parameter documentation, an output schema, and annotations covering safety, the description is complete. It covers cost, search scope, filtering, sibling distinction, and alias behavior—nothing essential to calling 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%, so the baseline is 3. The description adds value beyond the schema by clarifying `q` semantics as symbol, name fragment, or exact mint, and by mapping 'platform, size and age filters' to platform, min_mcap, and days. This helps the agent map natural language to the right parameters.

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: 'Find a token in the analysed catalogue', with concrete search modes (symbol, name fragment, exact mint) and filters. It explicitly distinguishes itself from find_tokens and acknowledges the search alias, making sibling differentiation immediate.

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?

Provides an explicit usage rule: 'find_tokens lists what just migrated; this finds the one you mean.' This tells the agent when to choose this tool over a close sibling. It also names the `search` alias as the ChatGPT-shaped variant, covering an alternative invocation path.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only over stored history; measured past, not a forecast.' It further discloses return behavior ('Returns cohort aggregates and a one-sentence finding, never per-token rows') and the cost, adding meaningful context beyond the annotations.

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

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

The description is compact yet information-dense, front-loading the core measurement purpose, then covering cost, alternatives, filter syntax, return shape, and safety. Every sentence earns its place with no filler or repetition of schema details.

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 two-parameter schema, output schema presence, and annotations, the description covers everything needed to decide when and how to call the tool: purpose, filter format, field source, expected return shape, alternative tool, cost, and read-only semantics. Nothing critical 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. The description adds real value by explaining the filters shape as '{field: {min,max}}', grounding it in fields from get_coverage, and giving a concrete example '{total_holders: {min: 200}}'. This goes beyond the schema's bare object type.

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 clear verb and resource: 'Measure what happened to every indexed launch matching your filters' and enumerates specific outputs (rug rate, peak-gain percentiles, time to peak, collapse speed). It also distinguishes itself from find_tokens, so an agent can tell them apart 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?

The description explicitly identifies when to use this tool ('Answers pattern questions like do launches with under 200 holders die faster?') and names the alternative for a different use case ('to shortlist live tokens to act on, use find_tokens instead'). It also clarifies that filters reference numeric fields listed by get_coverage, giving clear context for correct invocation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral context: it performs a live chain read, incurs a $0.025 cost, and diffs against previously recorded data. This goes beyond what the annotations alone convey.

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

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

The description is compact and front-loaded: it opens with the user-facing question, then explains the mechanism, then gives usage context, then a differentiating caveat. Every sentence earns its place.

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

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

For a single-parameter read-only tool with an output schema and safety annotations, the description covers what the tool does, when to use it, its live-chain behavior, and its cost. Nothing essential is missing for an agent to select and 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 coverage is 100% and the only parameter, mint, is already described as a Solana token mint in base58. The description does not add parameter-level detail beyond that, so the schema carries the semantic weight.

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 reads the chain and diffs large positions against previously recorded data to answer 'who sold since we analysed it.' It also distinguishes itself from siblings by noting it is the only call that touches the chain live.

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

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

The description gives explicit when-to-use guidance: use it when a cached read feels stale or when checking whether concentrated wallets are exiting. It implies alternatives are cached reads and positions this tool as the live-chain option, though it does not name a specific sibling 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 declare readOnlyHint=true and destructiveHint=false, so the tool is known safe. The description adds behavioral context beyond annotations by specifying the kind of insights returned (edges with strength/confidence, cluster membership, wash-trading detection), which helps the agent set expectations about the output. It does not contradict annotations. The description carries the burden for non-safety behaviors and does so adequately.

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 concise and well-structured: it front-loads the cost, then the main purpose, followed by the key outputs and a usage note. Every sentence contributes information, and the differentiation from token_wallets is integrated naturally. There is no wasted wording.

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

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

The tool has one required parameter with schema coverage, an output schema, and a description that explains the main purpose and usage context. The description mentions the nature of the output (edge strength, clusters, wash-trading), which is informative. While it doesn't detail every aspect of the returned graph, the output schema covers the structure. It is complete enough for an agent to decide when to call it, though it could explicitly state that it is complementary to token_wallets and perhaps other network-related tools. Still, it meets most criteria for completeness.

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% as the sole required parameter 'mint' has a description ('Solana token mint, base58.'). The tool description adds no additional parameter-level semantics beyond the schema, but with full coverage, the baseline score of 3 is appropriate. The description mentions 'token' in general context, but the schema already defines the parameter clearly.

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 explicitly states the tool's purpose: 'The wallet relationship graph behind a token' with specific entities (edges, strength, confidence, clusters, roles, wash-trading wallets). It also differentiates from a sibling tool: 'token_wallets names the holders; this shows how they are CONNECTED and whether a distributed-looking set is one person.' This gives a precise verb-resource and distinguishes it from the most closely related tool.

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

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

The description provides clear context for when to use the tool: it is 'Not a first look' and references token_wallets as the tool that names holders, implying this tool is used after or in conjunction with it to understand connections. However, it does not explicitly list exclusions or alternatives beyond token_wallets, though the sibling list is extensive. The guidance is sufficient for an agent to route to this tool when relationship analysis is needed.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate safety. It adds valuable behavioral context: the tool reports coverage per call, charges $0.025, and returns free empty results if no coverage. This goes beyond the schema and annotations, informing the agent about cost and data availability.

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

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

The description is compact and front-loaded: it starts with the cost, then the core question, and lists key data points. Every sentence adds value—cost, scope, decision-point role, and coverage behavior. No fluff or 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?

The tool has one parameter, full schema coverage, and an output schema, so the description doesn't need to explain return values. It covers the purpose, cost, and coverage behavior. However, it doesn't mention edge cases like how to interpret empty results beyond being free, or whether results are ordered by relevance, leaving minor gaps for an agent seeking complete decision support.

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 'mint' parameter described as 'Solana token mint, base58.' The description doesn't add to this but doesn't need to, since the schema is clear. It indirectly refers to the mint as the token being analyzed but provides no additional semantic details beyond the schema. Given high coverage, a baseline of 3 is appropriate, but the description's 'mint' usage in context adds slight value, earning a 4.

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 explains the tool's purpose: to reveal the identity behind a token by analyzing its largest holders' history and outcomes. It uses a specific metaphor ('Who is BEHIND this token') and cites concrete aspects (largest holders, sibling tokens, upside band). However, it doesn't explicitly differentiate from siblings like check_token or inspect_token, relying on the phrase 'decision-point call' to imply uniqueness.

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 implies when to use this tool: at the decision point, when you need identity context beyond basic checks. It mentions coverage reported per call and free empty results, which suggests using it iteratively. However, it doesn't explicitly state when not to use it or mention alternatives like check_wallet or find_serial_insiders, which may overlap.

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 readOnlyHint=true and destructiveHint=false, which the description does not contradict. The description adds valuable behavioral context: it specifies the data resolution (4-5 second), the feed start point (analysis, not bonding-curve), and the specific metrics (peak, drawdown, current). This exceeds what annotations provide and helps the agent understand the tool's temporal scope.

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 concise and front-loaded. It starts with the cost indicator and then states the tool's output in a clear, short sentence, followed by a brief clarifying note about the feed's temporal scope. Every sentence adds value with no wasted words.

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

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

The tool has an output schema (though not shown in full), one parameter, and clear annotations. The description explains the temporal scope and metrics, but does not mention factors like data availability or edge cases (e.g., what if the token wasn't analyzed yet). For a single-parameter tool with an output schema, this is adequate but not exhaustive.

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 only parameter 'mint' is described as 'Solana token mint, base58.' The description does not add extra parameter-level detail beyond what the schema provides. The baseline of 3 is appropriate since the schema fully documents the parameter.

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

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

The description clearly states what the tool does: reports what the token did after being called, including peak, drawdown from peak, and current standing, at 4-5 second resolution. It distinguishes itself by specifying the feed starts at analysis and excludes the bonding-curve phase, which differentiates it from other token inspection tools in the sibling list.

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 implies usage (to get token price action after analysis), but does not explicitly state when to use this tool versus alternatives like check_token, inspect_token, or token_report. The distinction from the bonding-curve phase is noted, but there is no explicit 'when to use' or 'when not to use' 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?

The description discloses cost ($0.07 for full depth) and indicates that the full depth adds outcome path, live sellability, and wallet graph. The annotation already marks it read-only, so the description adds cost and content info without contradictions.

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 tight and informative, covering the tool's composition, cost, parameter depth, and use case in just a few sentences. No redundant words or fluff.

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 formats. It adequately covers the depth parameter and cost, and it clearly positions the tool relative to siblings. It could mention error scenarios or edge cases, but for a combined report tool this is sufficient.

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 description enriches the schema by explaining what each depth level returns: 'core: verdict, holders, identity' and 'full adds graph, price path, sellability.' This goes beyond the bare enum definition and clarifies the trade-off of using the full depth.

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 this tool combines check_token, inspect_token, and token_identity into a single call, and it names the sibling tools it pulls from. The phrase 'use once a token is worth a real look' gives a concrete use case, making its purpose distinct from the individual 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?

The description explicitly mentions when to use it ('once a token is worth a real look') and notes it is 'cheaper than the parts,' which guides the agent toward using this composite when multiple pieces of token info are needed. It does not explicitly say when not to use it, but the context is clear enough compared to the sibling tools.

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

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

Read-only and non-destructive are already declared in annotations, and the description adds independently useful behavior: per-class list cap at 100 and real counts in *_total fields. It also conveys the output granularity, which goes beyond what annotations already provide.

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

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

Three dense sentences with no filler. The cost is front-loaded, core output classes come second, the cap behavior third, and the sibling distinction closes it. Every sentence earns its place.

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

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

With one required parameter fully covered, an output schema present, and the description explaining the key truncation caveat and the difference from inspect_token, nothing needed to invoke the tool correctly is missing.

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

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

The only parameter, mint, is fully documented in the schema as a Solana token mint in base58, so high schema coverage sets a baseline of 3. The description adds little parameter-level detail but does clarify that the mint identifies a single token for wallet analysis.

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 exactly what is returned: named wallet addresses behind a token, grouped by behavioral classes (insiders, snipers, early buyers, etc.), with funder, link count, and cluster. It also explicitly differentiates itself from inspect_token by noting that this tool provides addresses rather than counts.

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 final sentence explicitly contrasts with inspect_token ('inspect_token gives counts, this gives addresses'), which tells an agent when this tool is the right choice. It stops short of broader when/when-not guidance against the many other sibling tools, but for address-level wallet data the guidance is adequate.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds beyond that by disclosing the $0.04 cost, the tie-outcome details, and emphasizing this operation crosses token boundaries rather than staying within one token. 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?

Three short sentences front-load the cost and core output, then give the when-to-use rule and the contrast with a sibling. Every sentence contributes distinct information 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?

For a 2-parameter read-only query tool with a full output schema and clear sibling positioning, this description is complete enough. It covers cost, triggering conditions, output semantics, and the tool’s cross-token scope. No critical gap remains.

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%, so both mint and min_shared are already documented in the schema. The description refers to 'shared wallets' and 'WHICH launches,' which aligns with min_shared, but adds no concrete syntax or behavioral detail beyond what the schema provides.

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

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

The description clearly identifies the resource (earlier launches tied to a token via shared wallets) and the output (wallets, outcomes, highest market cap). It explicitly differentiates from sibling tools by contrasting with token_graph, which stays within one token, and token_identity, which reports shared wallets.

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

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

Explicit when-to-use guidance is provided: 'Use when token_identity reported shared wallets and you need WHICH launches.' It also gives a clear when-not/alternative statement by noting token_graph stays inside one token while this tool crosses 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context: cost, the bounded nature of the second hop, and the specific data categories (counts, shared tokens, direction). This goes beyond the annotations without contradicting them.

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

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

A single dense sentence that front-loads cost and core functionality, then adds a differentiating contrast. Every word contributes; no fluff.

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 output schema is present, the description doesn't need to explain return structure. It explains what the tool returns at a high level and mentions a key limitation (bounded second hop). It's complete enough for an agent to call safely.

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 covers 100% of the parameter (address as Solana wallet, base58). The description adds no new semantic detail about that parameter, 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 verb and resource: maps who a wallet is wired to, with concrete outputs (direct counterparts, interaction counts, shared tokens, transfer direction, bounded second hop). Explicitly contrasts with check_wallet, distinguishing it from a close 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?

Provides a clear usage contrast with check_wallet ('what it DID' vs 'who it MOVES WITH'), guiding when to prefer this tool. Doesn't enumerate alternatives like token_graph or funder_networks, but the single contrast is sufficient for the main decision.

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