EmblemAI AgentWallet

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond annotations by explaining the flexible sellAmount formats (token units, USD budget, 'max') and the return type (normalized conditionalOrderHandoff). This gives the agent useful behavioral details without contradicting annotations.

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

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

Two sentences, front-loaded with the primary action, and every clause informs usage. No filler or repetition of schema fields. The description is efficiently 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 moderate complexity, the description covers the core purpose, input flexibility, chain, and output type. No output schema exists, but the description explains what is returned. It does not mention slippage or exact-output alternatives, but for a quote tool with strong annotations and detailed schema, this is adequately complete.

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

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

The input schema has 100% coverage with detailed descriptions for sellAmount, including the 'Never convert a user's USD budget yourself' instruction. The tool description essentially repeats the sellAmount semantics and adds the return type context. It does not add meaning to buyTokenAddress or sellTokenAddress beyond what the schema already states. Baseline 3 is appropriate since the schema already 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 uses a specific verb ('Quote'), states the resource ('Base swap'), and clarifies the scope ('exact-input'). It clearly distinguishes from sibling swap quote tools by naming 'Base' and the input type. The phrase 'for explicit entry or exit orders' adds further specificity.

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

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

The description gives clear context: it quotes exact-input Base swaps and mentions the output (conditionalOrderHandoff) suitable for entry/exit orders. It does not explicitly say 'use this for Base chain, not for other chains', but the 'Base' keyword and the existence of sibling tools like ethSwapQuote and bscSwapQuote make the intended context clear. No exclusions or alternatives are mentioned, which is acceptable for a quote tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, signaling a safe read operation. The description adds useful scoping by specifying supported chains and the Hedera exclusion, but it doesn't disclose other behavioral aspects such as return format, rate limits, or whether trade data is real-time/historical. With annotations covering safety, the description provides a moderate layer of additional context.

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

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

The description is concise and front-loaded with the core purpose in the first sentence. The chain list is compactly embedded, and the exclusion is one clear sentence with a direct alternative. Every sentence earns its place without redundancy or 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 2-parameter tool with excellent schema coverage and annotations, the description is sufficient for correct invocation: it names the data (trade data), the target (token), supported chains, and the unsupported chain with an alternative. No output schema exists, but the phrase 'detailed trade data' gives enough context, though slightly vague on the exact fields or time range. Overall, the description is complete enough for its complexity level.

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

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

Schema description coverage is 100% for both parameters (address and chain), so the schema already documents each parameter fully. The description repeats the chain list and notes Hedera exclusion, which aligns with the schema's chain enum and description, but adds no new parameter-level meaning beyond what the schema provides. 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 function: 'Get detailed trade data for a specific token from Birdeye.' The verb 'Get' is specific, the resource 'detailed trade data' is unambiguous, and the target 'specific token' is precise. It distinguishes from sibling tools like birdeyeTrendingTokens (trending, not trade data) and solanaGetTokenPrices (prices, not trade data) by focusing on trade data, and also clarifies the scope of supported 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 explicitly lists supported chains and explicitly names an unsupported chain with an alternative: 'NOT supported: Hedera (use hederaTokensSwapQuote instead).' This provides a clear when-not-to-use and points to the correct alternative tool. The chain enum in the schema further reinforces the usage context, making it obvious when this tool is applicable.

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 contributes only 'real-time price and market data' as an output expectation, not behavior such as ordering, pagination, limits, or rate-limit implications; there is 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, front-loaded sentence with no redundant phrases; every clause communicates source, data type, and capability.

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 list tool with strong annotations and full schema coverage, this description is mostly sufficient: it names the data source, output type, and configurable aspects. The minor gaps are the absence of a return-shape outline and no mention of behavior when optional parameters (especially chain) are omitted, but the schema compensates for most of this.

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 chain, limit, offset, sortBy, and sortType are already documented with types, enums, and bounds. The description's mention of chains and sorting options only restates the schema and adds no extra semantic detail such as default chain behavior.

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

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

The description uses a specific verb ('Get') with a clearly scoped resource ('trending tokens from Birdeye') and adds meaningful qualifiers ('real-time price and market data', 'multiple chains', 'sorting options'). It distinguishes itself from ambiguous siblings like getTrendingCoins by naming the Birdeye source.

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 use case is implied: when an agent needs Birdeye trending tokens with live market data. However, it does not explicitly state when to prefer this over related siblings such as getTrendingCoins or birdeyeTradeData, nor does it mention exclusions or prerequisites.

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=true and destructiveHint=false, making the read-only nature clear. The description adds useful context about sellAmount flexibility ('$5', 'max') and the normalized return format ('conditionalOrderHandoff'), which goes beyond the schema. No contradictions found.

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

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

The description is two sentences, front-loaded with the primary action and immediately useful details about parameter formats and return type. No filler or redundancy.

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

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

The description covers the purpose, key parameter flexibility, and return type, but leaves gaps: buyTokenAddress and sellTokenAddress are optional in the schema yet logically needed for a swap, and the meaning of 'conditionalOrderHandoff' is undefined (no output schema). For a moderate-complexity tool, more prerequisite or return context 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 description coverage is 100%, and the schema already details sellAmount's formats and units. The description restates the sellAmount flexibility but adds no new parameter-level information beyond what's in the schema. It does clarify exact-input semantics, which is consistent with the schema's 'spend' interpretation.

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 and resource: 'Quote an exact-input BSC swap.' It distinguishes from sibling chain-specific quote tools (e.g., ethSwapQuote, polygonSwapQuote) by naming BSC and specifying exact-input, and it adds precision by mentioning the return type.

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: it's for BSC swaps with exact input amounts, and it notes the output is for 'explicit entry or exit orders.' However, it does not explicitly contrast with alternatives like exact-output quotes or other chains, relying on the title/name for 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 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 declare readOnlyHint=true and idempotentHint=true, so the safe, non-destructive nature is covered. The description adds value by revealing that the tool returns 'a normalized conditionalOrderHandoff' and that sellAmount can be a USD budget or 'max', which are behavioral details not present in the annotations.

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

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

The description is two sentences long, front-loaded with the core purpose, and includes only essential details about sellAmount flexibility and the return type. Every sentence 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?

The description mentions the return type (conditionalOrderHandoff) which compensates for the lack of an output schema. However, it does not explain how buy/sell token addresses are determined or what happens if they are omitted, which is a minor gap given the tool's complexity but not critical due to strong annotations and 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 coverage is 100%, and the schema already provides a detailed description for sellAmount (including USD budget and 'max'). The tool description restates this but adds no new parameter-level information beyond what the schema provides. 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 opens with 'Quote an exact-input Ethereum swap,' which is a specific verb (Quote) + resource (Ethereum swap) + qualifier (exact-input). This clearly distinguishes it from sibling chain-specific tools like bscSwapQuote and polygonSwapQuote. The additional mention of 'explicit entry or exit orders' further clarifies its intended use case.

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

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

The description gives clear context by specifying 'exact-input' and 'explicit entry or exit orders,' which helps the agent understand when to use this tool. However, it does not explicitly contrast it with other swap quote tools or state when not to use it, so it falls short of a 5.

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

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

Annotations already 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds useful context about cross-network scope and the optional status filter. However, it does not disclose potential behavioral traits such as pagination, rate limits, or response size, which would be valuable for a tool that fetches 'ALL' positions. Similar to the TDQS 4.3 example, this adds some value 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 two sentences, front-loaded with the core purpose and scope, followed by the optional filter. Every word earns its place; there is no redundancy 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?

For a simple read-only tool with rich annotations and a single optional parameter, the description is largely complete. It identifies the networks, the filter options, and the all-in-one nature. However, it does not describe the return format or any caveats about result size, and it lacks explicit differentiation from listPositions, which slightly reduces 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?

The only parameter 'status' is already fully described in the schema with an enum list and a description. The tool description repeats the enum values in prose, which is marginally helpful but adds no new semantic depth. With 100% schema coverage, 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 uses a strong verb ('Get') and specifies the resource ('conditional trade positions') with an explicit scope ('ALL networks... in a single call'). It clearly distinguishes itself from siblings like findPositionById (which targets a specific position) and getPolyMarketUserPositions (which is user-specific and limited to Polymarket).

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 use case: retrieve all conditional trade positions across all supported networks at once. It states the optional status filter, providing context on how to narrow results. However, it does not explicitly mention when not to use it or point to alternatives (e.g., listPositions for a specific network), leaving a small gap in usage guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, providing the safety profile. The description adds no additional behavioral context such as rate limits, return shape, or edge cases. It does not contradict annotations, but does not enrich 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 a single, concise sentence that fully conveys the tool's purpose without unnecessary words. It is efficiently front-loaded and contains 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 simple with two parameters, rich annotations (read-only, idempotent, non-destructive), and full schema coverage. Despite lacking an output schema, the description, combined with annotations and schema, provides sufficient context 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?

Input schema has 100% description coverage for both parameters (query and networks). The description does not add further parameter-level detail, but the schema already explains them adequately, 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's function: 'Get supported currencies for cross-chain swaps'. It uses a specific verb (Get), identifies the resource (supported currencies), and provides context (cross-chain swaps). This distinguishes it from sibling tools like getChangeNowSwapQuote, which handles quotes rather than supported currency listings.

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 checking supported currencies before cross-chain swaps, but does not explicitly state when to use it versus alternatives or mention exclusions. The sibling getChangeNowSwapQuote is present but no guidance is given for choosing between them.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds a useful behavioral constraint not in the schema: that tickers must be supported by ChangeNow. This provides extra context about potential failures without contradicting 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 two concise sentences, directly stating the purpose and a key constraint. There is no redundant language or filler, making it highly scannable and appropriate for an agent.

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 parameter set (three string/number params, 100% schema coverage) and the presence of safety annotations, the description provides sufficient context for basic usage. However, since there is no output schema, the description could be slightly more explicit about the return value (e.g., that it returns an estimated rate and payout). The mention of 'swap quote' partially covers this, but not entirely.

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 all three parameters with clear descriptions and examples (e.g., fromTicker as 'eth'). The description adds a notable constraint that tickers must be supported by ChangeNow, which is a semantic requirement beyond the schema's basic type descriptions. While the description doesn't elaborate on the fromAmount semantics, the schema already handles that.

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 ('Get') and resource ('swap quote'), clearly indicating a cross-chain exchange context. It also names the platform (ChangeNow) and adds a constraint ('Tickers must be supported by ChangeNow'), which helps distinguish it from sibling swap-quote tools like baseSwapQuote or ethSwapQuote.

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 'cross-chain exchange' clearly implies this tool is for cross-chain swaps rather than same-chain quotes, giving the agent a sense of when to use it. However, it does not explicitly name alternatives or state when not to use it, so it falls short of an explicit when/when-not/alternatives rubric.

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.

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

Beyond the annotations (readOnly, non-destructive, idempotent), the description adds that the tool operates network-wide and defaults to newest-first ordering. It also clarifies that address-specific queries are out of scope, providing 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?

The description is two sentences, front-loaded with the core purpose and immediately followed by usage guidance. 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 three-parameter read-only list tool, the description covers purpose, scope, and usage boundaries. It does not describe return values (no output schema), but that is reasonably implied and not a critical gap for this tool.

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

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

Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds a small semantic detail that the newest-first sort is the default, but it doesn't meaningfully elaborate on the after/before cursors.

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: browsing the most recently created Bitcoin Ordinals inscriptions network-wide, with default newest-first ordering. It also explicitly differentiates from address-specific lookups, distinguishing it from sibling tools like getInscriptionsByAddress.

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

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

It explicitly states when to use ('to discover newly-minted inscriptions') and when not to ('NOT to look up inscriptions on a specific address'). However, it does not name specific alternative tools, relying on the sibling list for that.

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 true, and destructiveHint false. The description adds the 'market discovery and browsing' framing but doesn't disclose pagination semantics, how 'latest' is defined (block height, timestamp), or any rate limit. It adds some 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?

Two sentences, front-loaded with the primary action. The second sentence adds usage guidance without any redundancy or fluff.

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

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

With no output schema and 3 parameters, the description should clarify return format and pagination. It doesn't mention that 'after'/'before' are likely pagination cursors, nor does it describe the shape of the returned token list. An agent would struggle to know how to use the optional parameters effectively.

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 hints at sorting via 'latest' and 'new/trending' but doesn't explain the required 'sort' parameter's behavior or the optional 'after'/'before' cursors. The enum values in the schema give some meaning, but no param-level guidance is provided.

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

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

The description uses a specific verb and resource ('List the latest Rune tokens') and clearly distinguishes this from personal-balance tools like getRuneBalances. It also differentiates from market-cap/volume ranking tools by focusing on temporal recency (latest/new/trending).

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

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

It provides an explicit when-to-use ('when user wants to see new/trending Runes') and a when-not-to-use ('NOT for checking their personal balance'). However, it doesn't name a specific alternative tool (e.g., getRuneBalances), which prevents a perfect score.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering safety. The description adds no extra behavioral traits beyond the ecosystem and trading context, which is acceptable given the strong annotation coverage. 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 concise sentence with no redundant words. It front-loads the key identifying information (ecosystem and purpose) and avoids filler, 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 simple read-only nature, rich annotations, and fully documented schema, the description is adequate. It doesn't detail the return format, but no output schema exists and the tool is straightforward. The pagination and sort options are already in the schema, so the description's brevity is acceptable.

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 all four parameters having meaningful descriptions. The tool description adds no additional parameter semantics, but the schema is sufficient, so the baseline 3 applies.

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

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

The description clearly identifies the tool as an 'Emblem ecosystem trading leaderboard', specifying the resource (leaderboard) and scope (Emblem ecosystem). It distinguishes from sibling leaderboard tools like nansen_pnl_leaderboard by the ecosystem qualifier. However, it lacks an explicit verb like 'get' or 'list', relying on the tool name for action.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention exclusions or mention sibling tools. The only implied usage is that it serves leaderboard data for the Emblem ecosystem, but there is no explicit context or comparison to other leaderboard or ranking 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 the tool as read-only, open-world, idempotent, and non-destructive. The description adds little behavioral context beyond the alternative source and fallback use case, but 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?

Two sentences deliver purpose and usage guidance with no wasted words. The key information is front-loaded and easy to scan.

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

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

For a simple one-parameter read-only tool with strong annotations and a clear fallback use case, the description is largely complete. It does not explain what 'market data' includes, but that is a minor gap.

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

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

Schema coverage is 100%, and the parameter description already explains the runeName format. The tool description does not add any further meaning 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?

The description clearly states the tool gets rune market data from Magic Eden, explicitly identifying it as an alternative data source. This distinguishes it from sibling tools like getRuneMarketInfo and getRuneInfo.

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

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

It provides explicit guidance on when to use this tool: 'Use this if Ordiscan returns zero prices for a rune.' This clearly defines the fallback scenario and differentiates it from other rune 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations: it is 'Lightweight ID-only response', implying limited payload and no metadata, which helps the agent understand response characteristics.

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 the core action. The second sentence adds a clear alternative without unnecessary detail. Every word contributes 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 read-only tool with one parameter and rich annotations, the description is complete enough. It states the input, the output (list of IDs), and the alternative for richer data. However, it does not describe edge cases (e.g., empty address results) or return format details, which would be expected if no output schema existed.

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

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

The input schema covers the single parameter bitcoinAddress with a clear description ('Bitcoin address whose owned inscription IDs to fetch'), so coverage is 100%. The tool description does not add extra parameter-level meaning beyond what the schema already provides, hence 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?

The description explicitly states the verb and resource: 'Return the list of Bitcoin Ordinals inscription IDs owned by a given Bitcoin address.' It clearly distinguishes from sibling getInscriptionsByAddress by noting this is a 'Lightweight ID-only response' versus full metadata.

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: use this tool when only inscription IDs are needed, and explicitly recommends getInscriptionsByAddress for full metadata. This directly addresses when-to-use and 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, openWorldHint, idempotentHint, and destructiveHint=false, covering safety. The description adds 'detailed info' but does not specify what fields are returned or any additional behavioral nuances. It is not misleading, but contributes little 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 concise sentence that gets straight to the point. No wasted words 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?

For a simple one-parameter tool with good annotations and no output schema, the description is sufficient to understand the tool's purpose and primary input. However, 'detailed info' is vague; specifying what details are included would improve 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?

The schema covers 100% of the parameter with 'Event slug (from event.slug)', so the baseline is 3. The description only repeats 'by slug' without adding extra meaning or usage details for the parameter.

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

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

The description clearly states the action ('Get'), the resource ('detailed info for a specific Polymarket event'), and the identifier ('by slug'). This distinguishes it from siblings like getPolyMarketEvents, getPolyMarketEventsByTag, and searchPolyMarketEvents.

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 'by slug' clearly indicates when to use this tool: when you already have a specific event slug. It does not explicitly mention alternatives or exclusions, but the usage context is clear from the description alone.

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 'compacted data' as behavioral context, but does not mention pagination, default ordering, or the effect of filters. This is moderate added value 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 two short, front-loaded sentences with no filler. Every word earns its place, making it highly concise and scannable.

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

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

With 6 optional parameters and no output schema, the description is too sparse. It lacks information on sorting, pagination, filtering, or the relationship to sibling tools. Annotations help with safety but not with usage completeness, leaving the agent under-informed for a tool with this 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 only 33%, and the description adds no parameter semantics. limit and tag_id are described in the schema, but order, offset, featured, and ascending have no explanation, and the description does not compensate for this 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 a specific action ('Get') and resource ('Polymarket events list'), and adds a useful behavior hint ('compacted data'). However, it does not distinguish from sibling tools like getPolyMarketEventsByTag or searchPolyMarketEvents, so it falls short of a 5.

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

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

No guidance on when to use this tool vs alternatives such as getPolyMarketEventsByTag or searchPolyMarketEvents. The description provides no context about filtering, sorting, or use cases, leaving the agent to infer applicability.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds little beyond the name itself; it does not disclose additional behaviors like pagination, ordering, or rate limits. It is not contradictory but offers marginal behavioral context.

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

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

The description is a single, clear sentence with no filler or redundant information. It is appropriately concise and immediately communicates the tool's purpose.

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 filtered-list tool with two parameters and strong annotations, the description is adequate. It does not explain return format, but no output schema exists and the operation is a straightforward read. The caveat is that it does not mention potential quirks like results ordering or default limit behavior beyond schema defaults.

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?

Only 50% of schema parameters have descriptions (tagId is described in the schema; limit is not). The tool description adds some semantic meaning by indicating filtering by tag/category, but it does not clarify the limit parameter. The schema's tagId description provides the essential linkage to getPolyMarketTags.

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

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

The description states the specific action ('Get') and resource ('Polymarket events') and explicitly mentions the filtering criterion ('by tag/category'). This clearly distinguishes it from sibling tools like getPolyMarketEvents (all events) and searchPolyMarketEvents (search-based).

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 when a tag/category is known, but it does not explicitly state when to use this tool versus alternatives. The schema's tagId reference to getPolyMarketTags provides some context, but no exclusions or alternative recommendations 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description simply restates 'Get' and adds no behavioral details beyond what annotations provide—no mention of rate limits, output format, or usage context. It is consistent with annotations, but adds no 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 extremely concise—seven words—and directly states the purpose. Every word is necessary, and it is front-loaded with the verb and resource. No fluff, no repetition of schema or annotations.

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 no-parameter, read-only tool with no output schema, the description is reasonably complete: it names the resource being fetched. However, it could add a bit of context about how the returned categories/tags relate to other Polymarket tools (e.g., that they can be used with getPolyMarketEventsByTag). Given the simplicity of the tool, this is a minor gap.

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

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

The tool has zero parameters, so there is no parameter semantics burden on the description. With 0 params and 100% schema coverage, the baseline is 4, and the description does not need to explain any parameters. It appropriately focuses on the operation only.

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 Polymarket categories/tags' clearly identifies the resource (Polymarket categories/tags) and action (get). It distinguishes from sibling tools like getPolyMarketEvent or getPolyMarketEventsByTag by focusing on the list of available tags/categories rather than events or positions. However, it could be slightly more specific about what is returned (e.g., a list of all available tags).

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 such as getPolyMarketEventsByTag or searchPolyMarketEvents. The description doesn't mention that this tool could be used to fetch the list of tags that can then be used to filter events, which would be helpful context. No exclusions or alternative recommendations 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context, such as pagination behavior, sorting options, or the structure of returned positions.

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 short and front-loaded, but it is under-specified rather than effectively concise. For a tool with four parameters and no output schema, this single sentence does not earn its place as useful guidance.

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, four parameters, and a large sibling set, the description is incomplete. It does not describe the return format, position fields, or how pagination and sorting work, leaving significant gaps for an agent to invoke the tool correctly.

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

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

Schema coverage is 50% (only limit and offset have descriptions; sortBy and sortOrder lack them). The description provides zero parameter information and does not compensate for the undocumented sort parameters, leaving their meaning and defaults unexplained.

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 user's Polymarket positions' states a specific verb, resource, and scope, distinguishing it from event/market listing tools. However, it does not clarify its relationship to similarly-named siblings like getAllPositions or listPositions, so it lacks explicit sibling differentiation.

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

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

No guidance is given on when to use this tool versus alternatives. The description relies entirely on the tool name and does not explain which sibling tools are better for other scenarios, such as fetching all positions or finding a specific position.

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, reducing the description's burden. The description adds the notion of token lifecycle stages but nothing about filtering behavior, defaults, or response format. 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 short sentence, but it under-specifies a tool with 25 parameters. It adds little beyond the tool name and is an example of under-specification rather than effective 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?

For a highly complex tool with 25 parameters and no output schema, the description is severely inadequate. It lacks any mention of return values, default filters, or operational context, making it nearly impossible for an agent to use effectively.

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 only 32%, leaving the majority of 25 parameters underdocumented. The description provides no parameter explanations beyond the enum values for 'type' already present in the schema, so it does not compensate for the low 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?

Description clearly states it queries PumpFun tokens, specifying lifecycle stages: new, graduating, graduated. It is a clear verb+resource statement, though it does not differentiate from sibling token tools like findSolanaGems or birdeyeTrendingTokens.

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 the many sibling token query tools. No alternatives, exclusions, or context 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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the specific categories of rare sats and the address-level scope, but it does not disclose additional behavioral traits such as pagination, error handling, or response format. It is consistent with annotations and adds modest context, but falls short of rich behavioral disclosure.

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 the action front-loaded. It wastes no words and every sentence contributes meaning: the first states what the tool does, the second states its value. No verbosity or redundancy.

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

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

Given the tool's low complexity (one parameter, fully described in schema), rich annotations, and lack of an output schema, the description is complete for an agent to understand what the tool does, when to use it, and what input is required. It does not need to explain return values since none are structured, and the description implies a list. The tool is a read-only, idempotent lookup, and the description covers the essential 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?

With 100% schema description coverage, the schema already fully documents the single parameter 'bitcoinAddress'. The description reinforces its meaning by linking it to 'rare sats' and 'evaluating sat rarity holdings', but it does not add new syntax, constraints, or formats beyond what the schema provides. 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 action ('List'), the resource ('rare sats'), and the specific scoping ('controlled by a given Bitcoin address'). It also enumerates the rarity categories (uncommon, rare, epic, legendary, named single-satoshi units), making the tool's purpose unambiguous and distinguishing it from sibling tools like rareSatsForUTXO and getSatRangesForUTXO, which operate at UTXO level.

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 a clear use case: 'Useful for collectors evaluating sat rarity holdings.' This gives context for when to use the tool, but it does not explicitly mention alternatives (e.g., rareSatsForUTXO) or situations where it should not be used. Since it offers a clear context without exclusions, it merits 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, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by specifying return fields (asset name, image preview, creator, timestamp) and ordering behavior, which is useful beyond the structured metadata.

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 purpose and use cases, with zero unnecessary words. Every sentence contributes to understanding the tool's function and context.

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 listing tool with one optional parameter, the description covers return fields, ordering, and typical use cases. The schema handles parameter constraints, and annotations confirm safety. Minor gaps like pagination details are not critical for this tool's simplicity.

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

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

Schema coverage is 100% for the single 'limit' parameter, including default, maximum, and description. The description does not add parameter-specific semantics, but the schema already provides complete documentation, 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 the tool's verb ('browse') and resource ('recently issued Bitcoin Stamps') with explicit ordering ('newest first'). It distinguishes itself from sibling tools like getStamp, getStampsByAddress, and searchStamps by focusing on recency and discovery.

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

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

Provides explicit use cases ('activity feeds and what's new surfaces') and frames the tool for discovery, giving clear context for when to use it. It doesn't name alternative tools, but the guidance is sufficient to differentiate from similar stamp-related functions.

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 this as a read-only, idempotent, open-world, non-destructive operation, so the safety profile is well-covered. The description adds minimal behavioral context beyond that; it doesn't specify return format, pagination, or any special behavior regarding unconfirmed balances or error conditions. Given the annotations, a 3 is appropriate as no contradictions exist, but the description doesn't enrich the behavioral picture significantly.

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 one concise sentence with no wasted words. It is front-loaded with the action and resource, making it easily scannable.

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

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

The tool is simple with one parameter, and the schema provides full parameter details. However, there is no output schema, so a brief mention of what the response contains (e.g., list of rune balances with amounts) would improve completeness. Annotations cover the behavioral safety aspects, and the description succinctly states the purpose, so it is adequate but not thorough.

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 100% of the parameter documentation, with bitcoinAddress described as 'The Bitcoin taproot address to check rune balances for'. The description adds no extra semantics beyond the schema, aligning with the baseline 3 for high schema coverage. The parameter is simple and well-documented by 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 states a specific verb ('Get') and resource ('Rune token balances'), clearly indicating it retrieves Rune balances for a user. It could potentially be confused with getUtxoRunes or getRuneInfo, but the focus on 'user's' balances, singular address input, and the title prefix helps distinguish it from general rune info or UTXO-specific queries, though it does not explicitly name 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 implies usage for checking a user's rune balances given a Bitcoin address, and the schema requires bitcoinAddress. However, it doesn't explicitly state when to use this versus similar tools like getUtxoRunes or getRunesActivity, nor does it provide exclusions or alternative tool recommendations.

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

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

Annotations already establish that the tool is read-only, non-destructive, and idempotent, reducing the burden on the description. The description adds value by enumerating the returned metadata fields, which is a useful behavioral context beyond simple safety flags. However, it does not disclose any additional traits such as error handling, rate limits, or network dependencies, so it remains at the baseline for annotation-backed descriptions.

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

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

The description is a single, efficient sentence that front-loads the purpose and lists concrete outputs without redundant words. Every word contributes meaning, making it an excellent example of concise tool documentation.

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 no output schema, the description is largely complete: it specifies the input, the kind of data fetched, and explicitly lists the expected return fields (which substitutes for a missing output schema). However, it omits any note about error behavior (e.g., unknown rune names) which could be helpful, though not strictly necessary given the tool's straightforward nature.

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 complete documentation for the sole parameter 'name', including case-insensitivity, automatic spacer stripping, and an example ('DOG•GO•TO•THE•MOON' or 'DOGGOTOTHEMOON'). With 100% schema description coverage, the description itself need not add further detail. This matches the baseline of 3 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 starts with a specific verb ('Fetch') and identifies the resource ('protocol-level metadata for a Rune token by name'), then explicitly lists the fields returned (ID, supply, divisibility, symbol, premine, etching transaction, lock height). This clearly distinguishes it from sibling tools like getRuneBalances or getRuneMarketInfo which target different aspects of Rune 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 implies usage for fetching Rune metadata by name, but it provides no explicit guidance on when to use this tool versus alternatives (e.g., getRuneBalances, getRuneMarketInfo) or any exclusions. With multiple Rune-related sibling tools, a brief note about which scenarios call for this tool would strengthen the score.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that it returns price and market cap, but does not disclose additional behavioral traits like rate limits or response structure. This is baseline for a read-only tool with good 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, front-loaded sentence: 'Get the market info for a given rune name: price, market cap.' It conveys the essential purpose without redundancy or 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?

This is a low-complexity tool with one parameter and no output schema. The description clearly states what it returns, and the annotations cover safety. It is complete 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 coverage is 100%, and the schema describes the 'name' parameter including auto-removal of spacers. The description does not add parameter semantics beyond what the schema already provides, 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 uses a specific verb ('Get') and clearly identifies the resource ('market info for a given rune name') and the return content ('price, market cap'). This distinguishes it from related tools like getRuneInfo (general info) and getTopRunesByMarketCap (ranked lists).

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 when you have a specific rune name and need price and market cap data. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context beyond that by specifying the activity types covered, the returned fields (timestamps, amounts, counterparties), and pagination. 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?

Two concise sentences, front-loaded with the main purpose, followed by supporting details about activity types and output fields. 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 read-only tool with two well-described parameters and no output schema, the description covers the essential information: what the tool returns, the input, and pagination. It lacks details like page size or error handling, but these are not critical for selection and invocation. The annotations provide strong safety 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?

Schema coverage is 100% with both parameters explicitly described (bitcoinAddress and page). The description does not add significant extra meaning beyond the schema; it just restates the address input and mentions pagination, which the schema already covers. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Return') and clearly identifies the resource ('Rune transfer history') and input ('given Bitcoin address'). It also enumerates the activity types included (etching, mints, sends, receives) and the fields returned, making it distinct from sibling tools like getRuneBalances or getRuneInfo.

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 conveys the use case: when you need an address's rune transfer history. It does not explicitly state when not to use it or mention alternatives, but the context is clear enough that an agent can infer when this tool is appropriate compared to balance or info 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 the tool safe (read-only, idempotent, non-destructive), lowering the burden. The description adds the detail of 'satoshi-by-satoshi composition', which is a behavioral trait, but it doesn't disclose other aspects like rate limits or output format. This aligns with the baseline for well-annotated tools.

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 function in the first sentence and use cases in the second. Every word earns its place with no redundancy or 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, read-only tool with one well-described parameter and clear annotations, the description is complete. It explains what the tool returns and why it's useful, so an agent can select and invoke it correctly.

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

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

Schema coverage is 100% and the schema already explains that utxoId is in 'txid:vout' form. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool returns 'ordinal-numbered sat ranges contained in a single UTXO', using a specific verb and resource. It distinguishes itself from sibling tools like rareSatsForUTXO by emphasizing the full composition rather than just rare sats.

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

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

The description gives explicit use cases ('ordinal theory analysis and rare-sat lookups'), providing clear context for when to use it. However, it does not mention alternatives or when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which is consistent with 'Fetch metadata.' The description adds valuable context beyond annotations by specifying the kinds of data returned (deploy info, max supply, mint progress, holder count, creator) and clarifying the token standard. No contradictions with annotations; it enriches the behavioral picture.

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: the first packs the action, resource, scope, and output fields; the second adds brief context about the standard. Every word earns its place, with no redundancy or 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 single-parameter read-only tool, the description covers the core behavior and lists the returned metadata categories, even without an output schema. It does not describe return format or error conditions, but the tool's simplicity and the annotations (read-only, idempotent) reduce the need for more. Sibling tools like searchSRC20Tokens and getBRC20TokenInfo provide ecosystem 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?

Schema coverage is 100% for the single parameter 'tick,' with a thorough description including format and case-insensitivity. The description only restates that it fetches 'by ticker,' adding little meaning beyond the schema. Baseline 3 is appropriate since the schema carries the full semantic burden.

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 the specific verb 'Fetch' and clearly identifies the resource: metadata for a single SRC-20 token by ticker. It also lists the exact metadata fields (deploy info, max supply, mint progress, holder count, creator) and distinguishes this from BRC-20 by noting SRC-20 is the Stamps protocol equivalent, which helps differentiate it from sibling tools like getBRC20TokenInfo.

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 its use case (fetch metadata for a single SRC-20 token by ticker) but provides no explicit guidance on when to use this tool versus alternatives such as searchSRC20Tokens or getBRC20TokenInfo. There are no when-not-to-use instructions or named alternatives, so the usage context is only implied.

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, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds meaningful context beyond annotations by explaining the Bitcoin Stamp protocol and listing the metadata fields returned, including 'if any' for SRC20 association. No contradictions exist.

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 fluff. The first sentence front-loads the action and result fields; the second provides useful protocol background. Every sentence earns its place.

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

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

Given the tool's simplicity (single parameter, no output schema), the description is complete. It covers what the tool does, the key return fields, and the underlying protocol context. The schema fully documents the only parameter, making this a well-rounded, self-sufficient description.

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

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

Schema coverage is 100%, with the stampId parameter fully described as a numeric, sequentially assigned ID. The description's 'by ID' adds no new syntax or semantic detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb ('Fetch') and resource ('metadata for a single Bitcoin Stamp') scoped by ID. It enumerates the exact data fields returned (image data, creator address, block height, asset name, SRC20 association), which clearly differentiates it from sibling tools like getRecentStamps, getStampsByAddress, or searchStamps.

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