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?

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?

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?

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 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.