fingers

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

With no annotations, the description carries full burden and does well: it names threat feed sources (GoPlus, SlowMist/BlockSec), lists flag categories, and explicitly discloses that 'No flags = no KNOWN bad history (not a guarantee of safety)'. This caveat prevents misinterpretation of results.

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

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

Two dense but purposeful sentences front-load the core purpose. The complex second sentence delivers necessary nuance about use cases and limitations without wasted words, though it is slightly heavy.

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 no output schema, the description covers purpose, scope, data sources, flag categories, and the interpretation of a 'no flags' result. It could describe the return format but is otherwise complete for an agent to select and invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning to the address parameter by noting it works on any address even without a contract, but it does not elaborate on the chain parameter beyond what the schema states.

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?

Description clearly identifies the tool as a wallet/address reputation check from GoPlus threat feeds and enumerates specific threat categories (phishing, drainer, money laundering, mixer use, etc.). It distinguishes from siblings by emphasizing it works on ANY address even without a contract and positions it as a pre-launch/pre-mint check.

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: it is the key pre-launch/pre-mint check for a project's creator/deployer wallet and also vets any wallet a user will interact with. This gives context for selection, though it does not name alternative tools for contrast.

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?

No annotations provided, so the description carries the full burden. It discloses that A2A does not verify card authenticity, warns about impersonation/tampering, and lists specific flags (unreachable card, new domain, wallet flagged, mismatch). This is transparent about limitations and outputs, though it doesn't detail auth/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?

Somewhat long but front-loaded with the key action, then explains risks, outputs, and comparison. All sentences contribute, though the KYA-complement phrasing is slightly cryptic.

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 complex tool with no output schema, the description covers what the tool fetches, what it reports, and what problems it flags, along with the trust model. It lacks explicit return format/error handling, but overall quite complete.

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

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

Schema coverage is 100%, so baseline 3. The description restates the parameter guidance ('Give the agent's domain or Agent Card URL') with an example, adding minimal value beyond schema.

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

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

The description opens with a clear verb ('VERIFY ANOTHER AI AGENT before trusting or paying it'), specifies the resource (A2A Agent Card + ERC-8004 identity proof), and distinguishes from generic verify/check siblings by focusing on agent cards and impersonation risks.

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?

States when to use (before trusting or paying an agent) and gives input format. Mentions KYA-complement, implying a counterpart tool, but does not explicitly name sibling tools or list exclusions, so it's not 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?

With no annotations to rely on, the description fully covers behavioral traits: it treats content as untrusted data, never obeys it, returns a severity read, and surfaces addresses/links for separate verification. It even warns about the real-world risk of compromised agents, providing valuable 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?

The description is moderately long but each sentence serves a purpose: purpose, examples, risk rationale, and output. The opening question is engaging and front-loaded. Slight redundancy exists (e.g., 'untrusted data' repeated), but overall it is well-structured.

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

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

The description is complete for this simple one-parameter tool. It explains when to use it, what input to provide, what it does internally, and what output to expect (severity read + surfaced addresses/links). No output schema exists, but the description fills that gap thoroughly.

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 100% coverage for the single 'text' parameter, so the baseline is 3. The description adds semantic depth by explaining what kinds of content are expected and providing concrete examples of malicious patterns, giving the agent a richer understanding of how to interpret the input.

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 tool's purpose: screening content for prompt-injection and social-engineering before an agent acts on it. It distinguishes itself from sibling security tools by focusing on the content-to-action flow rather than on-chain or address 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?

The description implies clear usage: before an agent acts on any untrusted content (message, tweet, DM, webpage, tool output). It does not explicitly name alternatives or exclusions, but the context is strong and distinct from the sibling tools listed.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It prominently warns that on no-code/SeaDrop mints the contract deployer is usually OpenSea, advising to vet the owner and payout wallets and check for drained funds. This is valuable, non-obvious behavior that helps the agent interpret results. However, it does not mention return format, potential errors, rate limits, or whether the tool is read-only, leaving slight gaps.

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 about 100 words and packs substantial information in a logical flow: core purpose, output items, use cases, critical caveat, and follow-up suggestions. It is concise for the complexity it covers, though slightly dense with multiple parentheticals. Every sentence contributes value, but it could be slightly tightened.

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—no output schema and a single parameter—the description does an above-average job of explaining what to expect: it lists the categories of returned data, warns about the OpenSea deployer nuance, and suggests concrete next actions. It does not specify the return structure or error behavior, but the provided context is sufficient for most selection and invocation scenarios.

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 covers the parameter fully with 'collection slug, name, OpenSea URL, or 0x contract address', and the description repeats this verbatim, adding no new semantic detail. Since schema coverage is 100%, the baseline is 3; the description does not elevate beyond that, though it does provide context around how to use the result.

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 it identifies 'WHO is behind an OpenSea collection / mint' and enumerates the concrete outputs: creator-owner wallet, payout wallets, contract, verification status, and socials. It positions itself as 'THE tool' for specific questions like 'who created this mint / can they rug and run', clearly differentiating it from siblings that focus on security, prices, or token data.

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 explicit use cases: 'who created this mint / can they rug and run / is this marketplace or launchpad launch legit / where does the money go'. It also instructs the agent to run complementary tools (address_security, deployer_check, wallet_nfts) on the returned wallets, effectively stating when those alternatives are appropriate as follow-ups.

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?

With no annotations, the description carries full burden. It explicitly states 'Read-only', describes the output values (safe_to_interact false/null/true), and lists the safety checks performed. This is thorough and goes beyond the 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 longer than the calibration high example but remains focused and front-loaded with the core question. Some redundancy exists between 'pre-payment / pre-interaction' and 'THE check before an agent sends funds...', but each sentence adds useful 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?

Given the simple schema, lack of annotations, and no output schema, the description provides sufficient context: input requirements, return semantics, use cases, and read-only nature. It is complete for an agent to decide when and how to use this tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds little beyond the schema: it reinforces '0x address' format (already in schema) and does not elaborate on chain values. The schema adequately documents both 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 clearly states what the tool does: it screens an address before payment or interaction, checking for scam/drain/sanction flags, known entity status, and on-chain track record. It distinguishes itself from siblings by positioning as the pre-payment/interaction check and specifying the safe_to_interact return value.

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 use cases: 'THE check before an agent sends funds to an address, pays an x402 endpoint, receives a transfer, or approves a contract.' It does not mention alternatives or exclusions, but the context is clear and actionable.

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?

With no annotations, the description carries full burden. It discloses keyless operation, the included data categories, and importantly interprets the hacks DB results ('A hit in the hacks DB is a real red flag; TVL is context, not a safety guarantee'). This adds valuable nuance beyond a dry API description, though it omits potential error/not-found 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 focused sentences with no redundancy. It front-loads the core purpose, then adds usage guidance and risk interpretation, each sentence earning 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 no output schema and no annotations, the description covers the main data returned, usage context, and risk interpretation. It could be more explicit about behavior when a protocol isn't found or response structure, but it is sufficient for a simple one-parameter lookup.

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 already covers the single parameter (name) with examples, so the baseline is 3. The description adds minor context by indicating it expects a named protocol, but not enough to elevate above 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?

The description clearly states it performs DeFi protocol due-diligence from DeFiLlama, listing specific data points (TVL, category, chains, and hacks database). It distinguishes from sibling security tools by focusing on named protocols and DeFiLlama data.

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 specifies when to use: 'Use for any DeFi protocol, dapp, or "is this project safe to use" question that names a protocol.' It does not explicitly mention alternatives or exclusions, but the context is 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?

No annotations are provided, so the description carries full burden. It details what the tool evaluates (number/recency of deployments, wallet age, scam/abuse reputation) and gives interpretation guidance (UNPROVEN vs red flag). It stops short of specifying return format or failure 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 description is longer than average but front-loaded with the core purpose and every sentence adds context (use case, interpretation, address sourcing). Emphasis via caps is slightly noisy but not wasteful.

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 tool with no output schema or annotations, the description provides enough context to select and invoke: purpose, use case, parameter provenance, and result interpretation. It doesn't describe exact output shape, but the described fields imply the report contents.

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 already documents both parameters (100% coverage), so baseline is 3. The description adds valuable semantics for the address parameter: it must be a 0x creator/deployer address and can be sourced from token_security's creator_address or the contract.

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?

Description clearly identifies the tool as due-diligence on a deployer wallet covering deployment history, wallet age, and reputation. It distinguishes from token-focused tools by targeting the wallet/deployer, though it does not explicitly contrast with the similarly-named deployer_reputation 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?

Explicitly frames when to use: 'THE key check for who is behind this project / is this team legit', especially on launchpad mints. It also instructs where to obtain the required address (token_security's creator_address or the contract). It lacks explicit exclusions or comparison to alternatives.

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?

No annotations are provided, so the description carries the full burden. It discloses the core behavior: it counts how many tokens the wallet launched and how many rugged or died, and flags serial ruggers. It does not mention data sources, output format, or limitations, but the disclosed behavior is substantive enough for a simple lookup tool.

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 somewhat verbose and includes an awkward typo ('fingers') and informal phrasing like 'the memory signal no live scanner has.' It communicates effectively but could be tightened. It is front-loaded with the core question, but the subsequent sentences could be more concise.

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 simplicity (one parameter, no output schema), the description covers the essential context: what it does, when to use it, and what input to provide. It implies the output includes launch counts and rugged/died status, which is sufficient for a user to understand the tool's value.

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 a clear description for the 'wallet' parameter ('the creator/deployer wallet address'), and the description adds 'Give the wallet address.' With 100% schema coverage, this is baseline 3. No additional format or chain details are provided.

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 function: tracking a wallet's history of token launches and whether they rugged or died. It clearly distinguishes from token-specific tools like rug_check by focusing on the deployer address, and uses a vivid question 'Has this WALLET rugged before?' to convey the purpose.

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 provides explicit guidance: 'Use when you have a token's creator/deployer address and want its history.' This clearly indicates the appropriate context. It also hints at a unique advantage (memory signal no live scanner has) but does not explicitly name alternatives or exclusions.

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?

With no annotations, the description carries the full burden, and it excels: it discloses the live data nature, the chains covered, the input modes (address+chain vs name), and the ambiguity-handling policy. It clearly implies a read-only query operation and gives specific behavioral expectations, going beyond what a simple 'get price' would state.

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 longer than average but every sentence earns its place: it front-loads the core purpose, then adds chains, sibling contrast, input usage, ambiguity policy, and use cases. There is no redundancy or fluff; the structure is logical and information-dense.

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?

Without an output schema, the description covers the return fields (price, change, volume, liquidity), the supported chains, the two input modes, and the edge case of ambiguous names. It is complete enough for an agent to select and invoke the tool correctly, even including a fallback instruction for handling ambiguity.

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 descriptions for both chain and query, but the description adds critical semantic guidance: instructs to provide a contract address WITH its chain for exact match, and to use a name to search all chains at once. It also explains what happens with ambiguous results, giving practical usage meaning beyond the schema.

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

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

The description clearly states the tool provides live price, 24h change, volume, and liquidity for any DEX token across many chains, including Solana and Robinhood Chain. It explicitly distinguishes itself from token_price by noting token_price only covers CoinGecko-listed coins and not Solana/Robinhood Chain, making the purpose unmistakable.

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 when to use this tool: for tokens CoinGecko does not list, DEX microcaps and memecoins, and non-Ethereum tokens. It also contrasts with token_price, names the alternative, and provides clear instructions for handling ambiguous results (ask for chain/contract rather than picking one). This is explicit when/when-not + alternative 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?

With no annotations, the description carries the full behavioral burden. It discloses the output is a 'FACT' and provides interpretive guidance for new domains (neutral signal), showing awareness of how results should be framed. It omits edge-case behavior (e.g., errors on invalid domains) but is sufficient for a read-only lookup.

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 sentences, tightly written, with no redundancy. It front-loads the core function ('Domain registration age via RDAP') then adds interpretive and usage guidance, all earning their 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 simple one-parameter tool with no output schema, the description adequately covers the return values (registration date, age, expiry, registrar) and usage context. It is complete for an agent to understand what to expect.

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

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

Schema coverage is 100% and already defines 'domain' as 'the domain or URL (e.g. runebrokers.com).' The description doesn't add parameter-specific detail beyond that, 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 explicitly states 'Domain registration age via RDAP' and lists exact data points (registration date, age in days, expiry, registrar). This clearly identifies the resource and differentiates it from sibling tools focused on tokens, NFTs, and stocks.

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 explicit usage context: 'Use it in PRE-LAUNCH due diligence and whenever a project points to a website.' It doesn't name alternative tools or exclusions, but the context is clear enough for an agent to decide when to invoke.

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?

With no annotations, the description carries the burden. It discloses the nature of the data returned (verified-source metadata), including whether the source is verified and proxy/implementation details. It does not mention potential failures or response format, but for a read-only lookup tool, this is adequate.

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 concise sentences. The first sentence front-loads the core purpose and data items; the second sentence provides the use case. 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?

Even without an output schema, the description lists the key return fields (actual name, verification status, compiler, proxy/implementation). It adequately covers the tool's purpose and use case. It could mention error/edge-case behavior (e.g., unverified source), but the stated metadata already includes verification status.

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 50%: the 'chain' parameter is well-described in schema, but 'address' is not. The description adds some meaning by stating the tool is for 'a contract,' implying the address must be a contract address. However, it doesn't elaborate on parameter formats or chain-specific behavior 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 it retrieves Etherscan verified-source metadata, listing specific data points (actual name, verification status, compiler, proxy/implementation). It also differentiates from siblings by framing the use case as confirming what an address is when onchain reads are insufficient.

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: 'Use this to confirm what an address really is when onchain reads alone can't label it.' This gives clear context. It does not name alternative tools or explicitly state when not to use, but the condition is sufficient for most scenarios.

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?

With no annotations, the description reveals that the index is curated and excludes spam copycats, that results are ranked, and that obscure collections may return nothing. It also explains the disambiguation behavior with the 'Normies' example. This goes beyond the operation to set expectations about result quality and failure mode.

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

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

Four sentences, each with a distinct role: purpose, output, behavior, usage/fallback. No filler or repetition; front-loaded with the most important 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 1-parameter read tool with no output schema, the description provides the necessary context: what it does, what it returns (contract, floor, holders, supply), when to use it, and how to handle no results. It is self-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?

Schema covers the query parameter as the collection name, but the description adds that the tool resolves the name to a contract, uses a curated index, and disambiguates similar-sounding names to the few that matter. This enriches the bare parameter definition with purpose and matching behavior.

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 the tool resolves a collection name to the correct contract via CoinGecko's curated NFT index, with a specific output. It clearly distinguishes from sibling NFT tools by positioning itself as the pre-pricing/judging name-resolution step.

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 tells the agent when to use it ('before pricing or judging a collection you only have a name for') and what to do if it fails ('if it returns nothing, the collection is obscure — fall back to web_search for the address'). This is clear guidance with a named alternative.

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

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

With no annotations, the description carries the full burden. It discloses a key behavioral nuance: movers are ranked among the 'most-traded pools,' not literally every token. It also instructs the agent to always state the 24h window and the universe, which is important behavior for cross-checking. However, it does not mention response format, pagination, or error behavior, so it is not fully transparent.

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

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

The description is front-loaded with purpose and is mostly dense with useful guidance. The final long sentence about CoinGecko is valuable but somewhat verbose and repetitive of the 'universe' point already made earlier, so it loses a point for 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?

Given there is no output schema and no annotations, the description does an excellent job explaining what to report (24h % and volume), the exact universe/window to caveat, the supported chains, and how to frame results to avoid cross-source contradictions. It is sufficiently complete for an agent to invoke and present results 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% for chain, limit, and direction, so the baseline is 3. The description reinforces the chain list and gainers/losers concept but does not add new parameter-specific semantics beyond the schema.

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

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

The description opens with a specific verb+resource: 'Scan and RANK a whole chain's most-traded tokens by 24h price move.' It clearly distinguishes the tool from single-token or stock-focused siblings by saying it is 'NOT about one named token' and is for the 'TOP/BIGGEST mover(s), gainers, losers.'

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

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

It explicitly states when to use: 'Use this whenever the question is about the TOP/BIGGEST mover(s), gainers, losers...' and provides an exclusion: 'NOT about one named token.' It also contrasts with CoinGecko's different universe, helping the agent avoid cross-source contradictions.

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?

With no annotations, the description discloses the paid data source, possible unavailability, and instructs the agent to state errors plainly and point to alternatives. It also describes what data is returned (floor path, high/low, net change, etc.) and the effect of compare_to. This goes beyond a simple read/write hint, though rate limits and output format aren't mentioned.

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

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

The description is dense but not wasteful. Each sentence adds relevant information: core function, single vs comparison behavior, expected inputs, and a caveat about data availability. It is slightly long but well structured with clear examples.

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 (optional comparison, multiple return metrics) and the absence of an output schema, the description is remarkably complete. It covers inputs, outputs, failure modes, and provides example queries. It doesn't specify exact output formatting, but that would be redundant without a schema.

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

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

The schema already covers all parameters (100% coverage), and the description adds value by explaining the semantic role of compare_to (time above the other floor) and emphasizing that collection names should be given. It also contextualizes 'days' as the window, which reinforces the schema description.

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 retrieves historical NFT floor prices from CoinGecko, for one or two collections, and distinguishes itself from siblings like 'nft_floor_price' by emphasizing 'Historical' and 'COMPARISON'. It uses specific verbs and describes what answers it provides.

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 concrete example questions the tool answers, clarifying when to use it (e.g., 'what was X's floor N hours/days ago', 'how much time has X floored above Y'). It also instructs to provide collection NAMES. However, it does not explicitly mention alternative tools for current floor or when not to use it.

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

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

With no annotations available, the description carries the full burden. It discloses live fetching from Alchemy (OpenSea + LooksRare) and staleness concerns, which covers the core behavioral trait. However, it does not mention potential failure modes, rate limits, or output format, leaving minor gaps in transparency.

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 sentences, front-loaded with purpose, and every clause serves a purpose—live data source, usage guidance, and address prerequisite. No filler or redundant 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 read-only tool with two parameters and no output schema, the description covers purpose, usage conditions, parameter prerequisite, and an alternative path. It is complete enough for an agent to select and invoke the tool 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%, but the description adds practical value beyond the schema by stating 'Needs the collection's CONTRACT ADDRESS' and suggesting find_collections as a fallback. This extra context helps agents correctly obtain the required 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 explicitly states 'LIVE floor price of an NFT collection' with a specific verb and resource, and distinguishes itself from siblings by emphasizing 'fetched right now from Alchemy' and contrasting with web search. It clearly conveys the tool's immediate-purpose scope.

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 provides explicit when-to-use guidance: 'Use this for any current/right now floor or price question' and explicit when-not-to-use: 'NEVER answer a live number from web search'. It also names an alternative tool (find_collections) for obtaining the required contract address, which is actionable context.

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?

With no annotations, the description carries the full transparency burden. It discloses what the tool returns (name, standard, total supply, holder count), what it explicitly does NOT return (floor price), and the reason (no marketplace API for such chains). This is strong, though it omits error handling or edge-case 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 description is efficient but slightly redundant, repeating the same limitation multiple times ('NO marketplace floor source', 'chain isn't on Alchemy/OpenSea', 'no NFT marketplace API exists'). Structured well with front-loaded purpose, but could be tightened without losing meaning.

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

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

Considering the tool's low complexity (2 params, no output schema) and no annotations, the description provides sufficient context: what it does, when to use it, what it returns, and prerequisites (contract address). It doesn't detail return format or errors, but for this simple tool it's nearly complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by emphasizing that contract_address is required (in caps) and clarifying that chain should be one without a marketplace floor source, especially Robinhood. This enriches the schema's descriptions, justifying 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 states the tool provides NFT collection info (name, standard, total supply, holder count) and explicitly distinguishes itself from nft_floor_price by noting it does NOT return a floor price. This makes the purpose specific and distinguishable from 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 explicitly says 'Use this when nft_floor_price can't help because the chain isn't on Alchemy/OpenSea' and names the alternative tool. It also states the tool does not return a floor price and emphasizes the need for a contract address, providing clear when-to-use and contextual 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?

With no annotations provided, the description carries the full burden and does well by disclosing data sources (GoPlus, DAS getAsset), detailed security checks, and chain-specific behavior. It doesn't explicitly state read-only semantics or output format, but the detailed audit list gives a strong picture of what the tool evaluates.

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 long but front-loaded with the core purpose and densely structured by chain. Although a bit lengthy, every clause adds meaningful detail about checks, usage, and fallbacks, and the organization makes it scannable.

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 no output schema, the description covers purpose, input, chain support, and fallbacks well. It does not explicitly describe the return value/format, but the enumerated safety checks and use-case statement give the agent enough context to know what to expect.

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

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

The schema already covers both parameters thoroughly (100% coverage), so the baseline is 3. The description adds value by clarifying how chain and contract_address interact per network (EVM vs Solana), how to obtain the address, and the fallback path—going beyond the schema without being redundant.

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 as a 'LIVE NFT COLLECTION safety/rug-risk' checker, listing concrete checks for EVM and Solana collections. It distinguishes itself from sibling tools like token_security or address_security by explicitly targeting NFT collection safety and even mentions using the collection address from resolve_entity/find_collections.

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

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

It explicitly states when to use it: 'Use for is this NFT collection safe / legit / a scam'. It also specifies required input (collection address), the correct chain parameter for Solana, and gives a clear fallback for unsupported chains ('for chains not covered (e.g. Robinhood) fall back to etherscan_lookup + onchain_lookup').

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?

No annotations are provided, so the description carries the burden. It discloses the key outputs (contract status, code size, balance, proxy info) and supported chains. However, it does not mention potential errors, response format, or any side effects (though none are expected for a read-only lookup). The description is adequate but not rich in behavioral context beyond the basic output list.

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 sentences, front-loaded with the tool's core purpose ('Basic onchain picture'), and every clause adds value. It lists the specific data points and supported chains without unnecessary fluff or repetition.

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

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

For a tool with only 2 parameters and no output schema, the description covers the essential usage and expected output fields. It does not describe the exact return structure, but the listed data points are sufficient for an agent to know what to expect. Minor gap: no mention of error behavior for invalid addresses or unsupported chains, but this is a low-complexity tool.

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

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

Schema description coverage is 100%, and the schema already documents both parameters (address and chain with enum-like list). The description adds minimal extra meaning beyond repeating 'Pass chain' and the chain list, with no new syntax, default, or constraint details. Baseline 3 is appropriate given the schema handles 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?

The description uses a specific verb ('lookup' implied by 'onchain picture') and clearly states the resource (address on EVM chains) and the exact data points returned (contract status, code size, native balance, EIP-1967 proxy). It distinguishes itself from siblings like address_security or etherscan_lookup by focusing on basic onchain attributes rather than security analysis or general explorer 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 provides clear context for when to use the tool (basic onchain picture) but does not explicitly mention when not to use it or name alternative tools. There is no exclusion criteria or comparison to siblings, so usage guidance is only implied rather than explicitly 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?

Since no annotations are provided, the description carries the full burden. It discloses behavioral nuances: for broad topics it returns 'EVERY open market it can find' rather than a top slice, and history=true includes resolved markets with final odds. It does not mention response size limits or error behavior, but for a read-only data tool, the disclosed behavior is adequate.

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 a single dense paragraph with each sentence serving a purpose: definition, use cases, history explanation, query guidance, and broad-topic behavior. It is slightly longer than strictly necessary but contains no filler; the admonitions and examples make it practical.

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 sufficiently explains what is returned (odds, volume, liquidity, resolution date, related markets) and addresses the trickiest case (broad topics returning all open markets). It does not cover pagination, rate limits, or error scenarios, but the tool is conceptually simple with only two optional parameters and the guidance is otherwise complete.

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

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

The input schema already has descriptions for both parameters (100% coverage), setting a baseline of 3. The description adds extra value by coaching usage: 'ALWAYS pass the subject the user named as query', examples of valid queries, and the specific condition for omitting query. This goes beyond the schema's static descriptions.

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 with a specific verb ('returns') and resource ('LIVE prediction-market data from Polymarket'), listing concrete outputs (implied odds, volume, liquidity, resolution date, related markets). It distinguishes itself from sibling tools (e.g., stock movers, security checks) by focusing solely on prediction markets.

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 explicit when-to-use guidance with example queries ('what are the odds of X'), explains when to set history=true for past/settled questions, and gives clear rules for the query parameter (always pass the subject, omit only when user asks generically). Includes a concrete example ('nba markets' -> query='NBA') and clarifies broad-topic behavior.

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?

With no annotations, the description carries the full behavioral burden. It discloses the returned data components, the pivot behavior for tokens younger than N days, and the ability to accept contract addresses and chain. It does not explicitly state read-only, but the query-like nature of the outputs implies it clearly enough.

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 sentences, each packed with distinct value: the return summary, the usage intent, and the token coverage and edge-case handling. It is front-loaded with the core phrase 'price MOVEMENT' and contains no filler.

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

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

Given the lack of annotations and output schema, the description must and does provide full context. It covers scope, use case, parameter meaning, return components, and the pivot behavior. It is sufficient for an agent to select and invoke this tool correctly without additional information.

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 covers 100% of the parameters, so the baseline is 3. The description adds meaning by clarifying that query can be a name/ticker or a contract address, and that chain pairs with the address. It also links the days parameter to the pivot behavior, providing context beyond schema defaults.

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 tool as providing recent price movement of a crypto token, listing specific outputs such as price path, high/low, net change, and sparkline. It explicitly distinguishes from siblings by stating 'movement OVER TIME, not just current price,' which differentiates it from token_price and similar 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 gives explicit when-to-use guidance: 'Use for how has X moved / dipped / done over the last N days' and emphasizes movement over time versus current price. It also covers edge cases like listed coins and DEX memecoins, but does not name specific alternative tools or provide explicit exclusions, 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?

With no annotations, the description carries the full burden and does well: it reveals the multi-source aggregation (DexScreener, GeckoTerminal, CoinGecko), specific liveness checks (stars, last push, archived), and interpretive guidance (strong vs thin profile). It does not disclose potential rate limits or failure modes, but the core behavior is transparent.

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

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

Three sentences efficiently deliver purpose, use cases, and input guidance. The first sentence is dense but packs necessary details (sources, liveness criteria). No wasted words, but the heavy parentheticals slightly reduce readability.

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

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

For a complex tool with no output schema, the description explains what it finds, how to interpret results, and how to structure inputs. It does not specify the return format (e.g., whether it returns URLs, scores), but it gives enough behavioral context to set expectations. Minor gap given no output schema.

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

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

The schema already describes both parameters fully (100% coverage), but the description adds critical semantic context: when to use contract+chain vs name, and that chain is needed for contracts. This goes beyond the schema's basic descriptions, enhancing the agent's ability to invoke correctly.

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 specific function: 'Find and VERIFY a project's WEBSITE, SOCIALS, and CODE REPOS' with concrete sources and liveness checks. It differentiates from siblings like domain_check or onchain_lookup by being the dedicated tool for project links and repo liveness, explicitly calling itself 'THE tool for...' that use case.

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

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

It gives explicit when-to-use guidance: 'THE tool for 'what is this project's website / socials / do they have real code / profile the team behind this token''. It also provides input format instructions ('Pass the CONTRACT (+ chain) for a memecoin/NFT, or the name for a listed coin'). However, it does not mention explicit alternatives or when not to use, slightly reducing the 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?

With no annotations, the description carries the full burden. It discloses important behavioral traits: returns is_pumpfun=false for non-pump.fun tokens, warns that pre-graduation tokens are thin and easy to manipulate, and explains what 'graduated' means. This goes beyond a simple status read and provides meaningful context for the agent.

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 well-structured and front-loaded with the core purpose, but it contains three sentences and some extra explanatory text. Every sentence adds value, but it is slightly longer than the most concise examples, so a 4 is warranted.

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 single-parameter lookup with no output schema, the description covers the main return values, the edge case for non-pump.fun tokens, and the risk context of pre-graduation tokens. It does not specify the exact response format or error handling, but it is fairly complete for the tool's complexity.

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 covers the single parameter 'mint' with a clear description ('the Solana token mint address'), and the tool description does not add further parameter-level detail. Baseline 3 is appropriate since schema description coverage is 100%.

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 it checks pump.fun graduation and bonding-curve status for a Solana token, listing key returned fields (graduated, bonding_curve_progress_pct, market cap, creator). It clearly distinguishes itself from sibling tools by being the dedicated check for pump.fun tokens, making its purpose unambiguous.

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

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

The description gives clear context: 'THE check for a pump.fun token' and 'Use for any pump.fun / fresh Solana memecoin question.' It implies when to use this tool but does not explicitly state when not to use it or name alternative tools, 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?

With no annotations, the description carries the full burden. It discloses that the tool is for view/pure functions (read-only) and gives examples, but does not describe error behavior, return format, or limitations (e.g., reverts, unsupported functions). Some transparency is present via 'view/pure' but more depth is expected.

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 sentences plus concise examples, front-loaded with the core action. Every sentence adds value, with 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 5 parameters, no output schema, and no annotations, the description is too thin. It lacks details on how to pass arguments, what the return value looks like (even though output types are given, the structure of returned data is not specified), and error handling. Significant gaps remain 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 only 40%, so the description must compensate. It clarifies function_signature and output_types via examples and notes the chain default, but does not explain the 'args' parameter, which is essential for functions with inputs. This partial compensation earns a mid score.

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 calls a view/pure function on any supported EVM chain, with specific examples (minter() -> address, totalSupply() -> uint256). This verb+resource+scope is unambiguous and distinct from sibling tools focused on security, tokens, or NFTs.

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 for reading contract state and provides the chain default ('Pass `chain` if not ethereum'), but does not explicitly state when to prefer this tool over alternatives or include exclusions. Usage context is present but not fully developed.

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?

With no annotations, the description carries the burden. It discloses that it runs crypto and on-chain routes in parallel, returns every real match at once, and clarifies that bare names in this context should be interpreted as crypto entities. However, it does not detail return format or potential errors, but the key behavioral traits are covered.

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

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

The description is dense but purposeful, with each sentence contributing to usage or interpretation. It is front-loaded with the 'FIRST STOP' positioning and examples. A minor typo ('fingers' users) slightly detracts, but the structure is effective.

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 no output schema, the description is quite complete: it covers question types, behavior, interpretation, and edge-case handling (launch date). It doesn't define the exact return structure, but the description's guidance on leading with traction match implies the return includes confidence/metadata.

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 already fully covers the query parameter with examples (name, ticker, address). The description reinforces this by mentioning bare proper nouns and address handling, but adds no new syntax or format details, so a baseline of 3 is appropriate given 100% schema coverage.

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

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

The description explicitly states it is the FIRST STOP for name/entity questions, lists specific example queries (what is X, when did X launch, is X a rug), and differentiates from siblings by emphasizing parallel multi-route resolution returning every match. This clearly distinguishes it from individual lookup tools like dex_token or nft_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?

Provides explicit when-to-use guidance: 'FIRST STOP' for entity questions, 'Call this BEFORE concluding from web search alone', and gives direction on how to use results (lead with traction match, add non-crypto namesakes from web_search as secondary). Also gives specific handling for launch date queries.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals a critical behavioral trait: any 'official Robinhood Chain token/airdrop/claim' is automatically a scam because no such token exists. This is valuable context beyond what the schema provides. However, it does not describe the output format or any caveats about domain checking methods, so it's not a 5.

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

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

The description is reasonably concise, front-loaded with the main purpose, and the key fact is appropriately emphasized. The final instruction 'Give a domain/URL or a claim/phrase' is somewhat redundant with the schema, but overall the text is efficient and well-structured.

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 no output schema, the description is quite complete. It explains the two types of input, provides concrete use cases, and states the critical rule about token scams. It could mention what the response looks like, but the tool's simplicity and clear purpose make this 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?

The schema already describes the single parameter 'query' as 'a domain/URL, or a claim/phrase to check' at 100% coverage. The description repeats this instruction and adds example phrases, which is helpful but not a significant semantic extension beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states it is a 'Real-vs-FAKE checker for Robinhood Chain' with two explicit functions: verifying domains against official explorer/docs and validating token/airdrop/claim authenticity. It provides concrete example queries ('is <site> the real Robinhood explorer', 'is the Robinhood airdrop real') that distinguish it from sibling tools like robinhood_clones or robinhood_token_safety.

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 for' followed by three example queries, giving clear context for when to invoke the tool. It does not mention when NOT to use or name alternative tools, but the examples make the intended usage unambiguous. The key fact about no official token helps avoid misuse.

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?

With no annotations, the description carries the full burden. It discloses what the tool does in detail: returns every token with that symbol, liquidity-ranked, flags the dominant/likely-real one, and for addresses tells rank. It clearly implies a read-only lookup with no side effects. It doesn't cover rate limits or error conditions, but for a simple lookup this is sufficient.

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 sentences and front-loaded with the core purpose. It includes a concrete example ('19 tokens named GP') and explains the problem, which is useful context. Slightly verbose with the 'runner problem' explanation, but every part contributes to understanding.

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 simple 1-parameter tool with no output schema, the description covers input, output behavior, and use case well. It doesn't specify the exact return format (e.g., JSON structure or field names), but it does explain key output features like liquidity ranking and flagging, which is adequate for an agent to invoke and interpret results.

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 describes the single parameter ('query') as a token symbol or address, providing 100% coverage. The description adds valuable context on how the parameter is used and what behavior changes when an address is passed versus a symbol, enhancing the schema's meaning.

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

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

The description uses a specific verb ('Find') with a clear resource ('COPYCAT tokens on Robinhood Chain') and explains the underlying problem. It clearly differentiates from sibling tools like robinhood_authenticity or token_security by focusing on clones/imposters sharing a name/symbol.

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 use case: 'Use for is this the real X on Robinhood / are there fakes'. It also states inputs ('Give a symbol or a 0x address'). It doesn't explicitly mention when not to use it or name alternatives, which keeps it from 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?

With no annotations, the description carries the transparency burden. It discloses that data is 'LIVE', explains that 'new' tokens are 'just-launched, earliest + riskiest', and mentions the token address allows chaining to robinhood_token_safety. It does not cover rate limits or return format but provides meaningful behavioral 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?

The description is only two sentences, front-loaded with the core purpose ('LIVE Robinhood-chain token discovery'). Every sentence contributes value: the first defines the tool, the second details kinds and usage. 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 simple two-parameter tool with no output schema, the description is largely complete. It covers what the tool does, the kind values, and a use case. It mentions that results carry the token's 0x address, giving a hint of output structure, but does not fully describe the 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 schema already covers all parameters (100% coverage), but the description adds meaning beyond the schema by explaining what each kind means, especially the riskiness of 'new' and the volume-based definition of 'gainers/top'. This goes beyond the schema's minimal description.

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: 'LIVE Robinhood-chain token discovery -- what's moving on Robinhood right now.' It lists the specific kinds (trending, new, gainers/top) and distinguishes itself from siblings by focusing on Robinhood chain 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?

Provides explicit use cases: 'Use for 'what's pumping / new / trending on Robinhood', 'top Robinhood coins right now'.' This gives clear context for when to use the tool, though it does not explicitly mention alternatives or when not to use it.

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

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

With no annotation provided, the description carries the full burden. It lists the on-chain signals it checks and mentions Blockscout as a data source, which gives useful insight. However, it does not explicitly state it is read-only, nor does it mention any potential side effects, 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?

Three sentences cover purpose, context, and usage. The description is information-dense without padding, though it could be slightly shorter without losing value.

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 there's no output schema, the description compensates by enumerating the returned signals (VERIFIED status, ERC type, holder count, creator, activity, scam flag). It also provides chain context and an example usage. Missing details like error conditions are minor given the tool's simplicity.

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 schema already documents both parameters. The description adds only 'Give a 0x collection address' which reinforces the existing schema but doesn't add substantial new meaning. The chain default is already in 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 it is a safety check for a ROBINHOOD-CHAIN NFT collection, with a specific verb ('check') and resource. It enumerates the exact signals checked (source VERIFIED, ERC standard, holder count, creator, on-chain activity, scam flag), and distinguishes itself by noting OpenSea's trust signals don't cover Robinhood.

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 to use this for legitimacy/rug checks on Robinhood/Anvil NFT collections, and notes it is 'the only read' because OpenSea doesn't cover this chain. It doesn't explicitly mention alternatives for non-Robinhood chains, but the context is clear enough.

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?

With no annotations, the description carries full burden. It transparently describes the operation: 'derives the bound account on-chain and lists + prices its holdings.' However, it doesn't explicitly state read-only nature or edge cases like non-ERC-6551 NFTs, minor gaps for a valuation tool.

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 the core purpose front-loaded in the first sentence, followed by context and usage. Each sentence adds value, but the ALL-CAPS emphasis and the aside 'which nobody else surfaces' make it slightly longer than necessary.

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 complex tool with no output schema, the description covers what it does, why it's unique, and when to use it, including the on-chain derivation mechanism. It lacks explicit return-format or total-value statement, but 'lists + prices its holdings' reasonably implies the output.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that collection is the NFT collection address and token_id identifies the NFT, and it clarifies the chain context (Robinhood) which informs the default chain parameter. This adds process insight 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?

Clearly states it values the assets held inside a Robinhood-chain NFT (ERC-6551 token-bound account), using a specific verb and resource. The description distinguishes it from siblings by noting 'which nobody else surfaces' and provides concrete intended uses.

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 explicit use-case scenarios in quotes: 'what's inside this Robinhood NFT / what is this broker worth / does this NFT hold stock tokens.' While it doesn't list alternatives or exclusions, the differentiation from floor-price tools is implied through 'floor PLUS its contents -- which nobody else surfaces.'

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the exact data sources (GoPlus, Blockscout, DEX), specific checks performed (honeypot, tax, blacklist, pausable, mintable, holder concentration, liquidity), and an output trait ('Every flag names its source'). This is a thorough and honest account of behavior, superior to most tool descriptions.

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

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

The description is dense but well-structured, leading with the main purpose and then detailing sources and checks. Every sentence provides useful information, though it is somewhat long. It avoids fluff while packing essential details, deserving a 4.

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 no output schema, so the description must hint at return values. It mentions 'Every flag names its source' and lists the verdict types (honeypot, rug, safe to buy). For a moderately complex tool with three data sources, this provides enough context for an agent to understand what it will receive, though a formal output structure is not described. The completeness is good but not perfect.

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 baseline is 3. The description adds marginal value by emphasizing the address is on Robinhood Chain and that the scan is by 0x address, but it does not add syntax or format details beyond the schema. The schema already documents both parameters adequately.

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 performs a 'Full safety scan' for a Robinhood-chain token by address, listing specific checks from three sources. It distinguishes itself from sibling tool token_security by claiming to be more complete for Robinhood tokens. This meets the criteria of a specific verb+resource+scope with sibling differentiation.

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

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

The description explicitly positions this as 'THE tool for is this Robinhood coin a honeypot / rug / safe to buy' and states it is 'More complete than token_security alone for Robinhood tokens.' This gives clear context on when to use it, but it does not explicitly mention when not to use it or name alternatives beyond token_security. Thus it earns a 4 for clear context without exclusions.

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?

With no annotations provided, the description carries the full burden and excels. It discloses what the tool inspects (team, payout wallet, mint proceeds, contract safety), how it weighs facts (flagged wallet as red flag, fresh wallet as neutral), and the range of input formats accepted. It sets expectations for the analytical nature and honesty of results.

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

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

The description is dense but every sentence adds value—the first sentence summarizes the core action, the second lists checks, the third explains evaluation philosophy, and the fourth enumerates inputs. Slightly verbose with the emphatic 'THE tool' phrasing, but still efficient and well-structured with the most important info 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?

Given the tool's complexity (multi-faceted risk assessment) and no output schema, the description covers the 'what' and 'how' well. It lacks an explicit description of the return value (e.g., risk score vs. report), which would be helpful, but the inputs and process are sufficiently documented for an agent to invoke correctly.

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

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

The single parameter 'collection' has 100% schema coverage, and the description merely repeats the three accepted formats. No additional semantics beyond the schema. Baseline 3 is appropriate since the schema already documents the parameter fully.

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 uses a specific action ('One-call... scorecard') and a clear resource ('NFT mint / collection'). It enumerates concrete activities (resolves team, vets wallet, follows proceeds, checks contract) and explicitly positions itself as 'THE tool' for rug/launchpad safety, distinguishing it from generic lookup 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?

Strongly implies when to use it ('THE tool for... is this mint a scam'), and lists acceptable inputs (slug, URL, contract address). It does not explicitly name alternative tools or when-not-to-use, but the 'one-call' framing and 'THE tool' language make the intended use case unmistakable.

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?

With no annotations provided, the description carries the full burden. It discloses critical behavioral nuances: the score is inverted (1 = clean, higher = riskier), authority == revoked is SAFE, and interpretation of insider % varies with token age/holder count. While it doesn't explicitly state read-only semantics or rate limits, the nature of an analysis tool is implied, and the interpretive details are highly valuable.

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 somewhat lengthy but information-dense, covering purpose, features, usage, and interpretation. It is front-loaded with the primary purpose, though the all-caps and dash-heavy structure could be slightly streamlined. Every sentence contributes meaningful details, so it 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?

There is no output schema, so the description must explain return values; it lists risk flags, LP lock %, mint/freeze authority, top-holder concentration, rugged flag, and insider metrics with field names. It also provides guidance on interpreting results and cross-referencing with token_security, making it well-rounded for a single-parameter tool.

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

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

The input schema already provides a clear description for the single 'mint' parameter ('the Solana token mint address'). The description reiterates 'Needs the token MINT address' and adds the Solana-specific context, but this adds minimal value beyond the schema. With 100% schema coverage, a 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 clearly states it performs Solana rug analysis from RugCheck.xyz, listing specific outputs like risk flags, LP lock %, authority status, and insider/bundle detection. It distinguishes itself from siblings by explicitly mentioning cross-checking with token_security and noting its Solana-native focus, while sibling names like rug_check and token_security exist.

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 for any SOLANA token safety / is it bundled / is it a rug question' and directs to use it ALONGSIDE token_security as a second source for cross-check. It also clearly states the required input (token mint address), making when-to-use guidance unambiguous.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context: 'keyless' (no auth needed), 'official primary source' (credibility), and enumerates the exact filing types included. It does not discuss pagination, rate limits, or return formatting, but for a read-only data retrieval tool this is reasonable coverage.

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 packs substantial information into a single well-structured sentence. The colon-list format makes the filing types scannable, and every clause serves a purpose: scope, content, usage context, and constraints. 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 tool with a single parameter and no output schema, the description is remarkably complete. It covers what data is provided, the source authority, use case, related tools, and limitations (US-listed only, requires ticker). An agent would understand exactly what to expect and when to invoke 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% at the parameter level (ticker is fully described). The description adds an extra constraint—'US-listed companies only'—which clarifies valid ticker values beyond the schema's generic examples. This adds meaningful semantic context.

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 provides SEC EDGAR filings for a US-listed stock, enumerating specific form types (10-K, 10-Q, 8-K, S-1, proxy, Form-4). This distinguishes it from price-focused siblings like stock_quote and stock_safety, making its unique purpose explicit.

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 to use it 'for deeper due diligence on a stock beyond price' and 'ALONGSIDE stock_quote/stock_safety', giving clear when-to-use guidance. It also notes the 'US-listed companies only' limitation and the need for a ticker, effectively guiding tool selection.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses the LIVE nature, US session scope, and data source (Financial Modeling Prep), which is useful. However, it does not mention the response format, rate limits, or explicitly confirm the operation is read-only.

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 concise, information-dense sentences: function, use cases, and sibling distinction. No redundant phrases 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?

The tool is simple and parameters are fully documented, but there is no output schema. The description does not state what fields the returned movers contain (e.g., symbol, price, change), which is a notable gap for an AI agent deciding if this tool answers a query.

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 descriptions for limit and direction. The description repeats the direction categories (gainers, losers, actives) but adds no additional semantic detail beyond what the schema already provides, so 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 specifies the tool's function: fetching top stock movers with specific categories (gainers, losers, actives). It explicitly contrasts with market_movers as the 'stock analogue', effectively distinguishing it from sibling tools.

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

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

Gives explicit use cases: 'Use for top movers / top gainers / biggest losers / most active stocks today'. Also references market_movers as the alternative, providing clear when-to-use context.

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?

With no annotations provided, the description carries the full burden of disclosing behavior. It states the data source (Financial Modeling Prep), that it's LIVE, and lists returned fields (price, % change, market cap, exchange, day + 52-week range, volume). It lacks details on error handling or rate limits, but covers the core behavioral expectations.

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

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

The description is information-dense but every sentence contributes: function, data fields, usage context, and differentiation. It is well-structured and front-loaded with the core purpose, with no redundancy.

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

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

For a single-parameter tool with no output schema, the description is complete: it covers the query format, data returned, and scope (US stocks). Users have enough information to select and invoke the tool correctly without additional context.

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

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

The input schema already has 100% coverage with a description for 'query', so baseline is 3. The description adds value by providing concrete examples ('AAPL' or 'Apple') and clarifying that company names are valid inputs, which enriches the schema's basic description.

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

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

The description clearly states the tool's function with a specific verb ('LIVE US stock/equity quote') and resource ('stock/equity from Financial Modeling Prep'). It enumerates the data fields returned and distinguishes itself from sibling tools by explicitly positioning as the stocks equivalent of token_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?

The description provides explicit when-to-use guidance ('Use for any public-company / stock / ticker price question') and an exclusion ('NOT for crypto tokens'). It also names an alternative tool (token_price) as the equivalent for crypto, giving clear usage boundaries.

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?

No annotations are provided, so the description carries the full burden. It discloses the data source (Financial Modeling Prep), the specific scoring thresholds (Altman-Z <1.8 distress, >3 safe; Piotroski 0-9), and risk flags (OTC/pink-sheet, penny-stock, micro-cap). It does not mention auth requirements or return structure, but for a read-only data lookup the key behavioral traits are well covered.

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

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

The description is front-loaded with the purpose, then provides detailed metric explanations with thresholds, followed by explicit usage guidance and input type. Every sentence contributes meaningful information without filler, achieving a good balance between detail and brevity.

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 compensates by enumerating the metrics and their interpretations (e.g., Altman-Z ranges, Piotroski range). It doesn't describe the response structure (e.g., JSON keys), but for a simple one-parameter lookup tool, it provides enough context for an agent to understand what information will be returned and how to use 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?

The schema already describes the query parameter as 'a ticker symbol or company name' with 100% coverage. The description merely restates this as 'Takes a ticker or company name.' No additional semantic nuance (e.g., case sensitivity, format, examples) is added, so the baseline score of 3 applies.

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

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

The description clearly states the tool provides a 'Stock RISK/safety profile' and enumerates specific metrics (actively trading vs delisted, exchange, penny-stock flags, Altman-Z, Piotroski). It explicitly positions itself as 'the stock analogue of token_security', which distinguishes it from sibling stock tools like stock_quote and stock_movers.

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 'Use for ... questions' with concrete examples like 'is this stock safe / legit / going to zero / a pump-and-dump', and names token_security as an analogue. However, it does not explicitly state when not to use it (e.g., for price quotes or market movers), so the guidance is clear but not exhaustive.

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?

With no annotations provided, the description carries the full burden. It discloses the underlying methodology (comparing deepest Robinhood-chain pool price to real stock price) and defines the interpretation of results (~1:1 peg = likely official, de-pegged = warning, copycat = memecoin). This is rich behavioral context, though it omits output format and edge 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 three sentences, front-loaded with the core question. It includes some rhetorical emphasis ('THE tool', 'Robinhood's unique lane') that adds personality but also slight redundancy. Overall, every sentence contributes meaning without excessive wordiness.

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 moderate complexity (single ticker input) and lack of output schema, the description covers the core logic and scenarios well. However, it does not describe the return format or how the agent should interpret the tool's response, leaving a gap for integration.

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 'ticker' is fully documented in the schema with a description and examples. The tool description adds no additional parameter semantics beyond what schema already provides, so the baseline 3 is appropriate.

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

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

The description uses a specific verb 'Verify' and clearly identifies the resource: a TOKENIZED STOCK on ROBINHOOD CHAIN. It distinguishes three possible outcomes (tracking, de-pegged, copycat), making the tool's function unambiguous and distinct from siblings like robinhood_authenticity or token_security.

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 positions itself as 'THE tool' for questions about whether a Robinhood tokenized stock is real/tracking/fake, which is strong when-to-use guidance. It also narrows scope with 'Robinhood's unique lane,' but does not explicitly name alternative tools or state when not to use it, 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?

No annotations are provided, so the description carries the burden. It discloses a side effect ('records the fresh reading') and its comparative approach, but does not elaborate on persistence, reversibility, or required permissions. This is partial transparency.

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 sentences and front-loaded with the core question. Some redundancy exists between 'Did this token survive or RUG?' and 'Answers 'did it rug / is it dead / can I still sell'', but overall it is compact and readable.

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 or annotations, the description provides the essential context: what the tool does, when it's most useful, and what questions it answers. However, it does not specify the exact return format or the operational implications of 'recording,' leaving some 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% for both parameters. The description's instruction 'Give a contract/mint address' reinforces the 'address' parameter but adds no meaningful detail beyond the schema. The chain hint is also not elaborated.

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

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

The description clearly states the tool's function with specific verbs ('Re-reads live liquidity/volume and compares...', 'records the fresh reading') and the resource (token outcome). It distinguishes itself from sibling tools like rug_check or token_security by focusing on survival based on historical comparison, making its purpose unambiguous.

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

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

The description provides contextual guidance: 'Works on any chain incl. Solana + Robinhood' and 'most powerful on a token fingers has history on.' This implies when the tool is most useful (when historical data exists) but does not explicitly exclude alternatives or name when-not-to-use.

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?

With no annotations provided, the description carries the full burden. It discloses the data source (CoinGecko), the live nature of the data, and lists the exact fields returned. It does not mention failure modes or rate limits, but for a simple read-only lookup, the behavioral transparency is adequate and not misleading.

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 sentences, front-loaded with the core purpose and return data. The second sentence quickly gives usage guidance and input format. Every word contributes, with no fluff or repetition.

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

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

For a one-parameter tool with no output schema, the description is complete: it states the tool's function, the type of data returned, when to use it, and what to pass. It provides enough context for correct invocation without requiring additional documentation.

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 'query' parameter with a clear description and examples, giving 100% schema coverage. The description repeats the instruction to provide name or ticker and adds a 'not an NFT' qualification, which is more about tool scope than parameter format. Thus it 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 it fetches a live price and market snapshot for a crypto token/coin, explicitly excluding NFTs, and enumerates specific data points (USD price, 24h/7d change, market cap, 24h volume, all-time high). This verb+resource+scope structure distinguishes it from sibling tools like NFT floor price or stock quote.

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 explicit usage guidance: 'Use for any current price / what's X worth question' and 'to give live data on a coin someone is weighing.' It does not explicitly mention alternatives or when-not-to-use, but the context clearly positions it for real-time token pricing, which is sufficient for most AI agents.

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?

With no annotations, the description carries full weight. It discloses the data points returned (honeypot, taxes, LP lock, etc.), the chain coverage, and special Solana handling (mint/freeze authority, transfer-hook). It implies a read-only profile operation but does not mention rate limits, authentication, or failure modes.

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 four sentences, densely packed with relevant lists and details. Each sentence serves a purpose: defining the output, covering Solana specifics, stating the use case, and providing input source guidance. It is slightly long but not verbose.

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 complex security tool with no output schema, the description is remarkably complete. It covers purpose, input requirements, chain support, and essentially documents the return content through the list of risk factors. An agent has sufficient context to select and invoke the tool 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%, so the baseline is 3, but the description adds meaningful context: it explains how to use chain=solana with a base58 mint and describes additional Solana-specific fields. It also tells agents where to obtain the contract address, which is not in 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 it provides a 'LIVE token SAFETY/rug-risk profile from GoPlus for a fungible token', enumerating many specific checks. It distinguishes itself by explicitly covering EVM ERC-20s and Solana SPL tokens, which differentiates it from NFT-focused or other security 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 explicitly says 'Use for any "is this token safe / a scam / a rug" question' and explains that the token's contract/mint address is needed, mentioning sources like token_price, dex_token, or web_search. However, it does not name alternative tools for non-fungible assets or provide exclusion scenarios.

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?

With no annotations provided, the description fully discloses the tool's behavior: read-only, simulates, never executes. It details what is checked (assets leaving/entering, approvals with unlimited allowances and flagged spenders, reverts), adding significant behavioral context beyond any structured fields.

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

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

The description is somewhat lengthy but information-dense. It opens with a strong imperative and structured flow (what, why, safety, inputs). Some redundancy exists ('THE check at the moment of signing' repeats earlier points), but each sentence contributes meaning.

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

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

No output schema exists, so the description must explain return behavior. It does so thoroughly: what assets leave/enter, what approvals are granted and to whom, whether it reverts. It also covers the read-only safety aspect, making the tool fully understandable for correct 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?

Schema covers all 5 parameters, so baseline is 3. The description adds value by grouping parameters in a usage hint ('Give the tx: to, data, value, from_address') and emphasizing from_address for accuracy. This reinforces schema meaning without replacing it.

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 simulates a transaction before signing, showing fund movements, approvals, and revert status. It distinguishes itself from sibling security tools by focusing on transaction-level simulation rather than address or token checks.

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 frames the usage context: 'THE check at the moment of signing' to catch drains and approval scams. It also provides direct input instructions ('Give the tx: to, data, value, from_address'). While it doesn't mention alternatives, the purpose and timing are 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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces this with 'This tool is read-only: it never moves funds, needs keys, or signs anything.' More importantly, it adds behavioral depth beyond annotations: it describes the research sources (web, on-chain reads, verified contract source, live market data), explains the recommended_action enum in detail, and provides an example result with a headline and confidence score.

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 lengthy but every sentence earns its place: the core purpose is front-loaded, followed by trigger scenarios, research sources, output semantics, example, and safety note. The structure is clear and easy to scan despite the density, with 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?

For a tool with nested objects, multiple parameters, and an output schema, the description is remarkably complete. It fully explains the recommended_action branching, provides a concrete example result, and clarifies the read-only behavior. Combined with the rich schema and annotations, an agent has enough information to select and invoke this tool correctly in a variety of situations.

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

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

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not add parameter-level meaning beyond the schema (e.g., it does not clarify 'fresh', 'context', 'category', or 'max_wait_s'), though the sample question ('is 0x... a honeypot?') and example output indirectly illustrate typical usage.

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

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

The description opens with 'Verify what is actually TRUE about something before you act on it', giving a specific verb and a clear scope (anything you might act on). It also lists concrete examples (sign a transaction, approve allowance, send funds, etc.) and positions itself as a pre-action safety gate, distinguishing it from the many specialized sibling tools like token_security or rug_check.

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 'CALL THIS BEFORE you:' followed by a detailed list of risky actions, providing strong when-to-use guidance. It also explains what to do based on the recommended_action field ('anything other than proceed means do not act yet'). However, it does not name alternative tools or explicitly say when to use a specialized sibling instead, so it lacks explicit exclusions.

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?

No annotations are provided, so the description carries the full burden. It discloses operational scope (native ETH + internal txs + ERC-20), the need for a 0x address, default chain, and behavioral interpretation (holding funds vs dragging them to a fresh wallet). It does not explicitly mention read-only or safety, but the context implies a non-mutating lookup, which is acceptable.

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 a single well-structured paragraph that front-loads the primary purpose in caps, provides examples, and ends with requirements. Every sentence adds value; no filler or redundancy. The structure (purpose, use cases, heuristics, requirements) is clear and scannable.

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 no output schema, the description compensates by explaining what the return data represents (balance, top addresses, types of transfers). It fully addresses the tool's complexity, includes default behavior for chain, and gives practical guidance for the major use case (rug detection). Complete for an agent to invoke correctly.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds context by explaining the purpose of the address (trace a payout wallet) and the chain parameter (default ethereum and list of supported chains), reinforcing the schema's semantics and linking them to real use cases.

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 uses a strong verb phrase 'FOLLOW THE MONEY' and specifically states it returns a wallet's balance and top withdrawal/funding addresses, clearly distinguishing it from sibling tools like wallet_nfts or token_security. It explicitly names the use case ('where did the mint/sale proceeds go') and differentiates from other wallet tools by focusing on fund movement.

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 explicit guidance on when to use: tracing payout wallets, checking if a wallet drained project funds, and following the next hop. It also gives a classic rug-pull heuristic ('swept proceeds to a fresh wallet and went quiet') and states requirements ('Needs a 0x address; pass the collection's chain'). This is more than enough to guide 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?

With no annotations, the description carries the full burden. It discloses the multi-chain scope, the types of NFT data (holds/minted/collected), and activity assessment. It also warns about the ETH balance trap. However, it does not describe the return format, pagination, or rate limits, which would improve transparency.

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

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

The description is front-loaded with the core purpose, then positions the tool as primary, and includes a critical usage warning. It is slightly verbose with the 'CRITICAL:' emphasis but every sentence provides value, and the multi-chain note is concise. Not overly long for the context it provides.

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 single-parameter tool with no output schema, the description covers scope, use cases, and a key trap. It does not specify the exact return structure (e.g., list of NFTs vs summary stats), but the agent gains enough context to invoke correctly. The description compensates well for the absence of annotations.

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 covers the single 'address' parameter with a description already stating '0x wallet address to look up'. The description repeats the need for a 0x address but adds no new details like ENS support, checksum format, or behavior for invalid addresses. Since schema coverage is 100%, baseline 3 is appropriate.

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

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

The description clearly states the tool returns what NFTs a wallet holds, minted, or collected across specific OpenSea chains, and activity level. It explicitly positions itself as 'THE tool' for wallet-level NFT queries, distinguishing it from siblings like wallet_funds which presumably handles ETH balances.

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 explicit when-to-use guidance: 'what is this wallet / is it active / what does it hold or mint / show me this OpenSea wallet'. Includes a critical warning to call before declaring a wallet empty, contrasting with ETH balance checks. It also states multi-chain capability as an advantage.

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