Server Quality Checklist

Tool Scores

• get_trending_cryptoC
  2.6/5.0
  Behavior2/5

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

  With no annotations, the description must carry full behavioral disclosure. It only mentions the $0.001 per request cost, which is useful, but it does not describe what the response contains, whether results are sorted, rate limits, or any side effects. This incomplete disclosure leaves the agent guessing about the tool's behavior.

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

  Conciseness5/5

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

  The description is extremely concise: one short sentence for the purpose and one for the cost. Every word earns its place, and the format is front-loaded.

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

  Completeness2/5

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

  Given no output schema and no parameter schema, the description must explain what the generated response looks like, but it does not. An agent would not know whether the result is a list of symbols, names, or objects with prices. The tool is simple, but the description is incomplete for effective invocation.

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

  Parameters4/5

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

  The tool has zero parameters and the schema coverage is 100% trivially. The description appropriately avoids adding parameter details, so the baseline of 4 applies.

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

  Purpose2/5

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

  The description 'Get trending cryptocurrencies' is essentially a restatement of the tool name 'get_trending_crypto' with no additional scope or distinguishing details. It does not differentiate from sibling tools like 'get_crypto_markets' or 'search_crypto', making it minimally informative.

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

  Usage Guidelines2/5

  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 'search_crypto' or 'get_crypto_markets'. The description implies a use case for trending data but explicitly lacks any when-to-use or when-not-to-use context.

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

• get_crypto_historyB
  3.1/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden of behavioral disclosure. It only mentions cost per request ($0.003), but does not state whether the operation is read-only, how results are returned, potential error conditions, or rate limits. The 'Get' verb implies read access, but significant behavioral context is missing.

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

  Conciseness5/5

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

  The description is a single clear sentence followed by a cost note. Both elements earn their place: the purpose is front-loaded, and the pricing is critical for cost-aware agents. There is no wasted text, making it highly concise and well-structured.

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

  Completeness3/5

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

  Given the tool has three parameters, one required, and no output schema, the description should ideally explain the return format or data granularity. It does neither, leaving the agent uncertain about what response to expect. While the schema handles parameter definitions, the lack of return-value details makes the description only minimally complete for a historical data tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already documents all three parameters (id, days, currency) with descriptions and constraints. The tool description adds no additional parameter meaning beyond the schema, which is the baseline score of 3. It does not enhance understanding of how parameters interact with the historical data retrieval.

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

  Purpose4/5

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

  The description clearly states the tool retrieves historical price data for a cryptocurrency, using a specific verb ('Get') and resource ('historical price data'). This distinguishes it from siblings like 'get_crypto_price' which likely targets current prices. However, it lacks details on the time series format or granularity, making it slightly less explicit than ideal.

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

  Usage Guidelines2/5

  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 such as 'get_crypto_price' or 'get_crypto_markets'. It does not mention exclusions, prerequisites, or scenarios where a different tool would be more appropriate. Usage must be inferred entirely from the tool name and sibling set.

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

• get_crypto_priceB
  3.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It adds the cost per request ($0.001), which is a useful operational detail not present elsewhere. However, it does not mention rate limits, response format, or explicitly confirm the read-only nature, though the verb 'get' implies it. The cost disclosure earns a mid-range score.

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

  Conciseness4/5

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

  The description is extremely concise at two sentences with no wasted words. It front-loads the core action and then adds the cost detail. However, it is slightly under-specified for a tool with four parameters, so it doesn't earn a perfect 5.

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

  Completeness2/5

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

  The tool has four parameters, no output schema, and no annotations, yet the description is minimal. It does not describe the return value, usage context, or how it differs from similar crypto tools. Given the abundance of sibling tools, this lack of contextual information makes it incomplete.

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

  Parameters3/5

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

  The input schema has 100% parameter description coverage, clearly specifying ids, currencies, include_24h, and include_mcap. The description itself adds no parameter-specific semantics, so the baseline score of 3 applies. The cost note is unrelated to parameter meanings.

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

  Purpose4/5

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

  The description clearly states the action ('Get current prices for cryptocurrencies') with a specific verb and resource. It does not explicitly differentiate from sibling tools like get_crypto_markets or get_token_prices, but the resource is unambiguous. The cost note adds a minor extra context.

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

  Usage Guidelines2/5

  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 such as get_crypto_markets or get_token_prices. No exclusions, prerequisites, or contextual triggers are mentioned, leaving the agent to infer usage solely from the tool name.

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

• get_from_ipfsB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure, but it only mentions the action and cost. It does not state that this is a read-only operation, mention potential errors, or describe the format or limitations of the returned content.

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

  Conciseness5/5

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

  The description is a single sentence that front-loads the core purpose, followed by a useful pricing note. There is no wasted wording or redundant content.

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

  Completeness2/5

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

  The tool is simple, but with no output schema and no annotations, the description should explain what the caller receives (e.g., content type, status codes) and any limitations. It omits these details, leaving the tool underspecified for an agent relying solely on this description.

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

  Parameters3/5

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

  Schema coverage is 100% with the parameter 'cid' described as 'IPFS content identifier (CID)'. The description adds no further meaning beyond restating 'by CID', so it relies on the schema's existing documentation. This meets the baseline for high coverage.

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

  Purpose5/5

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

  The description clearly states the action (retrieve) and resource (content from IPFS by CID). It is specific and distinguishes itself from sibling tools like pin_to_ipfs, which performs the opposite operation.

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

  Usage Guidelines2/5

  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. The description does not mention exclusions, prerequisites, or scenarios where another tool would be more appropriate.

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

• get_crypto_marketsB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It mentions the $0.002 per request cost, which is useful, and 'Get' implies a read-only operation. However, it doesn't disclose rate limits, pagination behavior, or any side effects. The cost detail raises awareness but overall transparency is only average.

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

  Conciseness5/5

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

  The description is extremely concise, consisting of a purpose sentence and a cost note. It is front-loaded with the key information and contains zero redundancy. Every word earns its place, making it easy for an agent to parse quickly.

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

  Completeness3/5

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

  The tool has 5 optional parameters and no output schema, so the description should partially cover behavior and return values. It hints at 'detailed market data' but is vague about what that includes. Given the schema documents parameters well, the main gap is lack of specifics about the response content and pagination/order behavior. This makes it adequate but not complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions. It mentions 'market cap' which aligns with the 'order' parameter, but provides no additional detail about how parameters interact (e.g., category filtering). Thus, it does not improve on the schema.

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

  Purpose4/5

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

  The description clearly states the tool returns top cryptocurrencies by market cap with detailed market data. It is specific about the resource and scope, but it doesn't explicitly differentiate from sibling tools like search_crypto or get_trending_crypto. The 'by market cap' detail provides some differentiation, but naming alternatives would make it a 5.

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

  Usage Guidelines2/5

  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 the many crypto-related siblings. No mention of alternatives, exclusions, or typical use cases. The description only states what it does, leaving the agent to infer suitability. This is a clear gap given the large set of sibling tools.

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

• get_wallet_pnlB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose a useful meta-behavior: the cost of $0.01 per request. However, it omits details about what the analysis includes (e.g., realized/unrealized PnL, time period, fees), potential side effects, or required permissions. The cost information adds some transparency, but the full burden is not fully met.

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

  Conciseness5/5

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

  The description is extremely concise, consisting of two short sentences. The main purpose is front-loaded, and the cost note is an essential piece of information. There is zero waste or redundant phrasing.

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

  Completeness2/5

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

  The description lacks completeness given the absence of an output schema and the analytical nature of the tool. It does not describe what the P&L response contains, how it is computed, or any limitations (e.g., supported chains, token coverage). The agent cannot infer the return format from the description alone, which is a significant gap for a non-trivial analysis tool.

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

  Parameters3/5

  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 adds no additional meaning to the parameters beyond what the schema already provides (chain, address, filters). The context of 'token trades' is implicit in the tool name and description, but it does not elaborate on how each parameter influences the PnL calculation.

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

  Purpose5/5

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

  The description clearly states the tool's specific function: 'Get profit and loss analysis for a wallet's token trades.' This uses a specific verb ('Get') and a distinct resource ('wallet's token trades'), differentiating it from sibling tools like get_wallet_balances and get_wallet_transactions. The additional pricing note is also clear.

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

  Usage Guidelines2/5

  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 does not mention any prerequisites, exclusions, or comparisons with similar wallet-related tools. There is no explicit 'use this when...' or 'for X use instead...' context.

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

• search_flightsB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does disclose the cost ($0.01 per request) and indicates the output type (pricing, itineraries, airlines). However, it omits other potentially relevant behaviors such as rate limits, data sources, or whether the search is read-only. The cost disclosure adds value beyond what the schema provides.

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

  Conciseness5/5

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

  The description is two sentences long and clearly front-loads the core function. Every word earns its place: it states what it searches, what it returns, and the cost. There is no redundancy or filler, making it highly concise and well-structured.

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

  Completeness4/5

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

  Given the tool's moderate complexity (8 parameters) and the absence of annotations and output schema, the description provides sufficient context by explaining the search focus, return contents, and cost. The schema covers parameter details, so the description does not need to repeat them. It could be improved by mentioning whether it supports one-way vs round-trip explicitly, but this is inferable from the optional returnDate parameter.

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

  Parameters3/5

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

  The input schema has 100% description coverage, documenting all 8 parameters including examples and defaults. The description adds no additional parameter detail beyond mentioning route, dates, and passengers, which maps to the existing schema fields. Since the schema already does the heavy lifting, 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.

  Purpose4/5

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

  The description clearly states the tool searches flight offers by route, dates, and passengers, and returns pricing, itineraries, and airlines. It uses a specific verb and resource, making the purpose easy to grasp. However, it does not explicitly distinguish this from the sibling tool 'search_cheapest_dates', which may also search for flight options.

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

  Usage Guidelines2/5

  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 such as 'search_cheapest_dates' or 'search_hotels'. It does not mention specific scenarios where this tool is preferred or when to avoid it. The only context given is implicit through the description of what it does.

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

• get_wallet_balancesA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It adds useful context like the per-request cost and 'any supported chain' scope, but omits behavior details such as response format, error handling, rate limits, or what happens for unsupported chains. The 'get' verb implies a safe read, but this is not explicit.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the purpose and cost with no redundant words. It is concise and directly to the point.

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

  Completeness3/5

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

  For a simple tool with two parameters and no output schema, the description is adequate but incomplete. It does not specify the format of returned balances, whether it returns all tokens or only selected ones, or list the supported chains. This information would need to be inferred from the tool name and examples.

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

  Parameters3/5

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

  The schema provides 100% coverage for both parameters (chain and address) with clear types and examples. The description adds minimal extra meaning, only clarifying that token balances are queried and chains are supported, but does not go beyond the schema's definitions.

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

  Purpose5/5

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

  The description clearly states the tool's function: retrieving token balances for a wallet address on any supported chain. This distinguishes it from sibling tools like get_wallet_transactions (transactions) and get_wallet_pnl (profit/loss), using a specific verb and resource.

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

  Usage Guidelines2/5

  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 such as get_wallet_pnl or get_token_prices. It does not mention exclusions, prerequisites, or specific use cases, leaving the agent to infer suitability from the name alone.

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

• search_cryptoA
  3.5/5.0
  Behavior3/5

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

  No annotations, so description carries full burden. It discloses cost ($0.001 per request), which is useful, but gives no details on result format, pagination, or search behavior (exact vs fuzzy). Minimal but not misleading.

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

  Conciseness5/5

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

  Two short sentences, no filler. The cost is a valuable and concise addition. Every word earns its place.

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

  Completeness3/5

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

  For a simple one-parameter search tool, the description gives enough to invoke it but omits return value details. An agent cannot know if it receives a list or a single match, which could affect downstream tool selection. Lacks extra completeness beyond the basics.

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

  Parameters3/5

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

  Schema coverage is 100%, and the parameter description 'Search query (coin name or symbol)' already conveys the same information as the tool description. No additional semantic value beyond the schema.

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

  Purpose5/5

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

  Description uses specific verb 'Search' with resource 'cryptocurrency' and scope 'by name or symbol'. Clearly distinguishes from siblings like get_crypto_price or get_token_prices which target specific data rather than discovery.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives like get_crypto_price or get_trending_crypto. The phrase 'by name or symbol' implies discovery use, but there are no exclusions or alternative references.

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

• execute_codeA
  3.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions a 'secure sandboxed environment' and cost, but does not describe what the execution returns, how results are formatted, error behavior, environmental limits (beyond the timeout parameter), or persistence/state. This is a significant gap for a code execution tool.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence that covers the essential information: sandboxing, supported languages, and cost. There is no redundant or wasteful text.

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

  Completeness2/5

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

  The tool has no output schema and no annotations, so the description must provide context about execution outcomes. It does not explain the return format, whether stdout/stderr are captured, or how errors surface. The description is too sparse for an agent to reliably predict the tool's behavior after invocation.

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

  Parameters3/5

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

  The input schema already provides 100% parameter descriptions and a language enum. The description's language list simply mirrors the schema enum, adding no new meaning. Cost is mentioned but is not a parameter. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's action ('Execute code') and resource ('secure sandboxed environment'), and lists supported languages. It is easily distinguishable from all sibling tools, none of which involve code execution.

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

  Usage Guidelines4/5

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

  The description provides clear context: it is a sandboxed code execution tool with language support and cost implications. It does not explicitly mention when not to use it or name alternatives, but the uniqueness among siblings reduces the need for exclusions.

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

• get_wallet_transactionsA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses the cost per request ($0.005), which is a behavioral trait beyond the name. However, it does not describe the return format, pagination, ordering, or potential errors, leaving some behavioral aspects undisclosed.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the purpose, followed by a concise cost disclosure. Every word earns its place, and no redundant information is present.

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

  Completeness3/5

  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 fully documented parameters, the description covers purpose and cost. However, since there is no output schema, it does not specify the shape of the returned transaction history, which would enhance completeness. It is adequate but has a clear gap around return value details.

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

  Parameters3/5

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

  The input schema has 100% coverage for both parameters (chain, address), so the description does not need to explain them further. The description adds no extra parameter semantics beyond the schema, but the schema already fully documents them.

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

  Purpose5/5

  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') and specific resource ('transaction history for a wallet address'). It naturally distinguishes from sibling tools like get_wallet_balances (balances) and get_wallet_pnl (profit/loss), making the purpose unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage: when you need a wallet's transaction history, use this tool. However, it does not explicitly mention when not to use it or provide alternatives for related wallet operations, so guidance is only implicit.

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

• pin_to_ipfsA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It adds a key detail: the cost ($0.01 per pin). However, it does not mention irreversible side effects, the public nature of IPFS data, authentication requirements, or rate limits. The cost disclosure is valuable, but other behavioral aspects remain unclear.

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

  Conciseness5/5

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

  The description is concise, consisting of two short sentences with no redundant words. It front-loads the core action and provides the essential return value and cost, earning a perfect score for conciseness and structure.

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

  Completeness3/5

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

  The tool has a simple two-parameter schema and no output schema. The description covers the main functionality and return value, but it omits important context such as potential public visibility of pinned data and alternatives for retrieval. Given the absence of annotations, the description should provide more completeness regarding side effects and usage context.

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

  Parameters3/5

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

  The input schema covers 100% of the parameters (json and name) with descriptions. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies, as the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the action ('Pin'), the resource ('JSON data'), and the destination ('IPFS via Pinata'), and specifies the output ('Returns the IPFS CID'). This distinguishes it from sibling tools like get_from_ipfs, which retrieves data rather than pins it.

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

  Usage Guidelines3/5

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

  The description implies the use case: pinning JSON data to IPFS. However, it does not explicitly mention when not to use it or suggest alternatives like get_from_ipfs for retrieval. The context of sibling tools hints at the alternative, but no direct guidance is provided.

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

• search_locationsA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses the cost ($0.005 per request) and return fields (IATA codes, names, coordinates), adding useful context. However, it omits other behavioral details like pagination, error handling, or read-only safety, leaving some gap.

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

  Conciseness5/5

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

  The description is a single concise sentence, front-loaded with the purpose, and includes cost and return info without redundancy. Every part earns its place with no wasted words.

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

  Completeness4/5

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

  For a simple two-parameter search tool with full schema coverage, the description covers the core purpose, output fields, and cost. It doesn't explain potential limits or pagination, but these are not critical given the tool's simplicity. It is reasonably complete for an agent to invoke it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both keyword and subType having descriptive text. The description adds no additional meaning beyond mentioning airports and cities, which aligns with subType's default. It does not enrich actual parameter usage.

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

  Purpose5/5

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

  The description clearly states the tool does a keyword search for airports and cities, with a specific verb and resource. It distinguishes itself from siblings like search_flights and search_hotels by explicitly focusing on locations and returning IATA codes.

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

  Usage Guidelines3/5

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

  The description implies use for location lookup but does not explicitly state when to use this tool versus alternatives. No exclusions or alternative guidance is provided, only an implied context.

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

• transcribe_audioA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the cost ($0.10 per transcription), the model (Deepgram Nova-3), and the URL requirement, but it omits potential rate limits, authentication needs, or the exact output format, leaving gaps in transparency.

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the core action, and includes the key practical detail of cost. Every sentence contributes value without redundancy.

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

  Completeness4/5

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

  Given the simple tool with four well-documented parameters and no output schema, the description covers the essential context: what it does, the input requirement (public URL), and the cost. It could clarify the return format explicitly, but the phrase 'to text' and the overall simplicity make it reasonably complete.

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

  Parameters3/5

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

  Schema coverage is 100%, with all four parameters (audio_url, diarize, language, punctuate) described in the input schema. The description adds little beyond repeating that a public URL is accepted, so it does not meaningfully enhance parameter understanding beyond the schema.

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

  Purpose5/5

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

  The description begins with a specific verb and resource: 'Transcribe audio to text using Deepgram Nova-3.' It clearly distinguishes this tool from its unrelated siblings (crypto, search, IPFS, etc.), and the purpose is unambiguous.

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

  Usage Guidelines3/5

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

  The description indicates that it accepts a public URL to an audio file and mentions the cost, which implies the primary use case. However, it does not explicitly state when this tool should be used over alternatives, nor does it mention exclusions or prerequisites beyond having a public URL.

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

• get_token_metadataA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the transparency burden. It adds a cost disclosure ($0.002 per request), which is useful, but does not mention read-only nature, error handling, or response format. However, 'get' implies a safe read operation, and the cost is a meaningful 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.

  Conciseness5/5

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

  The description is one sentence and front-loads the core function, with cost appended. Every word earns its place, and it is immediately clear what the tool does.

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

  Completeness3/5

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

  For a simple metadata tool, the description gives the gist but omits the fact that at least one of id/slug/chain+address is needed. Without an output schema, it does not indicate the return structure beyond the examples. Still, it is adequate for a low-risk read operation.

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

  Parameters3/5

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

  Schema descriptions cover all four parameters, so the baseline is 3. The description does not add additional parameter meaning, such as the requirement to provide at least one identifier. The schema already documents each parameter's purpose, so the description adds no extra value here.

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

  Purpose5/5

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

  The description clearly states the tool retrieves token metadata, listing concrete examples (name, symbol, decimals). This distinguishes it from price-focused sibling tools like get_token_prices and get_crypto_price. The verb 'get' and resource 'token metadata' are specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description implies the tool is for metadata lookup, which differentiates it from price/history tools, but it does not explicitly state when to use it or name alternatives. There is no guidance on which parameter combination is required (e.g., chain+address vs id), but the context is clear enough for basic use.

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

• get_token_pricesA
  3.9/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the behavioral disclosure burden. It adds useful context about the data source (DEX-derived) and the per-request cost ($0.005), but it does not describe the return format or error behavior, leaving a moderate transparency gap.

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

  Conciseness5/5

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

  The description is two short sentences with no filler. The first sentence states the core purpose, and the second adds essential cost information. Every sentence earns its place.

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

  Completeness3/5

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

  For a tool with a single parameter and no output schema, the description gives purpose, input method, and cost, but does not describe the return payload or any additional behavioral details. It is minimally viable but lacks the depth needed for fully confident agent invocation.

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

  Parameters3/5

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

  Schema coverage is 100%: the tokens parameter and its nested fields (chain, token_address) are described in the schema. The description adds no additional parameter-level details beyond 'by contract address,' which aligns with the token_address field, so the baseline 3 is appropriate.

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

  Purpose5/5

  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 'DEX-derived prices for tokens' and identifies the input method 'by contract address.' It distinguishes itself from siblings like get_crypto_price by emphasizing the DEX-derived nature and on-chain addressing.

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

  Usage Guidelines4/5

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

  The description clearly conveys the context for use: obtaining DEX-derived token prices via contract addresses. It does not explicitly list alternatives or non-use cases, but the DEX/contract-address qualifier provides strong contextual guidance that differentiates it from other price tools.

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

• search_hotelsA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the return content and a per-request cost ($0.01), which is useful behavioral context. However, it does not explicitly state that it is read-only (implied by 'search') or mention any rate limits or auth requirements, leaving some transparency gaps.

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

  Conciseness5/5

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

  The description is extremely concise, consisting of three short sentences that immediately state the tool's purpose, return value, and cost. There is zero wasted text and the most important information is front-loaded.

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

  Completeness3/5

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

  The tool has 7 parameters and no output schema. The description covers the core use case but omits details about optional parameters (currency, priceRange, adults, roomQuantity) and result pagination/limits. The schema compensates for parameter semantics, but the description could be richer about expected outputs and constraints.

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

  Parameters3/5

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

  The input schema has 100% coverage with descriptive parameter names and value examples, so the baseline is 3. The description adds only general parameter hints ('by city and dates') and does not go beyond the schema for optional parameters like currency, priceRange, or roomQuantity.

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

  Purpose5/5

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

  The description uses a specific verb ('Search') and resource ('hotel offers') with key parameters ('by city and dates'), clearly distinguishing it from sibling tools like search_flights and search_locations. It also states what it returns (room details, pricing, availability), making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description implicitly defines when to use the tool: when searching for hotel offers by city and date. However, it does not explicitly exclude alternatives or mention when not to use it, so it lacks explicit exclusions or alternative tool references.

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

• service_healthA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the transparency burden. It discloses that the tool is free ('Free, no payment required') and provides live data, which are useful behavioral facts. However, it does not mention potential side effects, authentication needs, or error handling, leaving some gaps for a tool that reports on service health.

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

  Conciseness5/5

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

  Two sentences, no fluff. The first sentence delivers the core purpose and metrics; the second adds essential usage and cost context. Every word earns its place.

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

  Completeness4/5

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

  With a single optional parameter, no output schema, and no annotations, the description is fairly complete. It explains what metrics are returned, the free nature, and when to call it. Minor omissions like response format or pagination are not critical for this straightforward health-check tool.

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

  Parameters3/5

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

  The schema fully documents the sole parameter 'service' with a clear description ('Filter to a specific service ID... Omit for all services'), yielding 100% coverage. The description adds no additional parameter syntax or format details, so baseline 3 is appropriate.

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

  Purpose5/5

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

  Description uses specific verb 'Get' with a clear resource 'live health metrics for all x402engine services', enumerating the exact metrics (latency, error rates, request volume, status). This differentiates it from sibling tools like discover_services and get_crypto_price by focusing on health/status rather than general discovery or financial data.

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

  Usage Guidelines4/5

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

  Explicitly states 'Call this before choosing which service to use', providing clear when-to-use context. It does not mention exclusions or alternatives, but the instruction is actionable and sufficient for an agent deciding to invoke this tool.

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

• discover_servicesA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses that the tool lists APIs with pricing, endpoints, and payment networks, giving some sense of return content. Yet it does not mention authentication requirements, side effects (though likely a read-only listing), rate limits, or any other behavioral constraints. This is adequate but lacks depth.

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the core purpose, and every word earns its place. The second sentence gives a clear call to action. No unnecessary detail or repetition.

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

  Completeness4/5

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

  Given the tool's simplicity (no parameters, no output schema, no annotations), the description covers the essential context: what it lists and when to call it. It is sufficiently complete for an agent to use it effectively, though more detail about return format would slightly improve it.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description is not required to explain any parameters and adds value by describing what the tool returns, but since there are no params to describe, no further param semantics are needed.

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

  Purpose5/5

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

  The description clearly states the verb 'List' and the specific resource 'x402 Engine APIs', with details on what is listed (pricing, endpoints, payment networks). It distinguishes itself from sibling tools by being a discovery service, and includes a direct usage cue ('Call this first').

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

  Usage Guidelines4/5

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

  The description explicitly tells the agent to call this tool first to understand what's available, providing clear context for when to use it. However, it does not mention alternatives or explicitly state when not to use it, so it doesn't earn a 5.

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

• get_crypto_categoriesA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It adds the cost per request ($0.001) which is valuable, but it does not mention read-only nature, response format, pagination, or any potential side effects. Since this is a simple list operation, the missing details are not critical, but the description only partially discloses behavior.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with the verb and resource first, followed by the purpose and cost. Every word adds value, and there is no redundancy or filler. It is an example of efficient, well-structured tool documentation.

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

  Completeness4/5

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

  For a simple tool with no parameters and no output schema, the description covers the essential context: what it lists, why to use it, and the cost. It could be considered complete, but it leaves out details about the return format (e.g., whether it returns a JSON array of IDs with names) and any rate limits. Still, given the low complexity, it is nearly complete.

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

  Parameters4/5

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

  The tool has zero parameters, so the input schema is empty and schema coverage is 100% by default. The description doesn't need to explain parameters but does clarify that the output is category IDs, which is useful. Given the baseline for 0 params is 4, this is appropriate.

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

  Purpose5/5

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

  The description clearly states the verb 'List' and the resource 'CoinGecko category IDs', which precisely identifies the tool's function. It also provides context ('for sector discovery and downstream market filters') and distinguishes it from sibling crypto tools by focusing on categories rather than prices, markets, or history.

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

  Usage Guidelines4/5

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

  The phrase 'for sector discovery and downstream market filters' conveys when to use this tool, but it does not explicitly mention alternatives or exclusion criteria. The context is clear enough to infer usage, but it lacks a direct comparison to sibling tools like get_crypto_markets or search_crypto.

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

• search_cheapest_datesA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It discloses the cost per request ('$0.01 per request') and the return format ('date/price pairs sorted by price'), providing useful behavioral context beyond a mere summary.

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

  Conciseness5/5

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

  The description is two sentences, front-loading the purpose and then adding return format and cost. Every sentence adds value, and there is no superfluous text.

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

  Completeness4/5

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

  The description covers purpose, output format, and cost, which is adequate for a simple search tool. Missing details like currency or result limits, but given the simplicity and schema coverage, it is reasonably complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already explains all parameters. The description does not add extra semantic detail about parameters beyond what the schema provides, warranting the baseline score.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Find the cheapest travel dates for a route.' It specifies the output ('date/price pairs sorted by price') and differentiates from sibling search_flights by emphasizing 'cheapest' dates, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description implies when to use the tool (when seeking cheapest travel dates) and is clear in context. However, it does not explicitly contrast with alternatives like search_flights or state exclusions, so it misses full guidance.

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

• generate_imageA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently discloses costs associated with each tier, the underlying models, and the return format (image URL). This goes beyond the schema, which only lists tier options without model/cost details.

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

  Conciseness5/5

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

  Two sentences, no wasted words. The first sentence states the core purpose, and the second delivers crucial tier/cost/output information in a compact, scannable format.

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

  Completeness4/5

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

  Given the tool's simplicity, no output schema, and no annotations, the description adequately covers purpose, pricing, models, and output format. It could mention reproducibility (seed) or dimension limits, but those are already detailed in the schema, so the description is sufficiently complete for an agent to select and invoke the tool.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds model names and cost context for the 'tier' parameter that are absent from the schema, enhancing semantic understanding. Other parameters are already well-described by the schema.

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

  Purpose5/5

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

  The description clearly states 'Generate an image from a text prompt' with a specific verb and resource. It also distinguishes this tool from all siblings, none of which involve image generation.

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

  Usage Guidelines4/5

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

  The description gives clear context on when to use the tool (whenever an image from text is needed) and provides useful guidance on choosing among quality tiers based on cost and model capabilities. It does not explicitly name alternatives, but no direct alternatives exist among siblings.

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