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 adds value beyond annotations by disclosing return fields, the ERC20 nature of the tokens, and pointing to baseSwap for trades. It doesn't mention pagination details but provides useful 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?

Three sentences, front-loaded with the core purpose, then return values, then usage and alternative tool. Every sentence adds distinct information with no redundancy. Highly concise and effectively 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 read-only search tool with rich annotations, the description covers the main capabilities (find, search, sort, return metrics) and the alternative swap tool. It lacks explanation for some parameters (includeUser/includeMarket) and pagination, but overall it provides enough context for an agent to understand what the tool does and when 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?

Schema description coverage is 0%, so the description must compensate. It explains the 'q' parameter (search by name/symbol) and 'sortBy' (market-cap or created-at), but doesn't clarify 'limit', 'offset', 'includeUser', 'includeMarket', or 'chainId'. While the enum for 'sortBy' is self-evident, several parameters remain unexplained, leaving a significant gap.

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 'Find meme tokens on Base via Clanker' and specifies the return fields (price, market cap, 24h volume, price changes). It distinguishes from siblings like hederaFindMemeCoins (different chain) and baseSwapQuote by explicitly noting that for buying/selling, one should use baseSwap.

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

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

Explicitly says to use baseSwap for buy/sell, naming the alternative tool. Also provides usage instructions: 'Use q param to search by name/symbol' and 'Sort by market-cap or created-at.' This gives clear context on when and how to use the tool versus 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the key behavioral insight that 'balance' provides exact units while 'humanReadableBalance' is rounded for display, which is valuable guidance for interpreting tool output.

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 long, with the primary purpose front-loaded and the critical usage note provided immediately after. Every sentence adds value, with no redundant 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 balance-checking tool with no parameters, strong safety annotations, and no output schema, the description is complete. It includes the essential guidance about which balance field to use for trades, making it fully actionable.

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

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

The tool has zero parameters, so the schema coverage is effectively 100%. The description does not need to explain parameters; the baseline for zero-parameter tools is 4, and the description meets this by focusing on output guidance.

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: 'Get wallet balances on Base.' This specifies the verb (get), the resource (wallet balances), and the scope (Base chain), distinguishing it from sibling tools like bscGetBalances and ethGetBalances.

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

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

The description implies when to use the tool (for Base balances) and includes a critical note about using 'balance' for trades instead of 'humanReadableBalance'. It does not explicitly mention alternatives, but the chain-specific scope is clear from the description and sibling 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?

Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adding 'Get current USD price and swap quote' confirms it is a read-only query. It also warns about volatility, which aligns with the openWorldHint. No contradictions found.

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

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

Two sentences: first states purpose, second provides a critical usage note and a concrete address hint. Every sentence is essential, no fluff. Front-loaded with the core action.

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 (3 parameters, no output schema, clear annotations), the description is sufficient. It explains what is returned (USD price and swap quote) and gives a key pointer for native ETH. Missing structural info about quote format but not critical for selection.

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 all parameters. The description adds value by specifying 'Use 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE for native ETH,' which clarifies the token address for ETH, a common special case. This exceeds the baseline of 3.

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

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

Clearly states 'Get current USD price and swap quote for Base tokens.' It specifies the action (get), the resource (swap quote and price), and the blockchain (Base). This distinguishes it from sibling swap quote tools for other chains like ethSwapQuote or bscSwapQuote.

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 includes a strong usage guideline: 'ALWAYS fetch fresh prices - crypto is volatile.' This tells the agent to always request a new quote rather than caching. It also provides the address for native ETH, which is a practical hint. However, it does not explicitly state when not to use this tool or name 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?

Annotations already declare readOnlyHint:true, destructiveHint:false, idempotentHint:true, and openWorldHint:true. The description adds value by specifying which chains are supported and which are not, providing additional behavioral context beyond the annotations. No contradiction exists.

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

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

The description is two sentences: the first states the core purpose, and the second lists supported chains with a critical exclusion and alternative. No unnecessary words 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 simple read-only tool with 2 parameters (100% schema coverage), clear annotations, and no output schema, the description adequately covers purpose, chain support, and exclusion. No additional information is needed for an agent to correctly select and invoke the 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% (both 'chain' and 'address' are described). The description adds extra context by listing supported chains explicitly and noting the Hedera exclusion with an alternative, which supplements the schema's enum and default value.

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 'detailed trade data for a specific token from Birdeye' and lists all supported chains, explicitly distinguishing from the sibling tool for Hedera by saying 'NOT supported: Hedera (use hederaTokensSwapQuote instead)'. This provides a specific verb+resource and differentiates from alternatives.

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 lists supported chains and provides an alternative tool for the unsupported Hedera chain, giving clear guidance on when to use this tool and when to use a sibling instead.

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, destructiveHint, and idempotentHint, so the safety profile is clear. The description adds that the data is real-time, which is useful but does not disclose additional behavioral traits beyond annotations.

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

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

The description is a single concise sentence with no fluff. It is front-loaded with the key action. However, it could be slightly more structured by separating purpose from features.

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?

Although the description covers the high-level purpose, there is no output schema and the description does not explain the return format or what fields the agent can expect. Given the number of parameters and the lack of output schema, this is insufficient.

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

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

Schema coverage is 100% with each parameter having a description. The description does not add any new meaning beyond what the schema 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 states the tool retrieves trending tokens from Birdeye with real-time price and market data, and supports multiple chains and sorting. It uses a specific verb and resource, distinguishing it from siblings like birdeyeTradeData.

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 fetching trending tokens but does not explicitly state when to use this tool versus alternatives like getTrendingCoins. No when-not or exclusion criteria are provided.

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

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

Annotations already declare read-only, non-destructive, idempotent behavior. The description adds valuable context about result units (market cap in BNB, price in USD), which is not available elsewhere. This supplements the annotations well.

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

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

The description is extremely concise—two short sentences—and every word adds value. No repetition or fluff.

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

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

Given 7 optional parameters, no output schema, and no parameter descriptions, the description is too minimal. It covers purpose and units but lacks details about filtering, pagination, defaults, or return structure, leaving the agent underinformed.

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 0%, and the description provides no explanation of any of the 7 parameters (labels, symbol, orderBy, pageSize, pageIndex, tokenName, listedPancake). The agent must rely on parameter names and enums alone, which is insufficient for proper 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 clearly states the tool finds meme coins on BSC via FourMeme, which is a specific verb+resource and differentiates from siblings like hederaFindMemeCoins (different chain) and getPumpFunTokens (different platform). No ambiguity.

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 BSC-based meme coins via FourMeme, providing clear context for when to use this tool. However, it lacks explicit exclusions or comparison to alternatives, so it doesn't fully meet the highest bar.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by explaining what is returned: native BNB plus all detected BEP-20 balances with fields like contract address and USD value where pricing is available. This is a useful behavioral disclosure beyond the annotations.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and packs details without redundancy. Every phrase contributes meaningful 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 there are no parameters, no output schema, and strong annotations, the description is fully adequate. It explains the return contents and limitations (USD value only where pricing available), making it complete for a simple balance lookup 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 has no parameters, and the rule sets a baseline of 4 for zero-parameter tools. The description still contributes by clarifying that the tool uses the user's wallet context, which is helpful.

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 the user's wallet holdings on BNB Smart Chain (chain ID 56), specifying native BNB and BEP-20 tokens with contract address, symbol, decimals, and USD value. This distinguishes it from sibling getBalances tools for other chains.

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

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

The description makes the context clear by naming BNB Smart Chain and chain ID 56, implying it should be used for BSC holdings rather than other chains. However, it does not explicitly mention alternatives or exclusions, so it stops short of full guideline quality.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds value by revealing the underlying protocols (Uniswap X or 0x) and the native BNB address, but does not disclose additional behavioral traits such as rate limits, response format, or potential fees.

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

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

Two sentences, zero filler. The first sentence states purpose and protocols, the second provides a critical usage tip. Every word earns its place.

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

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

No output schema exists, but the description does not explain what the quote response contains (e.g., expected output, price, slippage, fees). For a tool that returns data, this omission makes it partially incomplete despite covering input and protocols.

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 parameters are already documented. The description adds a concrete hint about using 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE for native BNB, which is helpful for correct parameter values beyond the schema's generic 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 gets a swap quote for BSC tokens, names the protocols used (Uniswap X or 0x), and includes a special address for native BNB. This differentiates it from sibling swap tools for other chains.

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 BSC tokens via the token addresses, but does not explicitly state when to use this tool versus alternatives like ethSwapQuote or baseSwapQuote. No when-not or prerequisite conditions are given.

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 provide readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds minimal behavioral context (availability timing) but does not disclose return format, edge cases, or block-height semantics. No contradiction with annotations.

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

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

The description is a single focused sentence, front-loads the action and resource, and contains no filler or redundant 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?

The tool is simple with one documented parameter and strong annotations, but there is no output schema and the description does not clarify what the return value looks like or how edge cases are handled. This leaves some ambiguity for the agent.

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

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

The input schema has 100% coverage for the single 'name' parameter, including spacer removal behavior. The description adds no extra parameter semantics beyond 'specific rune name,' so it neither compensates nor harms.

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 'Check' and clearly identifies the resource: 'when a specific rune name becomes available to etch.' This distinguishes it from sibling tools like getRuneInfo or getLatestRunes by focusing on availability timing.

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 no explicit guidance on when to use this tool versus alternatives. It does not mention related tools, exclusion cases, or prerequisites, so the agent must infer applicability solely from the one-line purpose.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds a hint about pagination via nextPageId, which is useful, but it does not disclose return format or other behavioral traits beyond what annotations already provide.

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

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

The description is two short sentences, front-loaded with the purpose and then a pagination hint. There is zero wasted text; every 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?

For a tool with 6 parameters, no output schema, and many sibling token tools, the description is severely under-specified. It provides a basic pagination pattern but omits critical details like valid sort values, platformId semantics, and return structure, making it insufficient for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate for all parameters. It explains 'size' (pass size=5) and 'nextPageId' (paginate), but leaves 'sort', 'mintType', 'platformId', and 'includeNsfw' completely unexplained, including the required 'sort' 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 'Get LaunchLab / bonk.fun tokens' uses a specific verb and resource, making the purpose immediately clear. It also distinguishes this tool from sibling token tools like getPumpFunTokens or findSolanaGems by naming the LaunchLab platform.

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 LaunchLab/bonk.fun token discovery, which is a clear context, but it provides no explicit when-to-use instructions or alternative comparisons. It lacks guidance on when to prefer this over sibling tools, so it falls short of a 4.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds the context 'specific curated collection' and 'vault creation', but does not disclose behaviors like pagination, return structure, or error conditions. It provides some added context but not rich behavioral detail.

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

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

The description is a single, front-loaded sentence that immediately states the action and target. It avoids filler and repeats nothing from the schema or annotations, making it highly efficient.

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

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

Given the tool's simplicity (one parameter), strong schema coverage, and rich annotations, the description is fairly complete for its purpose. It explains what it does and why it would be used. The lack of an output schema means the description could have mentioned the return format, but the phrase 'Get all assets' adequately conveys the core result for this 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 provides a clear description of collectionName with examples and a hint to list collections first, so schema coverage is 100%. The description's reference to 'specific curated collection' reinforces the parameter's meaning but does not add substantial new information 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 uses a specific verb 'Get' with a clear resource 'all assets within a specific curated collection' and adds context 'for vault creation'. It distinguishes itself from sibling tools like emblemListCollections (lists collections) and emblemResolveAsset (resolves individual assets) by focusing on retrieving all assets in a collection.

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

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

The description implies when to use the tool: during vault creation, and the schema parameter description explicitly advises 'use emblem list collections first', which provides actionable sequencing. However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of full guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds context that this is a read operation for deposit addresses and mentions accepted coins, providing value beyond annotations without contradicting them.

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

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

The description is extremely concise, with exactly two sentences that immediately state the core function and a key feature. Every word contributes value, with no redundant 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 tool's simplicity (one parameter, read-only operation) and lack of output schema, the description provides adequate context by stating what is returned (deposit address and accepted coins). It does not describe the address format or network details, but these are likely less critical for this use case.

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

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

The input schema already documents the tokenId parameter with clear coverage (100%) and a helpful hint to get it from emblemListMyVaults. The description itself says nothing about parameters, so it does not add meaning beyond the schema, but the schema is sufficient.

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 action ('Get the deposit address for a vault') and adds a distinct detail ('Shows which coins are accepted'). This differentiates it from sibling tools like emblemListMyVaults and emblemGetCollectionAssets, which have different purposes.

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 context (deposit address for a vault) but does not explicitly state when to use this tool over alternatives. The schema parameter hints at obtaining the token ID from emblemListMyVaults, but the description itself lacks explicit guidance 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?

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds minor context about 'curated collections' and 'asset details', but does not disclose deeper behavioral traits like pagination, rate limits, or what 'curated' means. This is acceptable but not rich.

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, front-loaded sentence that conveys the purpose and key output details without any 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 listing tool with one optional parameter and strong annotations, the description adequately covers the core functionality and output hint ('with asset details'). It does not specify the return format, but that is not critical here.

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

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

Schema description coverage is 100% (the single parameter showAll has a clear description). The tool description adds no additional parameter information, so the baseline of 3 is appropriate.

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

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

The description states a specific action ('List all available curated collections for vault creation') with a clear resource and scope. It differentiates from siblings like emblemListMyVaults and emblemGetCollectionAssets by emphasizing the 'for vault creation' 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?

The phrase 'for vault creation' provides clear context for when to use this tool, but it does not explicitly mention alternatives or exclusions. There is no direct 'use this instead of X' guidance, though the context is sufficient for most cases.

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral context: ownership scope (connected wallet or specified address) and optional status filtering, which go beyond the basic read-only nature.

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

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

The description is a single, concise sentence that front-loads the main action and scope. Every word contributes value, with no redundant 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?

The tool is a simple list operation with low complexity. Although there is no output schema, the name and description make the return type (list of vaults) implicit. The description provides sufficient context for a straightforward read operation.

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

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

The input schema has 100% coverage with descriptions for both parameters. The description adds minimal extra meaning, merely restating that status filtering is optional and that an address can specify a wallet. This aligns with the baseline for schema-heavy 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 clearly specifies the action ('List'), the resource ('vaults'), and the scope ('owned by the connected wallet or a specified address'). It distinguishes itself from sibling tools by focusing on vaults rather than collections, assets, or deposit addresses.

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 this tool: when you need vaults owned by a wallet, optionally filtered by status. It does not explicitly mention alternatives or exclusions, but the context is sufficient for the agent to differentiate from related emblem tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: the mandatory sequencing with emblemCreateVault, which is essential for correct usage. No contradiction with annotations.

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

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

The description is two sentences: the first states the core function, the second provides a critical usage directive. It is front-loaded, concise, and every word earns its place without unnecessary fluff.

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

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

Given the simple one-parameter tool with rich annotations, the description fully explains what it does and when to use it. It does not describe return values (no output schema), but the critical ordering note with emblemCreateVault adds essential context. Sibling tools that might be alternatives are not explicitly contrasted, but the description is adequate for this 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?

Input schema covers 100% of parameters and includes a clear description with examples for 'assetName'. The tool description does not add additional parameter semantics, but the schema already provides sufficient meaning, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb ('Resolve') and resource ('asset name to its curated collection'). It distinguishes itself from sibling tools like emblemListCollections by focusing on resolving a single asset name to its collection, and it references a concrete use case with emblemCreateVault.

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 indicates when to use the tool: 'BEFORE emblemCreateVault when vaulting user assets' and explains the purpose ('to find the correct collection name'). It does not explicitly mention alternatives or when not to use it, but the CRITICAL call-before instruction provides strong usage 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?

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context about the two balance representations and warns against using the rounded one for trades, going beyond 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?

Two sentences deliver the core purpose and a critical usage warning without redundancy. The structure front-loads the main action and then highlights an important caveat, making it efficient and easy to parse.

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 sufficient for a simple read-only tool with no parameters, but it does not clarify how the wallet is identified (implicitly from context) nor list the full set of return fields. The critical warning about balance fields compensates somewhat, but some information about input context is missing.

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

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

There are no parameters, so the schema coverage is trivially complete. Baseline for zero-parameter tools is 4; the description adds no parameter info but provides output field guidance, which is still relevant to 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 clearly states the tool fetches wallet balances on Ethereum, using a specific verb and resource. It distinguishes itself from sibling getBalances tools for other chains by naming the network, 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 implies use for Ethereum wallet balances, and the network specificity helps tool selection. However, it does not explicitly mention alternatives or exclusions, but the critical note about using 'balance' vs 'humanReadableBalance' provides clear guidance on how to interpret the output.

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

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

Annotations already cover safety (readOnlyHint, destructiveHint, etc.). The description adds useful context about volatility and the native ETH address but does not disclose other behaviors like rate limits or response format. With annotations present, 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 exceptionally concise: two sentences that front-load the core purpose and then add critical usage tips. No wasteful words, every sentence earns its place.

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

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

While the description is clear for its simple purpose, it lacks information about the return format (e.g., structure of the quote). No output schema exists, so the description should ideally describe what the agent can expect. Missing this reduces completeness for such a 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%, so baseline is 3. The description adds value by specifying the native ETH address (0xEeeee...), which is a practical hint for the fromTokenAddress parameter, improving usability 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 'Get current USD price and swap quote for Ethereum tokens,' specifying a specific verb and resource. It distinguishes from sibling tools for other chains (e.g., baseSwapQuote) by explicitly mentioning Ethereum.

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 includes a strong usage hint: 'ALWAYS fetch fresh prices - crypto is volatile,' guiding the agent to avoid stale data. It also provides the native ETH address. However, it does not explicitly exclude alternatives or specify 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful context about the cross-network search behavior ('across ALL networks') but does not detail return format, error handling, or any additional behavioral traits. This is adequate but not rich.

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

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

Two sentences, front-loaded with the main purpose and followed by a clear usage directive. No wasted words; every sentence adds 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?

For a simple 1-parameter read-only lookup tool with strong annotations and full schema coverage, the description is adequately complete. It explains what it does and when to use it. Lacking explicit return value details is a minor gap given the tool's simplicity and the absence of an 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?

Schema description coverage is 100% with positionId described as 'The position ID to find,' so the schema already documents the parameter fully. The tool description adds no extra meaning beyond what the schema provides, matching the baseline for high 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 uses a specific verb ('Find') and resource ('conditional trade position') with scope ('across ALL networks'), clearly distinguishing it from sibling tools like getAllPositions and listPositions by focusing on ID-based lookup across networks.

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

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

The description explicitly states when to use this tool: 'Use this when you have a position ID but don't know which network it's on.' It provides clear context but does not name alternative tools or give explicit when-not-to-use guidance, so it stops short of a 5.

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

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

Annotations already provide readOnly, openWorld, idempotent, and non-destructive hints. The description adds value by explaining the two category modes and noting that stock tokens reflect real stock prices, which is beyond the structured metadata. No contradiction.

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

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

Three sentences, front-loaded with the core purpose, and every sentence adds useful context without redundancy. Excellent structure.

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 16 parameters and no output schema, the description provides sufficient context for tool selection by covering the two categories, use cases, and exclusions. The return type (list of tokens/stocks) is implied clearly by 'Discover... tokens'.

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

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

Schema coverage is 100%, so the baseline is 3. The description enriches parameter understanding by listing sort options (trending, popular, top traded, organic, new) matching enum values, and clarifying that category='stocks' ignores sortBy, adding 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 discovers trending Solana tokens or tokenized stocks. It explicitly distinguishes from siblings by naming findSolanaSwapToken and getPumpFunTokens for other use cases, and provides concrete example intents like 'trending tokens' and 'TSLA stock token'.

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

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

It includes explicit 'Use for' and 'NOT for' sections with specific alternative tool names, making it unambiguous when to select this tool over others.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond the trigger, but does not describe return value, error handling, or scope. With annotations present, this is adequate but not rich.

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, front-loaded with the core purpose, and contains no waste. Every sentence earns its place.

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

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

For a simple, single-parameter lookup tool with good annotations, the description provides sufficient context including the specific trigger scenario. It could mention what the tool returns, but given the lack of an output schema and the simplicity of the tool, the description is adequate.

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

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

The input schema already fully describes the single parameter tokenName as 'Token name or symbol to search,' and the description echoes this. With 100% schema coverage, the description adds no additional parameter semantics, 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 states 'Find a Solana token by name or symbol' with a specific verb and resource. It distinguishes itself from sibling tools by adding the trigger condition 'Use when splBuyIntent reports ambiguous token symbol,' making its purpose unique.

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

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

The description provides an explicit when-to-use context ('Use when splBuyIntent reports ambiguous token symbol'), which helps an agent decide. However, it does not mention alternatives or when not to use, so it is a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds minimal context beyond this, like the fact that it uses Firecrawl and extracts structured data, but does not disclose potential rate limits, external dependency costs, 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 a single, front-loaded sentence with no redundant phrasing aside from 'Investigate or', which slightly dilutes precision. It earns a high score for being compact and easy to parse.

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

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

Given the tool has nested objects (options), 4 parameters, and no output schema, the description is far too sparse. It does not explain return values, how prompts interact with extraction, or the meaning of enableWebSearch, making it inadequate for correct invocation in many 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?

Schema description coverage is 0%, so the description must compensate by explaining parameters, but it does not. It only hints at the 'url' resource and says nothing about 'prompt', 'options', or 'enableWebSearch', leaving the agent without enough information to correctly populate these fields.

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

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

The description clearly states a specific action ('Extract structured data') and resource ('web pages or urls'), and references Firecrawl as the underlying service. However, it does not explicitly distinguish itself from the sibling 'websearch' tool, relying on the word 'Extract' to imply a difference.

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?

There is no guidance on when to use this tool versus alternatives like 'websearch' or other chain-specific tools. The description only states what the tool does, not in what context it should be chosen or when to avoid it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds scope context (includes NFTs, contracts, etc.) but doesn't disclose return format, pagination, or edge cases. This is acceptable given the simple read-only nature.

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

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

The description is two short sentences, front-loaded with the core action, and every word earns its place. The second sentence clarifies scope without padding.

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 one parameter and strong annotations, the description is complete enough. It specifies the address input and the full scope of returned data, with no output schema needed.

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

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

The input schema has 100% coverage for the single parameter (bitcoinAddress) with a description 'The Bitcoin address'. The tool description repeats the parameter's purpose but adds no additional format or example details, so it does not go 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 verb 'Get' and the resource 'alkane balance for a Bitcoin address', and explicitly lists what is included ('tokens, NFTs, contracts, and any other type of alkane'). This distinguishes it from sibling tools like getAlkaneAddressUTXOs and getAlkaneInfo.

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: when you need the alkane balance for a Bitcoin address. It doesn't explicitly exclude alternatives or name sibling tools, but the scope is clear and self-contained.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context that the UTXOs include tokens, NFTs, contracts, and other alkanes, clarifying the asset scope beyond the name. It does not specify edge cases like whether all UTXOs or only alkane-bearing ones are returned, but the annotation coverage lowers the bar.

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

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

Two concise sentences with the verb and resource front-loaded. Every word earns its place, and there is no redundant or extraneous 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 read-only tool with one parameter and rich annotations, the description provides enough context about what is returned. It could be more explicit about whether only alkane-bearing UTXOs are returned, but the name clarifies that, and no output schema is needed for this level of 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?

The schema provides a description for the single parameter ('The Bitcoin address') with 100% coverage. The tool description does not add any additional format, validation, or context beyond what the schema already gives, 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 clearly states it retrieves UTXOs for a Bitcoin address, specifically those related to alkanes, including tokens, NFTs, contracts, and other types. This distinguishes it from siblings like getUtxoRunes (runes) and getBTCBalances (BTC 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?

No guidance is provided on when to use this tool versus alternatives such as getAlkaneAddressBalance or getUtxoRunes. The description simply states what it does without any exclusions, prerequisites, or context for selection.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description need not repeat safety. It adds value by enumerating the exact metadata fields returned and noting the conditional 'if applicable' for contract details, which is useful context beyond annotations.

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

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

One sentence, front-loaded with the action, and no fluff. It efficiently conveys purpose and return fields.

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 lookup with one parameter, full schema coverage, and strong annotations, the description is complete. It explains what data is returned, which suffices given no output schema exists.

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 'id' is fully documented in the schema with format and example, leaving nothing for the description to add. With 100% schema coverage, 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 fetches metadata for a single Alkane by protocol ID, listing specific fields (name, symbol, supply, type, contract details). This distinct purpose stands out from siblings like getAlkaneAddressBalance and listAlkanes.

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

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

The phrase 'single Alkane' and 'metadata' provide clear context that this tool is for one-item lookups, differentiating it from balance or listing tools. However, it does not explicitly name alternatives or state when not to use it, so it falls just short of a 5.

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

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

Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds the cross-network scope and optional filtering, which provides behavioral context beyond annotations. However, it does not disclose potential large result sizes or performance implications.

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 action ('Get ALL conditional trade positions across ALL networks'), and contains no redundant words. Every sentence adds 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?

For a simple list with one optional filter and good annotations, the description covers the essential: what it returns and how to filter. It does not mention pagination or data volume, but given the simplicity, it is largely complete for tool selection.

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 the single parameter 'status' with enum values and description. The description only restates the optional filter without adding new meaning or format details, thus not exceeding the baseline.

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

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

The description clearly states 'Get ALL conditional trade positions across ALL networks' with a specific verb and resource. It distinguishes itself by emphasizing the cross-network scope, differentiating from per-network or per-position siblings like listPositions or findPositionById.

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 fetching all positions globally with optional filtering, but does not explicitly state when to use this tool versus alternatives (e.g., for specific network or user positions). No exclusion criteria or alternative mentions are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds value by disclosing that results are paginated and that returns include slug, name, supply, and identifiers. It explains the tool's scope ('all indexed') and its role in discovery, which goes beyond bare annotation flags. A slight gap is no mention of rate limits or paging details, but that is minor for a read-only list endpoint.

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 primary purpose, followed by return fields and usage guidance. Every clause adds value with no redundancy or fluff. It's efficiently structured and immediately understandable.

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 list tool with one optional parameter, the description fully explains what it returns and how to use it. It mentions pagination, return fields, and the use case. An output schema is absent, but the description compensates by listing the returned fields. There are no other behavioral aspects that need disclosure in this 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 single parameter 'page' is fully described in the input schema (1-indexed, omit for first page), so schema coverage is 100%. The description reinforces the 'paginated' nature but doesn't add new semantic information beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly states the tool's function: 'Browse all indexed Bitcoin Ordinals inscription collections (paginated).' It specifies the resource (Bitcoin Ordinals inscription collections) and the action (browse/returns), and differentiates it from siblings by mentioning pagination and pointing to getCollectionInfo/getCollectionMarketInfo for more specific 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 explicitly says the tool is 'useful for discovery before drilling into floor price or assets via getCollectionInfo / getCollectionMarketInfo,' naming concrete alternatives and indicating when to use this tool versus those. This provides clear context for selection.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe profile is covered. The description adds the pagination behavior and specifies the types of activity included, providing context beyond the structured annotations. No contradiction exists.

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

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

The description is a single, front-loaded sentence that conveys the core purpose and key output details without waste. Every clause adds value: the resource, address, activity types, and pagination.

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

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

For a read-only list tool with no output schema, the description adequately covers what is returned (activity types, timestamps, amounts) and pagination. It is sufficiently complete for an agent to understand the tool's behavior, though it could optionally mention field details or maximum page size.

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 both parameters (bitcoinAddress and page) at 100% coverage with descriptions. The tool description adds only 'Paginated' which hints at the page parameter but provides no additional semantic detail. Baseline 3 is appropriate given the schema already documents the 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 uses a specific verb ('Return') and clearly identifies the resource ('BRC-20 token transfer history for a given Bitcoin address'). It enumerates activity types (deploys, mints, transfers, sends, receives) and includes timestamps and amounts, fully distinguishing it from sibling tools like getInscriptionActivity or getRunesActivity.

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

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

The description clearly implies when to use this tool: when you need BRC-20 transfer history for a Bitcoin address. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5. The context is unambiguous enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read operation. The description adds the returned data fields but provides no further behavioral details such as error handling, rate limits, or response format. It does not contradict annotations.

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

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

A single, well-structured sentence that front-loaded the verb and resource, followed by a list of returned fields. No filler or redundant content.

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

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

For a simple single-parameter tool with no output schema, the description enumerates all key return values (price, supplies, mint progress, holders, market cap), covering essential information. Combined with strong annotations, this is sufficient.

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

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

The input schema fully describes the ticker parameter with details on typical length and case-insensitivity, achieving 100% coverage. The description merely restates 'by ticker' without adding extra meaning, so the baseline of 3 applies.

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

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

The description states a specific verb ('Fetch') and resource ('protocol + market metadata') scoped to a single BRC-20 token by ticker, listing concrete fields returned. This clearly differentiates it from sibling tools like getBRC20Activity (activity) or listBRC20Tokens (listing).

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 context is clear: use this tool to fetch metadata for one BRC-20 token by ticker. However, it does not explicitly mention alternatives or when-not-to-use, unlike the highest-calibrated examples. Still, the scope is 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context beyond annotations by specifying the address types (P2TR, P2WPKH), units (BTC and sats), and exclusions. It does not mention potential edge cases like empty wallets or authentication, but given annotation coverage, it is sufficiently 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 exactly two sentences, front-loaded with the primary purpose in the first sentence and exclusions/alternatives in the second. There is no redundant information; every sentence adds 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 the low complexity (no parameters, no output schema), the description fully covers what the tool does and what it returns: native BTC balances by address type in BTC and sats. It also clarifies exclusions and directs to alternatives, making it 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?

The tool has 0 parameters, so the baseline is 4. The description does not need to explain parameters because none exist. It correctly focuses on the output and scope rather than input 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 ("Return") and clearly identifies the resource (native BTC balances) and scope (user's wallet, broken out by taproot and nested segwit addresses, in BTC and sats). It further distinguishes itself from sibling tools by explicitly listing what it does NOT include (runes, ordinals/inscriptions, Counterparty assets) and pointing to dedicated tools for those assets.

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: it states the tool returns only native BTC balances and explicitly says to use getRuneBalances / getInscriptionsByAddress / getXCPBalances for runes, inscriptions, and Counterparty assets. This clearly tells an agent when to use this tool versus 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?

Annotations already indicate readOnly, non-destructive, idempotent, and open world. The description adds no behavioral details beyond the name, so it contributes minimal additional 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 a single sentence that is front-loaded and contains no extraneous information. Every word earns its place.

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

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

For a simple read-only tool with two parameters and no output schema, the description is adequate. It states the purpose and result type. Missing details about filter behavior are covered by the 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?

Schema description coverage is 100%, meaning the schema already describes both parameters. The description does not enhance understanding beyond what the schema provides.

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

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

The description clearly states the tool's function: getting supported currencies for cross-chain swaps. It uses a specific verb ('Get') and resource ('supported currencies'), and the context distinguishes it from siblings like 'getChangeNowSwapQuote' which handles quotes.

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?

No explicit guidance on when to use this tool versus alternatives. The description implies it's a prerequisite for swap quotes but does not mention when not to use it or provide 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?

Annotations already indicate readOnlyHint, idempotentHint, and openWorldHint. The description adds that it is for cross-chain exchange and that tickers must be supported. It does not contradict annotations, but fails to disclose potential behavioral aspects like rate limits or output risk. Given annotations coverage, this is minimally 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 sentences, front-loaded with the main purpose. It is concise with no wasted words. However, it could be slightly more informative (e.g., hinting at the output structure) without becoming verbose, so it earns a 4 rather than a 5.

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 should explain what the quote contains (e.g., estimated rate, fees, expiration). It only mentions the constraint on tickers. For a quote tool, the agent needs to know the return format. The description is incomplete for effective 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?

The input schema already has 100% coverage with clear parameter descriptions (fromTicker, toTicker, fromAmount). The tool description adds no additional meaning beyond the schema, so it provides no extra value. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Get a swap quote for cross-chain exchange.' It specifies the verb 'Get', the resource 'swap quote', and the domain 'cross-chain exchange via ChangeNow.' This distinguishes it from sibling swap tools that may be on different protocols or single-chain.

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 by stating 'Tickers must be supported by ChangeNow,' suggesting use only for ChangeNow-supported pairs. However, it does not explicitly state when to use this tool over siblings like baseSwapQuote or ethSwapQuote, nor does it provide when-not-to-use guidance. Usage is implied but not fully clarified.

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 provide readOnlyHint, destructiveHint, etc. The description adds no behavioral details beyond what is implied by the name. It does not mention pagination, data freshness, or rate limits, which would be helpful given the openWorldHint.

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 concise sentence, but it is overly minimal. While it front-loads the purpose, it could benefit from additional context without becoming 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?

Given the absence of an output schema and moderate complexity, the description should mention that results are paginated and list ETF items. Currently it only states it provides a list, which is insufficient for an agent to understand 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter information beyond the schema, but since the schema already describes page and limit, no extra is needed.

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

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

The description clearly states the tool provides a list of Bitcoin-based ETFs, using a specific verb and resource. It distinguishes from similar sibling tools like getCoinglassEthereumEtfList and getCoinglassBitcoinETFNetAssetsHistory.

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 offers no guidance on when to use this tool versus alternatives. With many sibling tools like getCoinglassBitcoinETFNetAssetsHistory or getCoinglassEthereumEtfList, explicit context on selection criteria is missing.

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 (readOnlyHint, idempotentHint) already indicate safe, read-only behavior. Description adds no additional behavioral traits beyond what annotations provide.

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

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

Single sentence clearly communicates purpose without extraneous information. Efficient and 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?

Description sufficiently explains what data is returned (historical net assets for Bitcoin ETFs). Could specify scope (aggregate or per ETF) but acceptable given simplicity and complete 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?

Schema coverage is 100% for both pagination parameters. Description does not add meaning beyond the schema's parameter 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?

Title and description clearly state it provides historical net assets data for Bitcoin-based ETFs. Distinguishes from siblings like getCoinglassBitcoinEtfList and getCoinglassEthereumETFNetAssetsHistory.

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?

Description does not explicitly state when to use this tool versus alternatives. Usage context is implied by the tool name and siblings, but no direct guidance is provided.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's simple 'provides data' is consistent but adds no additional behavioral context. It does not disclose pagination limits, data freshness, or whether historical data is available. With high annotation coverage, this is acceptable but not revealing.

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 sentence of 13 words. It is front-loaded with the core data type ('data on margin long and short positions') and source ('from Bitfinex'). 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?

Given no output schema, the description should ideally hint at the return type (e.g., list of positions, with long/short ratios). It only states 'data on margin long and short positions', which is vague. The tool has moderate complexity (3 params, no enums), so the description is minimally adequate but could specify whether results are historical or current, and the structure of each position.

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

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

Input schema has 100% description coverage for all three parameters, so the description's role is minimal. It does not add semantics beyond the schema, which already explains 'symbol', 'page', and 'limit'. 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 it provides 'margin long and short positions from Bitfinex', using a specific verb ('provides') and resource ('margin long and short positions from Bitfinex'). It distinguishes itself from sibling tools like 'getCoinglassBitcoinEtfList' which deal with ETFs.

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 does not state when to use this tool or when not to. It merely describes what it does, leaving the agent to infer usage context. No alternatives or exclusions are mentioned.

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, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which cover safety and idempotency. The description does not add any behavioral context beyond what annotations provide, missing opportunities to mention data freshness or rate limits.

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 concise sentence with no unnecessary words. It front-loads the purpose and 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?

Given the tool's simplicity (3 parameters, no output schema, clear annotations), the description is adequate. It could mention the data source or typical use cases but is largely complete for a straightforward read 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 has 100% description coverage for all three parameters (symbol, exchange, interval), providing examples and formats. The description adds no additional meaning beyond the schema, achieving the baseline 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 provides daily borrowing interest rates for cryptocurrencies, with a specific verb and resource. It distinguishes itself from sibling tools like getCoinglassBitcoinEtfList by focusing specifically on borrowing interest rates.

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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or conditions. The usage context is only implied by the name and purpose.

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

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

Annotations already indicate read-only, idempotent behavior. The description adds 'historical' context but does not elaborate on pagination or other traits. Adequate but unremarkable.

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?

Single sentence with no waste, front-loaded with verb and resource. However, it is extremely brief and could benefit from more structure.

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 tool with robust schema and annotations, the description is minimally complete. It omits clarification of output format or data range, but complexity is low.

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 description adds no additional meaning to the parameters. Baseline score 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 it provides historical CDRI data, which distinguishes it from sibling tools like getCoinglassCGDIIndex (a different index). However, it could be more specific about the data's nature.

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?

No guidance on when to use this tool versus alternatives (e.g., getCoinglassCGDIIndex). The description lacks context for agent decision-making.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. Description adds 'historical' context, which is consistent but does not disclose pagination behavior or rate limits.

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?

Single sentence that is clear and to the point, no extraneous 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 full schema coverage and strong annotations, the description is adequate but could benefit from mentioning the purpose of CGDI or that data is paginated.

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 has 100% coverage with descriptions for both parameters. The description does not add any additional parameter meaning beyond what schema already provides.

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

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

Clearly states it provides historical CGDI data, but does not differentiate from many sibling getCoinglass* tools. The acronym CGDI is defined in parentheses, which helps but could be more specific.

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?

No guidance on when to use this tool versus alternatives. Only describes what it does without context for selection.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds 'with pagination', which is implicit from the schema, but doesn't disclose additional behavioral traits like rate limits or data freshness.

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 sentence that efficiently conveys the core action and resource. No unnecessary 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?

With no output schema, the description could explain the response structure (e.g., fields returned, pagination metadata). It does not, leaving the agent to infer. Adequate but incomplete.

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

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

Schema coverage is 100%, and the schema descriptions for page and limit are clear. The description mentions pagination but adds no meaning beyond what the schema already provides.

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

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

The description clearly states the verb 'Get' and the resource 'Ethereum ETFs with pagination'. It distinguishes from sibling tools like getCoinglassBitcoinEtfList by specifying Ethereum.

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?

No guidance is provided on when to use this tool versus alternatives such as getCoinglassEthereumETFNetAssetsHistory. The description lacks context for selection.

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

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description does not add behavioral context beyond stating it provides 'historical net assets data'. It does not describe pagination behavior or response structure. With good annotations, a score of 3 is appropriate as description adds no additional behavioral insights.

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?

One sentence of 11 words, no filler, front-loaded with key information. Highly concise and efficient.

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

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

For a simple paginated historical data tool with good annotations and schema coverage, the description is nearly complete. It lacks details on return value format but is acceptable given the low complexity and presence of sibling tools for comparison.

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

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

Input schema has 100% coverage with descriptions for both parameters (page and limit). The tool description adds no extra meaning beyond the schema. Baseline of 3 is correct as schema already documents the 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 'Historical net assets data for Ethereum-based Exchange-Traded Funds (ETFs)'. This uses a specific verb-resource combination ('get historical net assets data') and distinguishes from sibling tools like getCoinglassEthereumEtfList (which likely lists ETFs) and getCoinglassBitcoinETFNetAssetsHistory (for Bitcoin).

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?

No explicit guidance on when to use this tool versus alternatives. The description does not mention any contexts where it should or should not be used, nor does it reference sibling tools or provide when-not 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?

Annotations (readOnlyHint, destructiveHint) already indicate safety. The description adds context about returned data fields but does not disclose pagination behavior or potential rate limits. Given annotations, this is adequate but not enriched.

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?

Single concise sentence efficiently communicates purpose and key data fields. No redundant or irrelevant 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?

Description mentions returned fields but no output schema exists. It does not explain pagination or how to handle large results. Given multiple sibling tools, more details on uniqueness would help.

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 parameters with descriptions (exchange, page, limit). The description does not add further meaning beyond what schema provides, so baseline 3 applies.

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

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

The description clearly states the tool provides asset holdings data for exchange wallets, listing specific fields (address, balance, USD value, price info). It distinguishes from siblings by focusing on exchange wallet assets, and the required 'exchange' parameter clarifies the 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?

No guidance on when to use this tool vs. alternatives like getCoinglassExchangeBalanceList. It does not specify prerequisites, limitations, or appropriate contexts beyond the implied use case.

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

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

Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. Description aligns with these, but adds no additional behavioral context beyond what annotations provide. No contradiction.

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

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

Very concise single sentence, front-loaded with the action. No wasted words, but could be expanded slightly to improve clarity without losing efficiency.

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?

Despite 100% schema coverage and annotations, the description lacks details about the output structure (e.g., what fields are in the list). As a list tool without an output schema, description should compensate but does not.

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 all three parameters (symbol, page, limit) are described. The description does not add extra meaning or usage details beyond the schema, 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?

Description clearly states it provides a list of exchange balances for a given symbol, which is a specific verb+resource. It distinguishes from sibling tools like getCoinglassExchangeAssets by focusing on balances for a symbol, but could be more precise about what 'exchange balances' entails.

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?

No guidance on when to use this tool vs alternatives. Given many similar Coinglass tools, the description should specify context or mention when to prefer this over others like getCoinglassExchangeAssets or getCoinglassBitcoinEtfList.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's mention of 'historical' adds context but does not reveal additional behavioral traits like pagination behavior or data freshness. The description does not contradict annotations.

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

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

The description is a single clear sentence that conveys the core purpose efficiently. It could be slightly more structured but is 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?

No output schema exists, so the description should clarify return structure. It mentions included data fields but does not explain pagination or ordering. The tool is straightforward but leaves some gaps for an agent.

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

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

Schema coverage is 100% with each parameter described. The description adds minimal extra meaning beyond the schema, only hinting at the output fields. Baseline of 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool provides historical futures basis data with open/close rates and annualized changes, distinguishing it from other Coinglass tools that focus on ETFs, options, or whale 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?

No explicit when-to-use or when-not-to-use guidance is given. The description does not mention alternatives or context for choosing this tool over siblings like getCoinglassOpenInterestHistory or getCoinglassPremiumIndex.

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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds no behavioral disclosure beyond 'provides a list', missing details like pagination behavior, data recency, or rate limits. Minimal added value.

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 short sentence, no fluff. It is efficient but lacks structure (e.g., no bullet points or details). Still, it earns a high score 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?

No output schema is provided, and the description is very brief. Agents lack context on what the data includes (e.g., fields, time ranges). Given the open world hint, some incompleteness is tolerable, but more detail would help.

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

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

Schema coverage is 100%, and the parameters 'page' and 'limit' are described in the schema. The description does not add any additional meaning or context beyond what is already in the schema, so 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 'Provides a list of futures whale index data' clearly states the verb ('provides') and resource ('futures whale index data'). However, among many sibling Coinglass tools (e.g., getCoinglassOpenInterestHistory, getCoinglassBitcoinEtfList), it does not differentiate what makes this whale index data unique.

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

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

The description offers no guidance on when to use this tool versus alternatives, nor does it mention context or prerequisites. Agents have no help deciding between this and other Coinglass data tools.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe read-only operation. The description adds no additional behavioral traits beyond what the annotations provide—e.g., no mention of data freshness limits, pagination behavior, or any side effects.

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 concise sentence that wastes no words. It is front-loaded and to the point, 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?

The tool has no output schema, so the description would ideally describe what the output contains (e.g., list of holdings with fields like ticker, amount, etc.). It does not, but the annotations are rich and the parameters are simple. The description is adequate but incomplete for an agent to fully understand the tool's response.

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

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

The input schema has 2 parameters (page, limit) with descriptions covering 100% of parameters. The description does not add any extra meaning beyond the schema, but the schema is sufficient. Baseline 3 is appropriate given full schema coverage.

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

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

The description clearly states it provides a list of holdings managed by Grayscale Investments. It uses a specific verb ('provides a list') and specific resource ('holdings managed by Grayscale Investments'), distinguishing it from sibling tools like getCoinglassBitcoinEtfList or getCoinglassExchangeAssets.

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 offers no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or scenarios where another tool would be more appropriate. The sibling list includes many similar Coinglass tools, but no differentiation is provided.

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

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

Annotations already cover read-only and idempotent behavior. Description adds real-time aspect but does not disclose pagination limits, data freshness, or response format.

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?

Single sentence, front-loaded with purpose, no redundant 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 tool with no output schema, description covers core functionality and threshold. Could mention pagination limits or update frequency for completeness.

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

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

Schema coverage is 100% with descriptions for both parameters. Description does not add meaning beyond schema, so baseline 3.

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

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

Description clearly states it provides real-time whale alerts on Hyperliquid with a specific threshold (>$1M), distinguishing it from sibling tools like getCoinglassHyperliquidWhalePosition and getCoinglassFuturesWhaleIndex.

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?

Implies usage for tracking large positions but lacks explicit when-to-use vs alternatives or what not to use it for. No guidance on context 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, covering safety and idempotency. The description adds 'real-time,' but does not disclose pagination limits, data freshness boundaries, or how 'whale position' is defined. With strong annotation coverage, the description adds minimal behavioral context beyond 'real-time'.

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?

Single sentence is concise and front-loaded with the core action. However, it is somewhat vague and could elaborate on the tool's value in the same space.

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

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

Given the tool's simplicity (2 optional params, no output schema, clear annotations), the description is adequate but lacks context on what 'whale position data' entails (e.g., whether it returns tables, charts, or alerts). Could mention data source or usage 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?

Input schema covers both parameters (page, limit) with clear descriptions, achieving 100% coverage. The description adds no extra meaning about parameters, 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 states it provides 'real-time whale position data on Hyperliquid,' specifying the resource (whale position data) and platform (Hyperliquid). It distinguishes from siblings like getCoinglassHyperliquidWhaleAlert, though could be more specific about what constitutes a whale position.

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?

No guidance on when to use this tool versus alternatives such as getCoinglassHyperliquidWhaleAlert or getCoinglassFuturesWhaleIndex. There is no mention of context, prerequisites, 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?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds only ERC-20 and exchange scope, omitting details about return format, pagination, or data freshness.

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?

One concise sentence with no redundant words. Could include more detail without sacrificing efficiency.

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?

Despite annotations covering safety, the description lacks information on the content of transfer records (e.g., amounts, addresses). No output schema to compensate, leaving agents with 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?

Input schema covers both parameters with descriptions (page, limit). The tool description adds no additional meaning, but schema coverage is 100%, meeting 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 the verb ('Provides'), resource ('on-chain transfer records'), and scope ('ERC-20 for exchanges'), 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?

No guidance on when to use this tool versus alternatives, such as other Coinglass tools. No when-not-to-use or explicit differentiation.

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, but the description adds no extra behavioral context such as data freshness, pagination behavior, or rate limits. It does not go beyond what annotations provide.

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

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

The description is a single concise sentence that front-loads the key information. No unnecessary 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?

Despite a simple tool with 3 parameters and no output schema, the description lacks details on return format, pagination behavior, or how results are ordered. It does not fully compensate for the missing 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 input schema has 100% description coverage, so the description adds no additional meaning beyond the schema. The tool name and description imply the symbol parameter is used for filtering, but no extra context is given.

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 'historical open interest data for options across different exchanges', using a specific verb and resource. It distinguishes itself from other Coinglass tools that focus on different metrics like ETF assets or options 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?

There is no guidance on when to use this tool versus alternatives. Among many Coinglass tools, the description does not clarify scenarios where this particular open interest history is preferred over related tools like getCoinglassOptionsInfo.

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, destructiveHint, and idempotentHint, but the description adds no behavioral context beyond that, such as rate limits, authentication, or error handling.

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?

Single sentence of 14 words that front-loads the purpose, with no unnecessary 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 data retrieval tool with good annotations and schema, the description covers core functionality. Minor missing context about output format but not critical given low 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?

Schema description coverage is 100% with clear descriptions for all three parameters, so the description adds no extra meaning. 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 the tool provides detailed open interest and trading volume for options across exchanges, which is specific and distinguishes it from siblings like futures open interest or ETF 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?

No guidance on when to use this tool versus alternatives like getCoinglassOpenInterestHistory or getCoinglassBitcoinEtfList, nor any when-not-to-use conditions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds no behavioral traits beyond what annotations provide, but it does not contradict them. A 3 is appropriate as the description adds minimal extra 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 a single, focused sentence that conveys the tool's purpose without superfluous words. It is front-loaded and efficient.

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

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

Given the low complexity (2 optional parameters, no output schema, annotations covering behavior), the description adequately explains what the tool returns. No additional details are necessary for an agent to use it correctly.

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

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

Schema coverage is 100% with clear descriptions for page and limit parameters. The description does not add any additional meaning beyond the schema, so baseline 3 applies.

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

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

The description clearly states it provides the Coinbase Bitcoin Premium Index, which is a specific resource that distinguishes it from sibling Coinglass tools like getCoinglassBitcoinEtfList or getCoinglassFutureBasis. The verb 'Provides' is appropriate for a read operation.

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?

No guidance is provided on when to use this tool versus alternatives or when not to use it. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision-making support.

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 disclose the tool as read-only, idempotent, and non-destructive. The description adds the list of returned fields but no additional behavioral caveats such as rate limits or auth requirements. It aligns with annotations without introducing new transparency details.

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 with no filler. The first sentence states the core function and output fields, while the second provides a useful pointer to a complementary tool. Every word earns its place.

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

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

For a simple single-parameter read-only fetch, the description covers the returned metadata fields and the companion tool for market data. With annotations covering safety and the schema covering parameters, no further details are necessary.

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 fully describes the sole parameter 'slug' with an explanation and examples. The description adds no additional parameter-level meaning, but since schema coverage is 100%, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb ('Fetch') and resource ('Bitcoin Ordinals collection's metadata'), and lists the exact fields returned. It also distinguishes itself from siblings by referencing getCollectionMarketInfo for floor/market data, making the scope 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?

The description provides explicit guidance by naming getCollectionMarketInfo as the companion tool for floor/market data. This implies that getCollectionInfo is for static metadata, giving the agent a clear when-not-to-use signal and a direct alternative.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral context by specifying the return content ('Returns inscription IDs and basic metadata'), which is beyond what annotations provide.

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

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

The description is a single, focused sentence that front-loads the action and resource, followed by a brief note on the return value. Every word earns its place with no redundancy.

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

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

For a simple read-only tool with one well-documented parameter and comprehensive annotations, the description fully covers the purpose, input, and return format. No output schema is provided, but the description compensates with the return summary.

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 full coverage for the only parameter (slug) with a clear description and example. The tool description adds no additional parameter-level meaning beyond what the schema documents, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb 'List' with a clearly defined resource: inscriptions belonging to a given Bitcoin Ordinals collection. It explicitly states this is the collection's items, which distinguishes it from sibling tools like getCollectionInfo (collection metadata) and getCollectionMarketInfo (market 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 clearly implies the tool is for retrieving the items of a specific collection, providing context for when to use it. It does not explicitly mention alternatives or exclusions, but the scope is clear enough to guide selection among sibling tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds no additional behavioral traits beyond the data returned; it is consistent but not additive, so a baseline score of 3 is appropriate.

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

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

Two concise sentences, front-loaded with purpose and followed by usage. Every word earns its place; no fluff.

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

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

For a simple single-parameter tool with rich annotations, the description fully specifies what is returned (floor price and market cap in both BTC/sats and USD) and when to use it. No output schema exists, but the description adequately covers expected 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 single parameter 'slug' is fully documented in the schema with a clear description and examples (bitcoin-puppets, nodemonkes). The tool description does not add parameter details, but schema coverage is 100%, so baseline 3.

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

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

The description clearly states the tool retrieves market info for a Bitcoin inscription collection, listing specific metrics (floor price in sats/USD, market cap in BTC/USD). This distinguishes it from sibling tools like getCollectionInfo and getCollectionVolume.

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 timing guidance: 'Use this when user asks about collection prices, valuations, or floor prices.' However, it does not name alternative tools for volume or basic info, so it lacks explicit exclusions/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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that it returns total volume, floor price, supply, owners, and listings, which is useful but does not go beyond that baseline. No additional behavioral traits like error conditions or external dependencies are disclosed.

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 concise sentences, front-loaded with the main verb and resource, and each sentence contributes meaningful information—what it does, what it returns, and when to use it. 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?

With only one required parameter, strong annotations, and a clear description of both behavior and return fields, the description provides a complete picture for an agent. There is no output schema, but the description explicitly lists the returned data, so the agent knows 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 input schema provides 100% coverage for the single collectionSymbol parameter, including examples. The description does not add any parameter-specific meaning, 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 gets trading volume and market stats for a Bitcoin ordinal collection from Magic Eden, and lists the specific data returned. It distinguishes itself by focusing on volume/market statistics, but does not explicitly differentiate from the similar sibling getCollectionMarketInfo, so it falls short of a perfect 5.

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

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

The description includes 'Use this for questions about collection trading activity or volume,' which gives explicit when-to-use guidance. However, it provides no exclusions or alternatives, so it does not earn the full 5 for explicit when-not/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?

Annotations already declare readOnlyHint true, openWorldHint true, idempotentHint true, and destructiveHint false, which align with the description. The description adds no extra behavioral context such as data source, rate limits, or handling of unsupported coins. Since annotations cover the safety profile, a baseline of 3 is appropriate.

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: the first states the core function, the second provides usage context and examples. Every sentence earns its place, with no unnecessary detail.

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, read-only price lookup tool with strong annotations, the description covers purpose, usage, and supported coins. It does not discuss behavior for unsupported coins or return format, but these are minor gaps given the tool's simplicity and the presence 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 input schema provides 100% coverage for coinId, listing all accepted aliases in its description. The tool description repeats some of these examples but does not add meaningful new semantics beyond the schema, so it remains at the baseline for high schema coverage.

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

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

The description clearly states the tool gets the current USD price of major cryptocurrencies and lists specific supported coins (BTC, ETH, SOL, BNB, HBAR). It positions itself as the PRIMARY tool for price questions, which helps differentiate it from other price-related tools in the sibling list.

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

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

The description explicitly says when to use the tool ('Use this when the user asks about the price, value, or worth of...') and provides example queries. It does not explicitly state when not to use it or name alternative tools, but the primary guidance 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that results include incoming/outgoing movements with timestamps and counterparties, and that results are paginated. This is useful but does not disclose additional traits like data freshness or rate limits, and the description does not contradict annotations.

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

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

A single sentence that is front-loaded with the action and includes all key details (incoming/outgoing, timestamps, counterparties, pagination) without any wasted words 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 simple read-only tool with two parameters and good annotations, the description sufficiently explains what the tool returns and mentions pagination. It lacks details on edge cases or return format specifics, but overall it is complete enough for expected usage.

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?

Both parameters have complete schema descriptions: 'bitcoinAddress' is 'Bitcoin address whose inscription activity to retrieve' and 'page' is '1-indexed page number for activity pagination'. Since schema coverage is 100%, the description adds little beyond referencing pagination, which 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 starts with a specific verb and resource ('Return the inscription transfer history for a given Bitcoin address'), and further details incoming/outgoing movements with timestamps and counterparties, plus pagination. This clearly distinguishes it from related tools like getInscriptionsByAddress or getBRC20Activity.

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: when you need transfer history for a Bitcoin address. However, it does not explicitly mention alternatives or exclusions, such as when to use 'inscriptionTransferActivity' or that this is not for current holdings.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive, covering the primary behavioral safety aspect. The description adds the content of the response but no additional behavioral caveats (e.g., error handling, data availability, or ordering). Since annotations carry the safety burden, a score of 3 is appropriate for a simple fetch operation.

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 sentence that states the action (Fetch metadata) and lists the specific data returned. It is front-loaded with the verb and resource, containing no filler or redundant information.

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

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

With no output schema, the description compensates by listing the expected metadata fields, giving the agent a clear picture of the response. It does not describe potential error responses or edge cases (e.g., invalid inscriptionId), but for a simple single-item fetch with one parameter, this level of detail is adequate.

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

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

The schema description for inscriptionId is detailed (format '<txid>i<index>' with example), providing 100% coverage. The tool description does not add further parameter-specific semantics beyond referring to a 'single Bitcoin Ordinals inscription,' so the baseline of 3 is warranted.

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 fetches metadata for a single Bitcoin Ordinals inscription and enumerates the specific fields returned (content type, content URL, owner, satpoint, inscription number, genesis transaction, timestamp). The phrase 'single' distinguishes it from related sibling tools like getInscriptionActivity or getCollectionInfo, 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 implies usage for retrieving detailed metadata of one inscription, which is distinct from activity, traits, or collection-level tools. It provides clear context but does not explicitly exclude alternatives or name sibling tools for contrast, so it falls short of a perfect 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond those: it specifies pagination ('paginated') and the level of detail returned ('fully-detailed'), including specific fields. This complements the annotations without redundancy.

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

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

Two sentences, front-loaded with the primary action and key details, followed by a clear use case. Every word earns its place; 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?

This is a simple read tool with good annotations and complete schema coverage. The description covers purpose, pagination, and return fields, which is sufficient for an agent to select and invoke it. It could mention address format requirements or empty-result behavior, but those are minor gaps 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?

The schema covers both parameters with descriptive explanations (bitcoinAddress and page). The description reinforces that results are paginated and address-specific but doesn't add new semantics 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 uses a specific verb ('Return') and identifies the resource ('Bitcoin Ordinals inscriptions held by a given Bitcoin address') along with key fields ('number, content type, traits, satpoint'). It also adds a use case ('display a wallet's NFT-style holdings') that distinguishes it from other inscription-related tools like getInscriptionInfo or getCollectionInscriptions.

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

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

The description clearly states when to use the tool: 'Use this to display a wallet's NFT-style holdings.' This provides a clear context for usage, though it doesn't explicitly name alternatives or exclusions. That's enough for a clear read-only query tool.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds the empty-array fallback when no traits are indexed, providing a useful behavioral detail beyond the annotations. No contradiction detected.

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, with the action and primary resource front-loaded. Every word earns its place, and there is no redundant filler.

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

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

For a simple one-parameter tool with no output schema, the description explains the return fallback (empty array) and the clear purpose. It does not detail the trait object structure, but given the low complexity and strong schema coverage, this is sufficient for selection and invocation.

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

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

Schema coverage is 100%, with the only parameter clearly documented. The description adds no new parameter semantics, just reinforces that it operates on a single inscription. Baseline 3 is appropriate when schema already provides complete parameter information.

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 'Fetch the trait/attribute set for a single Bitcoin inscription' with a specific verb and resource, and further distinguishes itself by mentioning NFT-style traits for collection rarity ranking. This sets it apart from sibling tools like getInscriptionInfo or getInscriptionActivity.

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 this tool (to retrieve traits for rarity ranking) but does not explicitly name alternatives or state when not to use it. The specialized purpose implicitly guides selection, but explicit exclusions are absent.

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