DeepCounterfeit

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds real behavioral context beyond them: it discloses the scope boundary ('Does not assess creator behaviour') and what the output tells you ('which brand, and why'). It stops short of describing confidence levels, rate limits, or whether a negative result is conclusive.

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, none wasted, and the core capability plus the sibling routing are front-loaded. Slightly longer than strictly necessary given the example coin names, but those examples usefully illustrate what a positive detection looks like.

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 no output schema, the description carries the return-value burden and largely does so by stating it reports whether the name would be flagged, which brand, and why. It also covers the negative scope. Remaining gaps (opt-in parameters, result granularity) are minor for a read-only lookup whose annotations already signal safety.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters with examples. The description reinforces the name/ticker pairing and that no address is required, but adds no syntax or constraint detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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: 'run the impersonation detector on a token name and/or ticker symbol without needing an address'. It also explicitly scopes out the sibling by noting that check_token is used when an address is available, so an agent can discriminate between the two without opening a schema.

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

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

Gives concrete when-to-use conditions ('pre-launch name checks', 'when a user mentions a coin by name and you have no address') and names the alternative tool plus the exact condition that selects it ('with an address, use check_token'). 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 only cover the read-only/idempotent profile; the description adds substantial behavioral context: the three verdict values, the concrete risk-score signals (supply bought at launch, same-block bundles, creator cash-out, serial launcher), the returned creator wallet/explorer links, and an API-key tier that degrades to brand match only. That tiering is exactly the kind of thing 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?

Front-loaded with what the tool is and what it returns, with the usage trigger next and caveats last. Dense but every clause carries information; the parenthetical risk-signal list is somewhat long but justifies itself by previewing the risk score.

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?

There is no output schema, so the description carries the full burden of explaining returns, and it does: verdict enum, matched brands, risk score range, reasons, and creator/explorer links. The unauthenticated-mode caveat and the negative-result disclaimer close the two biggest interpretation risks, leaving only the chain-parameter default as a minor gap.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the mint-vs-0x-contract distinction. The description restates the address meaning but adds nothing about the chain enum (including the unusual "robinhood" value) or what happens when chain is omitted, so it does not exceed the baseline.

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

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

States a specific verb+resource (look up a deployed token by contract/mint address) and the exact judgment it returns (brand impersonation verdict). The examples (fake SpaceX, Coinbase, NVDAx) and the contrast with a name-based lookup (sibling check_name) make it unmistakable which tool this is.

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 before buying, listing or promoting a token" gives a concrete triggering context, and the warning that "not_in_index" is not a safety guarantee tells the agent how to interpret a negative result. It never explicitly says to use check_name for brand names instead, so the sibling routing is left implicit.

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 safe, read-only, idempotent, closed-world behavior, so the description's job is to add beyond that — and it does: data comes from public on-chain sources only, it is explicitly not financial advice and not a finding about any person, and it discloses tiering (free headline score vs. full breakdown with API key or $0.10 USDC via x402). It omits latency, rate limits, and failure behavior for unknown wallets.

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 scope is front-loaded correctly, but the body is one long run-on sentence stacking many indicator clauses. Every clause is informative, yet the lack of structure (bullets or a shortened list) makes a dense definition harder to scan than it needs to be.

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 no output schema, the description carries the burden of explaining what is returned, and it does so by enumerating both the free headline output (score 0-100, band, counts) and the paid breakdown, plus the endpoint. That is close to complete for a one-parameter lookup; only return-shape details for the paid tier and error behavior are 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 single `wallet` parameter is fully documented in the schema (base58 Solana or EVM 0x), and schema description coverage is 100%. The description repeats the chain-format detail but adds no new constraint, so the baseline 3 applies.

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

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

Opens with a specific verb-and-resource framing: reputation indicators for a token creator wallet, then enumerates the exact indicators (launch count, bundling share, creator-dump share, liquidity removal, linked wallets). An agent knows what it gets. It stops short of naming the sibling it competes with (token_manipulation_score, kol_scorecard, trace_wallet), so differentiation is left 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 makes the use case implied (screening a creator wallet's launch history) and explains the free vs. paid access path, but it never states when to choose this over token_manipulation_score, kol_scorecard, or trace_wallet, which all overlap on wallet and manipulation analysis. Usage is inferable, not directed.

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 declare readOnlyHint, idempotentHint, non-destructive behavior, and closed-world scope. The description adds useful behavioral context by listing returned fields and noting that an API key unlocks additional risk and creator data, though it does not discuss error behavior or missing-result cases.

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

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

The description is two compact sentences with the primary purpose front-loaded and the usage rule immediately after. Every clause contributes actionable 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 simple one-parameter read-only tool with complete schema coverage and annotations, the description supplies sufficient context: what it returns, when to use it, and the direct alternative. No output schema exists, so the field list is especially helpful.

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 the single id parameter with examples. The description reinforces that the id must come from search and gives the "<chain>:<address>" format, but adds little 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 clearly states that this tool fetches a full check_token result for an id returned by search, and enumerates the returned fields. It distinguishes itself from search and check_token by explaining the result-id workflow versus known-address lookup.

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 to use this after search and directs agents to call check_token directly for a known address. This gives both the intended sequence and the relevant alternative 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?

Beyond the annotations (readOnly/idempotent/non-destructive), it discloses traits the agent could not otherwise know: an empty call returns a case index, unauthenticated or trial keys get a truncated preview (summary, detectors, hash, first transactions), and the output is scoped to on-chain facts with no intent or identity claims. The determinism implied by a SHA-256 integrity hash is also useful behavioural context.

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

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

It is front-loaded with the resource and packs only high-value content, but the opening is a long semicolon-separated run-on that is closer to a feature dump than a structured list. Slightly reformatting the output inventory would improve scanability without losing content.

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 no output schema, the description carries the full burden of describing the return payload, and it does so completely: detector confidence plus false-positive notes, Solscan-linked signatures, timeline, P&L, and funding graph. Access-tier behaviour and the empty-argument case are also covered, leaving nothing an agent needs before calling it.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it maps the three lookup modes to case types (token, creator group, caller) and tells the agent that omitting all of them yields an index rather than an error. That last point is not derivable from the schema's optional 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 — an evidence pack for a flagged pump.fun token, creator wallet group or caller — and enumerates exactly what it contains (detectors, tx evidence, timeline, P&L, funding graph, integrity hash). That content profile makes it unmistakable against siblings like token_manipulation_score, kol_scorecard or trace_wallet, which return scores or traces rather than a packaged case file.

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 concrete lookup guidance — case id prefixes TK-/CL-/KOL-, mint, or wallet — plus the useful edge case that no argument returns an index of cases, and it explains trial vs paid key behaviour. What is missing is any explicit routing statement against the sibling tools (e.g. when to open a case file instead of calling token_manipulation_score first).

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

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

Annotations already declare read-only, idempotent, non-destructive behaviour, so the safety profile is covered. The description adds genuinely new context beyond them: the report contents (fake coins, volume, repeat creator wallets, 50%+ supply buyers, evidence cases) and the Pro/Wholesale tier gating for the takedown PDF link, which is an access condition not visible in 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?

A single front-loaded sentence that leads with the core action and scope before the content list. Dense but every clause names a distinct report section, so little is wasted; the trailing tier note is the only slightly separable piece.

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 no output schema, the description carries the full burden of describing return values, and it does so thoroughly by enumerating the report's sections and the tier-dependent PDF link. Combined with annotations covering the safety profile, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, with 'brand' and 'days' (default 30, 1-365) fully documented, so the baseline is 3. The phrase 'over a window' loosely maps to 'days' but adds no format or semantics 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?

States a specific verb (summarise) and resource (impersonation activity against one brand) and enumerates the exact contents of the report. A reader can distinguish it from get_stats, list_brands, and search_alerts 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?

The scope ('one brand over a window') implies when the tool applies, but there is no explicit when-to-use or when-not guidance and no named alternative among the siblings (e.g. search_alerts for individual cases). Usage is inferable but not stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds that output includes data-source health and coverage, implying a freshness signal, but says nothing about pagination, limits, or what a call actually returns structurally.

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

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

Two dense sentences, zero filler: the first front-loads what is returned, the second states intended usage. Every clause 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 no output schema, the description correctly compensates by enumerating the aggregate fields returned, and annotations cover the safety profile. It is nearly complete, only missing window defaults/limits that live in the schema and any note on result shape beyond the metric list.

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% with a single optional 'days' parameter whose default, min and max are documented in the schema. The description references 'a window' but adds no format or interpretation detail beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Aggregate numbers for a window') and enumerates the returned metrics (alerts, high-severity count, brands hit, by chain, by match type, top brands, data-source health). This clearly delineates it from siblings like get_brand_report, but it never explicitly names an alternative, so it stops short of a 5.

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

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

Gives clear when-to-use guidance: 'Use for overviews, trend questions and to check data freshness.' That covers the primary intents, but it offers no exclusions or explicit alternative routing (e.g., when to prefer get_brand_report or search_alerts).

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 disclose that this is a non-read-only, non-idempotent, non-destructive operation. The description adds important context beyond annotations: the key is returned once, must be given to the user and inserted as an X-API-Key header or query parameter, and the call does not count against the free daily limit. It does not explain key lifecycle details such as what happens if the tool is called repeatedly or whether an existing key can be retrieved.

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 purpose is front-loaded in the first sentence, and the description uses only a few sentences to cover benefits, consent, key handling, and rate-limit context. Some phrasing is redundant, such as repeating 'no card' from the title and restating the daily-limit point, but the structure remains efficient overall.

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

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

For a tool with one required parameter, no output schema, and annotations covering the safety profile, the description is largely complete. It explains what the tool returns, how the agent should handle the key, and the consent constraint. It could be stronger by clarifying duplicate-call behavior or key replacement, but the core invocation guidance is present.

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

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

Schema description coverage is 100%, so the schema already documents both parameters, including that the email must be the user's own and that disposable domains are rejected. The description reinforces the consent and ownership requirement for the email, but adds little about the optional company field. A baseline 3 is appropriate when the schema does the heavy lifting.

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: creating a free 14-day trial API key for the user, with real-time data and no daily cap. It clearly distinguishes the result from the keyless Free tier. It does not differentiate from sibling tools, but no sibling appears to offer a directly comparable trial-key action.

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 an explicit prerequisite: only call this with the user's explicit consent and their own email address. It also frames the tool as an alternative to the keyless Free tier, which is delayed and limited. It does not specify additional when-not-to-use conditions beyond consent and email ownership.

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 declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context beyond annotations: public handles/wallets only, and access-tier-dependent output ('headline numbers only' without a trial/paid key). It does not describe return structure or error behavior, but the added tier limitation is meaningful.

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 definition is compact and front-loads the caller context before listing metrics. The metric list is dense but each item is informative, and the scope/access constraints are placed at the end without redundant 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?

For a one-parameter read-only scorecard tool with no output schema, the description gives a strong content-level summary of what the scorecard includes and notes the key access limitation. It could be more explicit about response shape or invalid/private-handle behavior, but it is largely sufficient for selection and invocation.

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

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

Schema description coverage is 100%, and the single parameter is already documented as a wallet address, pump.fun username, or X handle. The description reinforces the 'public' constraint but adds no new syntax or format details beyond the schema, 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 is highly specific about the resource and the computed metrics: it names a public pump.fun caller and enumerates buy-before-call frequency, median lead time, sell-within-1h frequency, 50%+ drawdown frequency, serial-launcher calls, and creator-to-caller transfers. That is enough to distinguish it from token-level tools like token_manipulation_score, though it does not explicitly name competing 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?

It gives scope constraints — 'Public handles and wallets only' and 'Without a trial/paid key: headline numbers only' — which help decide eligibility. However, it does not state when to use this instead of trace_wallet, token_manipulation_score, or other sibling tools, so guidance is implied rather than explicit.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds value beyond them by disclosing the returned content (ids, tickers, all-time alert counts) and the ordering (most-targeted first), though it says nothing about pagination or how to page past the limit cap.

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, zero filler: the first front-loads what is returned and in what order, the second front-loads the use case. Nothing is repeated or padded.

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

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

For a read-only, zero-required-parameter list tool with full schema coverage and strong annotations, the description covers purpose, use case, return contents and ordering. It lacks pagination/truncation behavior and any note on how results relate to sibling lookup tools, which are the only remaining gaps.

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

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

Schema description coverage is 100%, so limit, query and category are already fully documented in the schema. The description only echoes the 'most-targeted first' ordering that the limit parameter already states, adding no new parameter semantics.

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

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

States a specific verb and resource ('List the brands on the watchlist') and enumerates what a brand can be (companies, tokenized stocks, crypto projects, private companies) plus the returned fields and sort order. It is unambiguous what the tool does, though it never names a sibling tool to differentiate from search or get_brand_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?

The second sentence gives concrete when-to-use triggers: finding a brand id or checking whether a brand is covered. There are no exclusions or explicit pointers to alternatives such as check_name or search, so it stops short of the 5-level routing guidance.

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

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

Annotations already cover read-only/idempotent/non-destructive, and the description still adds real behavioral context: refusal to estimate for unknown mints, a tiered access model (free/keyless gives verdict + codes, full report requires an API key or $0.01 USDC x402 pay-per-call), and the exact paid endpoint. The 'informational only, not financial advice, no guarantee' caveat sets expectations about reliability.

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 verdict and scoring are front-loaded and no sentence is filler, but it packs signals, pricing tiers, a URL and a legal disclaimer into one dense paragraph. It remains readable, though a split between 'what it returns' and 'how to access it' would be tighter.

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?

There is no output schema, so the description carries the return-shape burden and does: verdict enum, 0-100 risk_score, and reasons[] as code plus one line. It also resolves the one thing an agent could get wrong, treating a missing mint as 'unknown' rather than inferring risk, and explains what changes with an API key.

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 'mint' parameter already documents base58 Solana and 0x EVM acceptance. The description adds only the emphasis that Solana/pump.fun is the main target, which is marginal beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('one fast call before buying a token' returning verdict clear/caution/avoid/unknown, risk_score 0-100, reasons[]) and enumerates the signals it aggregates: brand imitation, creator wallet reputation, bundled launch, holder concentration, age/liquidity/graduation. That scope distinguishes it from siblings like creator_reputation or token_manipulation_score, which cover only one of those dimensions.

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?

Clearly frames the trigger ('before buying a token', Solana mint, mainly pump.fun) and gives a usable fallback rule: mints not in the data return 'unknown', never an estimate. It does not name alternative sibling tools or state when another tool would be a better choice, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds one useful behavioral fact beyond annotations — that results are ids intended to be passed to fetch — but says nothing about pagination, result caps, or match quality. With annotations carrying the safety burden, this is adequate but thin.

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

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

Two compact sentences, no filler, and the core action plus return contract are front-loaded before the alternative-tool advice. Every clause carries information.

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

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

For a one-parameter read-only search with no output schema, the description supplies the essential missing piece — that the output is ids to feed into fetch — and annotations cover safety. It stops short of describing result volume or pagination, but nothing critical for a correct call is absent.

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

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

Schema coverage is 100% and the single parameter's description already explains the brand-vs-coin matching behavior in detail. The description merely restates the accepted input types ('brand name, ticker or coin name') without adding format rules or examples the schema lacks, so the baseline 3 applies.

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

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

States a specific verb and resource ('Search the impersonation index') plus the accepted input dimensions (brand name, ticker, coin name) and what comes back ('result ids for fetch'). This is clearly more than a restatement of the name, but the purpose sentence itself doesn't differentiate the tool from search_alerts or check_name; that separation only appears in the next sentence.

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?

'Prefer search_alerts / check_name when available' explicitly names alternative tools and gives a condition for choosing them, which is real routing guidance. The condition 'when available' is left undefined, so the agent doesn't know what availability means in practice.

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 the safe read-only, idempotent, closed-world profile. The description adds meaningful behavior beyond that: the Free-tier restriction to alerts older than 24 h with a 20-result cap. It does not mention pagination behavior or auth requirements for the keyed tier in detail.

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

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

Two tight sentences with no filler. The core purpose and ordering come first, and the tier caveat is placed at the end where it belongs.

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 no output schema and all parameters optional, the description supplies the key context an agent needs: sort order, available filters, and the Free-tier time/limit constraint. Minor gaps remain around the keyed tier's behavior and result shape.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters including relative time formats and severity thresholds. The description restates the filter dimensions but adds no new syntax or defaulting detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('List recent impersonation coins') plus ordering ('newest first') and the filter dimensions. It is clearly distinguishable from siblings like check_token, get_brand_report, and 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?

Gives three concrete use cases (answering 'are there fake <brand> tokens?', monitoring a brand, collecting takedown cases), which tells the agent when this tool is appropriate. It does not name an alternative sibling or state when-not to use it, so it falls short of a 5.

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

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

Annotations already cover read-only/idempotent/non-destructive. The description adds value beyond that: access tiers (free headline vs. full report with any API key vs. x402 at $0.01 USDC via a specific endpoint), data-provenance guarantees ('never estimated'), and a disclaimer that results are informational only. It stops short of stating rate limits or error 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?

The essential subject and time windows are front-loaded, but the single dense sentence with stacked parentheticals (proven-wallet definition, fee treatment, exclusions) is hard to parse, and access/pricing details are trailed at the end.

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

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

For a single-parameter read tool with no output schema, the description does the heavy lifting on what the response contains (flow counts, share of active wallets, net SOL flow, first entry time, exit signal, wallet score bands, coverage and confidence). Only the response shape and error cases remain unspecified, which is acceptable here.

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 there is only one parameter, so the baseline is 3; the description earns a bump because it constrains the mint to pump.fun bonding-curve tokens specifically, which the schema's generic 'Token mint address (Solana base58, pump.fun)' only partially conveys.

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

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

Opens with a specific verb+resource framing ('for a pump.fun token mint: how many proven wallets bought or sold it in the last 15 min / 1 h / 24 h') and enumerates the metrics returned. It's clearly distinguishable in substance from siblings like creator_reputation or token_manipulation_score, but never names or contrasts those alternatives explicitly.

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

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

Scope constraints are stated ('pump.fun bonding-curve (pre-graduation) trades only'), which implicitly tells the agent when this applies. However there is no explicit 'use this instead of X when...' routing against the many sibling scoring tools, so the agent must infer 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral context: the 72-hour analysis window and the key/tier gating that drops the creator exchange cash-out trail for free callers. It does not cover latency, scoring methodology caveats, or error 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?

Front-loaded with the score range and subject, then the signal list and tier caveat. The pattern enumeration is dense but each item earns its place as an expectation of what the score reflects; only the phrasing is slightly compressed.

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 no output schema, the description carries the burden of describing returns and does: a 0-100 score, the pattern breakdown, the optional cash-out trail, and what free-tier callers get. For a one-parameter read tool, nothing essential is missing.

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

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

The single 'mint' parameter is fully documented in the schema (100% coverage), so the description need only align with it. It does so implicitly by referring throughout to a pump.fun token but adds no format, chain, or validation detail 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?

Names a specific verb and resource ('Score 0-100 ... for a pump.fun token') plus the exact analytic signals (bundled launch, creator sell-off, serial-launcher group) and time window. It is clearly distinguishable from siblings like kol_scorecard or check_token.

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

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

Usage is implied — call it to assess a pump.fun mint for manipulation risk — and the tier note signals what a non-paying caller gets. But there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as check_token or kol_scorecard.

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

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

Annotations already cover read-only/idempotent safety, and the description adds substantial non-obvious behavior: a 3-hop traversal limit, the source of exchange labels (public label set), a snapshot-based coverage restriction, tiered access returning only a summary preview without a key, and an explicit "patterns only, not findings about any person" framing. These are exactly the operational and interpretive constraints an agent needs before calling.

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

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

Front-loaded with the core output promise before scope, disclaimers, and paywall notes. Dense but every clause carries information; the parenthetical enumerations of exchanges and wallet-group contents are slightly heavy for a single paragraph but do not waste space.

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

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

No output schema exists, so the description carries the return-value burden and does so by listing the returned artifacts (cash-out trail, deposit addresses, funding source, wallet group stats). Coverage limits and license gating are disclosed; only the concrete response shape/field layout is left unspecified, which is a minor gap.

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

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

With a single parameter and 100% schema coverage, the schema already defines the base58 Solana address. The description adds a bit of semantic context (the wallet is typically a token creator and must be in the forensics snapshot), which constrains what values make sense beyond format alone.

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 ("for a Solana wallet ... return where its SOL/USDC went") and enumerates exactly what comes back: transfers up to 3 hops, exchange hot wallets, deposit addresses, funding source, wallet group. None of the sibling tools (token_manipulation_score, kol_scorecard, check_token) do wallet fund-flow tracing, so it is clearly differentiated.

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

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

Gives clear applicability context: the wallet is "typically a token creator" and must be "in the current forensics snapshot (creators of flagged impersonation coins, serial launchers, creators of KOL-called tokens)", which implicitly excludes out-of-snapshot wallets. It also flags the paywall condition ("Without a trial/paid key: summary preview"). It stops short of naming an explicit alternative tool for non-snapshot wallets.

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