Server Quality Checklist

Tool Scores

• check_wallet_tierC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions 'FREE' which suggests no cost, but doesn't disclose other behavioral traits like rate limits, authentication requirements, response format, or what happens with invalid addresses. For a tool with no annotation coverage, this leaves significant gaps.

  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 appropriately concise with two short sentences. The first sentence states the core functionality, and the second adds the 'FREE' qualifier. No wasted words, though it could be slightly more structured.

  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 annotations and no output schema, the description is incomplete. It doesn't explain what information is returned (just balance and tier details?), format of response, error conditions, or how the discount tier relates to balance. For a financial tool with no structured output definition, more context is needed.

  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 documents the single 'address' parameter. The description adds minimal value beyond what's in the schema - it confirms the address is for checking ASTERPAY token balance but doesn't provide additional context about address format, validation, or examples.

  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's purpose: checking ASTERPAY token balance and discount tier. It specifies the resource (ASTERPAY token) and includes the 'FREE' qualifier. However, it doesn't explicitly differentiate from sibling 'check_token_tiers' or 'wallet_score' tools, which appear related.

  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. With sibling tools like 'check_token_tiers' and 'wallet_score' present, there's no indication of when this specific ASTERPAY-focused check is appropriate versus more general token or wallet analysis tools.

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

• check_token_tiersB
  3/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 the tool is 'FREE' which hints at no cost, but doesn't describe response format, data freshness, rate limits, authentication needs, or what specific information about tiers is returned.

  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 appropriately concise with two sentences that convey core functionality and key benefit. It's front-loaded with the main purpose, though the second sentence could be integrated more smoothly.

  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?

  For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what information is returned about token tiers, how the data is structured, or provide examples of the tier system details that would help an agent understand the response.

  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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description appropriately doesn't add parameter information beyond what the schema provides, maintaining a clean baseline.

  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 what the tool does ('View ASTERPAY token tier system') with a specific verb and resource. It distinguishes from sibling 'check_wallet_tier' by focusing on token tiers rather than wallet tiers, though the differentiation could be more explicit.

  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 like 'check_wallet_tier' or other sibling tools. The description mentions API discounts and being free, but these are features rather than usage instructions.

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

• ai_summarizeB
  3.2/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 adds context beyond basic functionality by mentioning the cost ('Cost: $0.004 USDC via x402'), which is a useful behavioral trait (monetary implication). However, it lacks details on other behaviors like rate limits, error handling, or output format (e.g., summary structure), leaving gaps for a tool with no output schema.

  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 appropriately sized and front-loaded: the first sentence states the core purpose, the second adds return value context, and the third provides cost information. Each sentence earns its place, but it could be slightly more structured (e.g., separating functional and non-functional details). No wasted words, but minor room for improvement in flow.

  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's moderate complexity (AI-based summarization with cost), no annotations, and no output schema, the description is partially complete. It covers purpose and cost but lacks details on behavioral aspects like error cases, performance, or output format. For a tool with no structured output, more context on what the summary looks like would enhance completeness, but it's minimally adequate.

  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 documents both parameters (text and maxLength) adequately. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain how maxLength interacts with summarization quality or default values). Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with extra insights.

  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's purpose: 'Summarize any text using AI' specifies the verb (summarize) and resource (text). It distinguishes from siblings like ai_sentiment or ai_translate by focusing on summarization rather than sentiment analysis or translation. However, it doesn't explicitly differentiate from all AI siblings (e.g., ai_code_review could also involve text processing).

  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 mentions a cost implication ('Cost: $0.004 USDC via x402'), which might hint at usage considerations, but doesn't specify scenarios where summarization is preferred over other AI tools like ai_sentiment or when not to use it (e.g., for non-text inputs). No explicit alternatives or exclusions are mentioned.

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

• ai_translateB
  3.2/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 adds useful context beyond the schema: it reveals the tool uses AI, supports all major languages, and has a cost of $0.02 USDC via x402. However, it doesn't mention rate limits, error conditions, or what the output looks like (though there's no output schema), leaving gaps for a mutation tool.

  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 appropriately sized with two sentences that each add value: the first states the core functionality, and the second adds cost and language support details. It's front-loaded with the main purpose. However, the cost detail could be more integrated, and there's minor room for tighter phrasing.

  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 no annotations and no output schema, the description is moderately complete. It covers the AI aspect, language support, and cost, but lacks details on output format, error handling, or usage constraints. For a 3-parameter tool with mutation implications (translation likely creates output), it should do more to compensate for missing structured data.

  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 documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. It mentions 'any language' and 'all major languages' which loosely relates to targetLanguage but doesn't provide specific format or validation details. Baseline 3 is appropriate when schema does the heavy lifting.

  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's purpose: 'Translate text to any language using AI.' It specifies the verb (translate) and resource (text), and distinguishes it from siblings like ai_sentiment or ai_summarize. However, it doesn't explicitly differentiate from other potential translation tools, which prevents a perfect score.

  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 mentions cost and supports all major languages, but doesn't specify scenarios, prerequisites, or exclusions. With siblings like ai_code_review and ai_summarize, there's no indication of when translation is preferred over other AI processing tools.

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

• whale_alertsB
  3.2/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 adds valuable context about cost ('$0.02 USDC via x402') and scope ('recent', 'large', 'on-chain'), which aren't in the schema. However, it doesn't disclose important behavioral traits like rate limits, authentication requirements, response format, or what constitutes 'large' movements. The description doesn't contradict any annotations since none exist.

  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 appropriately concise with two sentences that each add value. The first sentence states the core purpose, and the second adds important behavioral context (cost and mechanism). There's no wasted language or redundancy. However, it could be slightly more structured by separating cost information into its own clause.

  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's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers the core purpose and cost information but lacks details about response format, error conditions, rate limits, and use case guidance. Without an output schema, the description should ideally mention what the tool returns, but it doesn't. The cost disclosure is valuable but doesn't compensate for other missing 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 has 100% description coverage, providing clear documentation for both parameters. The description doesn't add any parameter-specific information beyond what's in the schema - it mentions neither 'network' nor 'limit' parameters. According to the scoring rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.

  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's purpose: 'Get recent large cryptocurrency movements (whale alerts)' with the specific verb 'Get' and resource 'large cryptocurrency movements'. It distinguishes from siblings by focusing on whale alerts rather than price data, sentiment analysis, or other crypto-related functions. However, it doesn't explicitly differentiate from all siblings (e.g., 'check_token_tiers' or 'wallet_score' might also involve cryptocurrency analysis).

  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. While it mentions tracking 'significant token transfers on-chain', it doesn't explain when whale alerts are preferable to other crypto tools like 'get_crypto_price', 'get_ohlcv', or 'token_analysis'. There's no mention of use cases, prerequisites, or exclusions.

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

• ai_code_reviewB
  3.3/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 mentions the cost, which is useful context, but lacks details on rate limits, error handling, or what the output looks like (e.g., format of bugs and improvements). It does not contradict annotations, but could be more informative for a tool with potential behavioral complexities.

  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 appropriately sized with two sentences: one stating the purpose and one noting the cost. It is front-loaded with the main function, but the cost detail, while relevant, could be integrated more seamlessly. Overall, it is efficient with minimal waste.

  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 the complexity of code review (which may involve detailed outputs) and no output schema, the description is incomplete. It lists what the tool returns but does not explain the format or structure of the output. With no annotations and incomplete behavioral context, it falls short for effective agent use.

  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 documents both parameters ('code' and 'language'). The description does not add meaning beyond what the schema provides, such as examples or constraints. Baseline is 3 when schema does the heavy lifting, but no extra value is added.

  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 purpose with specific verbs ('AI-powered code review') and resources ('code'), and it distinguishes from siblings by focusing on code analysis rather than sentiment, translation, or other unrelated tasks. The mention of 'bugs, improvements, security issues, and best practices' adds specificity.

  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 mentions a cost ('$0.05 USDC via x402'), which could imply a usage consideration, but does not specify prerequisites, limitations, or comparisons with other tools like 'ai_sentiment' or 'ai_summarize' for code-related tasks.

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

• take_screenshotA
  3.5/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 effectively states the core action (screenshot webpage) and key constraint (cost of $0.02 USDC via x402), but lacks details about execution time, error conditions (e.g., invalid URLs, timeouts), or image format specifics. The cost disclosure is valuable context beyond basic functionality.

  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 with just two sentences that are front-loaded with the core functionality. Every word earns its place: the first sentence states the action and resource, while the second adds critical behavioral context (return type and cost). No wasted verbiage.

  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's moderate complexity (webpage interaction with financial cost) and lack of both annotations and output schema, the description is minimally adequate. It covers what the tool does and a key constraint (cost), but omits details about output format (e.g., image type, size), error handling, or performance characteristics that would help an agent use it effectively.

  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%, providing complete parameter documentation (url, width, height with defaults). The description adds no additional parameter semantics beyond what the schema already specifies, so it meets the baseline for high schema coverage without compensating with extra insights.

  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 specific action ('Take a screenshot') and resource ('any webpage'), with the verb+resource combination making the purpose unambiguous. It distinguishes itself from all sibling tools, which focus on AI analysis, crypto data, or document generation rather than visual capture.

  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. While it mentions a cost, it doesn't specify scenarios where screenshotting is preferable to other methods or tools, nor does it mention prerequisites like URL accessibility or browser compatibility.

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

• get_crypto_priceA
  3.6/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 effectively describes key behaviors: real-time data retrieval, specific return fields (price, market cap, volume, changes), and a cost mechanism. However, it doesn't mention potential limitations like rate limits, error handling, or data freshness, which could be important for an agent's decision-making.

  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 front-loaded with the core purpose and efficiently lists return data and cost in two sentences. It avoids unnecessary details, but could be slightly more structured by separating the cost note into its own sentence for clarity. Overall, it's concise with minimal waste.

  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's moderate complexity (single parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It covers purpose, returns, and cost, but lacks details on error cases, data sources, or example outputs. Without annotations or output schema, more behavioral context would improve completeness for agent use.

  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, with the 'symbol' parameter well-documented. The description adds minimal value beyond the schema, only implying the parameter is used to specify the token. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.

  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's purpose: 'Get real-time cryptocurrency price data for any token' with specific examples (Bitcoin, Ethereum). It distinguishes from siblings like 'get_ohlcv' (which likely provides historical OHLCV data) and 'token_analysis' (which likely provides deeper analysis). However, it doesn't explicitly differentiate from 'get_trending' or 'whale_alerts', which might also involve price data, keeping it from 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.

  Usage Guidelines3/5

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

  The description implies usage for real-time price data retrieval, but lacks explicit guidance on when to use this tool versus alternatives like 'get_ohlcv' for historical data or 'token_analysis' for deeper insights. It mentions a cost ('$0.005 USDC via x402'), which provides some context but doesn't specify when this tool is preferred over other pricing or analysis tools in the sibling list.

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

• ai_sentimentA
  3.7/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 effectively describes the output format ('positive/negative/neutral classification with confidence scores') and explicitly states the cost ('$0.004 USDC via x402'), which are crucial behavioral traits not evident from the input schema alone. However, it doesn't mention rate limits, error conditions, or processing time.

  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 and front-loaded, with every sentence earning its place. The first sentence states the core function, the second describes the output, and the third provides cost information—all in just three sentences with zero wasted words.

  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's moderate complexity (single parameter, no output schema, no annotations), the description is partially complete. It covers the core function, output format, and cost, but lacks information about error handling, rate limits, or example usage. For a paid service with no output schema, more contextual details would be beneficial.

  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 description coverage is 100%, with the single parameter 'text' fully documented in the schema. The description doesn't add any additional parameter semantics beyond what the schema already provides (e.g., it doesn't specify text length limits, language requirements, or formatting expectations). This meets the baseline expectation when schema coverage is complete.

  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 specific action ('analyze sentiment of text') and resource ('text'), and distinguishes it from siblings like ai_summarize or ai_translate by focusing on sentiment classification. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.

  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. While it mentions cost, it doesn't specify scenarios where sentiment analysis is appropriate compared to other AI tools like ai_code_review or ai_summarize, nor does it mention prerequisites or exclusions. This leaves the agent without contextual usage direction.

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

• generate_pdfA
  3.7/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 effectively reveals key traits: the tool performs a conversion (implying mutation), returns a PDF file, and includes a cost detail ('$0.03 USDC via x402'), which is crucial for financial awareness. However, it lacks information on error handling, rate limits, or authentication needs.

  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 and front-loaded, with two sentences that efficiently convey the core functionality and cost without any wasted words. Each sentence adds critical value, 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?

  Given the tool's moderate complexity (conversion with a cost), no annotations, and no output schema, the description is partially complete. It covers the basic operation and cost but omits details like response format, error cases, or prerequisites, leaving gaps that could hinder effective tool 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 description coverage is 100%, so the schema already documents both parameters ('html' and 'format') thoroughly. The description adds no additional semantic details beyond what the schema provides, such as HTML formatting requirements or PDF quality options, resulting in a baseline score of 3.

  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 specific action ('Convert HTML content to PDF document') and the resource ('PDF file'), making the purpose immediately apparent. It distinguishes this tool from siblings like 'take_screenshot' or 'generate_qr_code' by focusing on HTML-to-PDF conversion rather than other document or image generation tasks.

  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. While it mentions a cost, it does not specify scenarios where this tool is preferred over other document generation tools or when it should be avoided, leaving the agent without contextual usage instructions.

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

• token_analysisA
  3.9/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 effectively describes the core functionality (security checks) and mentions the cost, which is crucial behavioral context. However, it lacks details about rate limits, authentication needs, response format, or potential side effects (e.g., whether analysis is cached or triggers alerts).

  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 and front-loaded: it immediately states the purpose, specific checks, and cost in just two sentences. Every word earns its place with no redundancy or unnecessary elaboration, 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?

  Given the tool's complexity (security analysis with financial cost) and lack of annotations/output schema, the description is moderately complete. It covers the core purpose and cost but misses details like response structure, error handling, or integration notes. For a paid tool with no structured output, more context on what to expect would be beneficial.

  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 documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain format requirements for 'address' beyond '0x...' or clarify 'network' choices). Baseline 3 is appropriate when the schema handles parameter documentation.

  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 specific action ('Security analysis') and resource ('ERC-20 token contract'), with explicit details about what it checks (honeypots, rug pulls, ownership issues, contract risks). It distinguishes itself from sibling tools like 'check_token_tiers' or 'wallet_score' by focusing on comprehensive security analysis rather than tier classification or wallet scoring.

  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 for when to use this tool: for security analysis of ERC-20 tokens, including specific risk types. It mentions the cost ($0.10 USDC via x402), which helps determine appropriateness. However, it doesn't explicitly state when NOT to use it or name alternatives among siblings (e.g., 'check_token_tiers' might be for different purposes).

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

• wallet_scoreA
  3.9/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 effectively describes key behavioral traits: it's a read operation (implied by 'Get'), discloses the cost ($0.05 USDC via x402), and mentions what is analyzed. However, it lacks details on rate limits, error conditions, or response format.

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

  Conciseness5/5

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

  The description is appropriately sized and front-loaded, with two sentences that efficiently convey purpose, analysis scope, and cost. Every sentence adds value without redundancy or unnecessary elaboration.

  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's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers purpose and cost but lacks details on output format, error handling, or integration with sibling tools. Without annotations or output schema, more behavioral context would improve completeness.

  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, so the baseline is 3. The description does not add any parameter-specific semantics beyond what the schema provides (e.g., no extra details on address validation or network implications). It mentions analysis aspects but not how they relate to parameters.

  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 purpose with specific verbs ('Get reputation and risk score') and resource ('blockchain wallet address'), and distinguishes it from siblings by specifying what it analyzes (transaction history, age, activity patterns). It goes beyond just restating the name/title.

  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 context through the analysis details and cost information, but does not explicitly state when to use this tool versus alternatives (e.g., check_wallet_tier or token_analysis). No explicit exclusions or comparisons to sibling tools are provided.

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

• generate_qr_codeA
  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 adds valuable context beyond basic function: it specifies the return format ('base64-encoded PNG image') and cost ('FREE — no payment required'), which are not inferable from the input schema. However, it does not cover aspects like rate limits, error handling, or performance traits.

  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 appropriately sized and front-loaded, with two concise sentences that directly convey the tool's function, output, and cost. Every sentence earns its place by providing essential information without redundancy or unnecessary details.

  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 (2 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, output format, and cost, but lacks details on error cases, usage limits, or example scenarios. With no output schema, it could benefit from more on return values, but the base64 PNG mention partially compensates.

  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 documents both parameters ('data' and 'size') fully. The description adds minimal semantic value beyond the schema, as it only mentions 'text or URL' for 'data' and does not elaborate on 'size' or default behavior. Baseline 3 is appropriate when the schema handles parameter documentation effectively.

  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 purpose with a specific verb ('Generate') and resource ('QR code image'), and distinguishes it from siblings by specifying the unique function of creating QR codes from text/URLs, which none of the sibling tools offer.

  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 by stating 'Generate a QR code image from any text or URL,' but does not explicitly guide when to use this tool versus alternatives or provide exclusions. It mentions 'FREE — no payment required,' which hints at a cost-free context but lacks detailed comparative guidance.

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

• get_ohlcvA
  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 full burden and adds valuable behavioral context: it discloses the cost ('$0.01 USDC via x402'), which is critical for usage decisions. However, it doesn't mention rate limits, authentication needs, or response format 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?

  The description is extremely concise (two sentences) with zero waste. The first sentence states purpose and use case, the second provides critical cost information. 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?

  For a 2-parameter tool with no annotations and no output schema, the description provides good coverage: clear purpose, use case, and critical cost information. However, it doesn't describe the response format or data structure, which would be helpful given the lack of output schema.

  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 documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3.

  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 ('Get') and resource ('OHLCV candlestick data') with specific purpose ('for charting and technical analysis'). It distinguishes from sibling tools like 'get_crypto_price' by specifying OHLCV data rather than just price.

  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 for charting and technical analysis, providing some context, but doesn't explicitly state when to use this tool versus alternatives like 'get_crypto_price' or 'token_analysis'. No exclusions or prerequisites are mentioned.

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

• settlement_estimateA
  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 effectively describes key traits: it's a read-only operation (implied by 'Get'), provides real-time data, includes fee details (0.5%), and specifies timing (SEPA Instant). However, it doesn't mention potential errors, rate limits, or authentication needs, which are minor 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 front-loaded with the core purpose and efficiently includes essential details like fees, timing, and cost in a single, well-structured sentence. Every element earns its place without redundancy, making it highly concise and clear.

  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 low complexity (1 parameter, no output schema, no annotations), the description is mostly complete, covering purpose, fees, timing, and cost. However, it lacks details on return values or error handling, which would be beneficial for full contextual understanding.

  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 the 'amount' parameter as a USDC amount with formatting examples. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without extra value.

  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 purpose with specific verbs ('Get settlement estimate') and resources ('USDC to EUR conversion via AsterPay's EUR off-ramp facilitator'), distinguishing it from sibling tools like 'get_crypto_price' or 'check_token_tiers' by focusing on conversion estimation rather than price checking or tier analysis.

  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 context by specifying 'USDC to EUR conversion' and 'FREE — no payment required,' suggesting it's for estimating conversions without cost. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_crypto_price' or detailed prerequisites, leaving some ambiguity.

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

• discover_endpointsA
  4.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 of behavioral disclosure. It mentions the tool is 'FREE' which is useful cost information, and 'x402 Bazaar compatible' provides integration context. However, it doesn't describe response format, rate limits, authentication requirements, or error behavior that would be important for a discovery 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 extremely efficient with just 10 words across two sentences. The first sentence states the core purpose, the second adds important qualifiers. Every word earns its place with no redundancy or unnecessary elaboration.

  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 zero-parameter tool with no annotations and no output schema, the description provides adequate basic information about what the tool does. However, it lacks details about the response format, what 'pricing and metadata' specifically includes, and how the discovered endpoints are structured or returned to the agent.

  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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description appropriately doesn't waste space discussing parameters that don't exist, maintaining focus on the tool's purpose and behavior.

  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 specific action ('Discover all available AsterPay API endpoints') and resource ('AsterPay API endpoints'), with additional scope details ('with pricing and metadata'). It distinguishes itself from sibling tools by focusing on API endpoint discovery rather than AI processing, crypto data, or wallet operations.

  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 for when to use this tool ('Discover all available AsterPay API endpoints with pricing and metadata') and includes compatibility information ('x402 Bazaar compatible'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for similar purposes.

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

• get_trendingA
  4.3/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 adds valuable context about cost ('Cost: $0.005 USDC via x402'), which is a behavioral trait not inferable from the schema. However, it doesn't describe rate limits, response format, or other operational 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?

  The description is perfectly concise with two sentences: one stating the purpose and one stating the cost. Every sentence earns its place, and it's front-loaded with the core functionality.

  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 no annotations and no output schema, the description provides good purpose and cost information but lacks details about return values (what data structure, fields, examples) and other behavioral aspects like rate limits or error conditions. For a tool with no structured metadata, this leaves some gaps.

  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 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to add parameter information, and it appropriately focuses on the tool's purpose and cost instead.

  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 specific action ('Get') and resource ('currently trending cryptocurrency tokens based on search interest'), distinguishing it from siblings like get_crypto_price (price data) or token_analysis (analysis). It provides a precise verb+resource combination with a specific scope.

  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 usage context (when you need trending tokens based on search interest) but doesn't explicitly state when not to use it or name alternatives. It provides clear context but lacks explicit exclusions or sibling tool comparisons.

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