Server Quality Checklist

Tool Scores

• check_blacklistC
  2.7/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 the full burden of behavioral disclosure. It mentions 'community-sourced intelligence' and a cost, but doesn't cover critical aspects like rate limits, authentication needs, error handling, or what 'community-flagged' entails (e.g., severity levels, confidence scores). For a tool with financial implications and no annotations, this is inadequate.

  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 concise and front-loaded, with three sentences that each add value: purpose, data source, and cost. There's no wasted text, and it efficiently communicates key information. However, it could be slightly more structured (e.g., separating cost into a separate note).

  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 (financial tool with community data), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It misses details on output format, error cases, usage limits, and how results should be interpreted. The cost mention is helpful but doesn't compensate for other gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for undocumented parameters. It doesn't explain what 'token_address' or 'chain' represent, their formats, or examples. The mention of 'token' implies 'token_address' is a token identifier, but this is vague. With 2 parameters and no schema descriptions, the description adds minimal semantic value.

  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: 'Check if a token is community-flagged.' It specifies the verb ('check') and resource ('token'), and mentions the data source ('community-sourced intelligence with reputation-weighted flags'). However, it doesn't explicitly differentiate from sibling tools like 'check_token_risk' or 'check_token_risk_premium', which appear to serve similar risk assessment functions.

  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 ('Cost: $0.02'), which might imply usage considerations, but doesn't specify scenarios, prerequisites, or exclusions. With multiple sibling tools for token risk assessment (e.g., 'check_token_risk', 'check_batch_risk'), the lack of differentiation is a significant gap.

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

• get_serial_ruggersC
  2.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 full burden. It discloses the cost ('Cost: $0.02'), which is valuable behavioral information. However, it doesn't mention rate limits, authentication requirements, response format, whether this is a read-only operation, or any other behavioral traits. The description adds some value with the cost disclosure but leaves significant gaps in behavioral understanding.

  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 brief (two sentences) and front-loaded with the core purpose. The cost information is efficiently appended. No redundant information or unnecessary elaboration is present. However, the first sentence could be more precisely structured to clearly separate purpose from usage guidance.

  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 risk assessment tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (list of deployers? risk scores? binary flag?), how results should be interpreted, or what 'serial rug deployer' means operationally. The cost disclosure helps but doesn't compensate for the missing behavioral and output context needed for effective tool 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% with one parameter fully documented in the schema. The description doesn't mention the 'min_tokens' parameter at all, nor does it provide any additional context about parameter usage, constraints, or implications. Since schema coverage is high, baseline is 3 even without parameter information in the description.

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

  Purpose3/5

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

  The description states the tool provides a 'serial rug deployer watchlist' for 'cross-reference before trusting new tokens', which gives a general purpose (identifying risky token deployers). However, it's somewhat vague about the exact function - it doesn't specify whether this returns a list, checks a specific token, or provides risk scores. It distinguishes from some siblings like 'get_api_status' but not clearly from other risk-checking tools like 'check_deployer_history' or 'check_token_risk'.

  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 mentions 'cross-reference before trusting new tokens' which provides some context for when to use it, but doesn't explicitly state when to choose this tool versus alternatives like 'check_deployer_history', 'check_token_risk', or 'marcus_forensics'. No guidance on prerequisites, limitations, or specific scenarios where this tool is preferred over siblings is provided.

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

• get_social_osintC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions a cost ($0.06) which is useful context, but doesn't describe what the analysis returns, whether it's a one-time or ongoing analysis, rate limits, authentication requirements, or what 'social infrastructure analysis' entails beyond the listed examples.

  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 efficiently structured in two sentences: one describing the analysis scope and one stating the cost. It's appropriately sized for a single-parameter tool, though it could be more front-loaded with the core purpose.

  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, no output schema, and complex social analysis functionality, the description is incomplete. It doesn't explain what the analysis returns, the format of results, error conditions, or how the listed examples (Twitter, Telegram, etc.) manifest in practice. The cost mention helps but doesn't compensate for missing behavioral 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?

  Schema description coverage is 100%, so the schema already documents the single 'token_address' parameter. The description doesn't add any parameter-specific information beyond what's in the schema, such as format requirements or how the token address relates to the social analysis. 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 performs 'social infrastructure analysis' with specific examples (Twitter account recycling, domain age, Telegram group legitimacy, cross-references), which provides a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_token_intelligence' or 'marcus_forensics' that might also analyze token-related social data.

  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 ($0.06), it doesn't specify use cases, prerequisites, or comparisons with sibling tools like 'check_token_risk' or 'get_token_intelligence' that might offer similar functionality.

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

• get_coordinated_buysB
  3.1/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 the cost ('$0.04'), which is useful behavioral context beyond the input schema. However, it lacks details on permissions, rate limits, output format, or error handling. The description doesn't contradict annotations (none exist), but it's minimal for a tool that likely returns complex data.

  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 concise with two sentences: one states the purpose, and the other adds cost information. It's front-loaded with the core functionality. However, the second sentence about cost could be integrated more smoothly, and there's room to add brief usage context without losing efficiency.

  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 detecting coordinated buying (likely involving multiple data points and analysis), no annotations, and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list of tokens, confidence scores), how results are structured, or any limitations (e.g., only covers tracked KOLs). The cost mention is helpful but insufficient 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 1 parameter with 100% description coverage, providing a baseline of 3. The tool description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain what 'hours' means in the context of coordinated buying or suggest typical values). It mentions 'short window' but doesn't link this to the 'hours' parameter explicitly.

  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: 'Detect coordinated buying across tracked KOLs. Identifies tokens where multiple influencers bought within a short window.' It specifies the verb ('detect'), resource ('coordinated buying'), and scope ('tracked KOLs'), but doesn't explicitly differentiate from sibling tools like 'get_kol_shills' or 'get_token_intelligence' that might involve KOL or token 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. It mentions a cost ('$0.04'), which implies a paid service, but doesn't specify prerequisites, ideal scenarios, or exclusions. With sibling tools like 'check_token_risk' and 'get_kol_shills', there's no indication of how this tool fits into the broader workflow.

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

• check_token_risk_premiumB
  3.2/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 the full burden. It mentions a cost of $0.10, which is useful behavioral context not in the schema. However, it lacks details on permissions, rate limits, response format, or whether it's a read-only or mutating operation. For a risk analysis tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

  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 concise and front-loaded, starting with the core purpose and listing key features in a single sentence. The second sentence adds usage and cost information efficiently. There is no wasted text, though it could be slightly more structured for clarity.

  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 complexity implied by 'deep risk analysis' and the lack of annotations and output schema, the description is somewhat incomplete. It covers the purpose and cost but misses details on behavioral traits, output format, and differentiation from siblings. This is adequate for a basic understanding but has clear gaps for effective tool selection.

  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 ('token_address' and 'chain') with clear descriptions and a default value. The description does not add any meaning beyond what the schema provides, such as explaining how these inputs affect the analysis. Baseline 3 is appropriate when the 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 performs 'Premium deep risk analysis' with specific components like 'category breakdown, deployer cross-reference, social OSINT, holder intelligence, and historical pattern matching', which distinguishes it from simpler risk checks. However, it doesn't explicitly differentiate from sibling tools like 'check_token_risk' or 'marcus_forensics', which might offer similar analyses.

  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 provides some guidance with 'Use for high-value positions', implying this tool is for important or large investments. It also mentions a cost of $0.10, which helps in decision-making. However, it doesn't specify when to use this over alternatives like 'check_token_risk' or 'marcus_quick', nor does it list any exclusions or prerequisites.

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

• get_token_intelligenceB
  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 mentions cost ($0.06), which is useful context about pricing. However, it doesn't disclose other important behavioral traits like rate limits, authentication requirements, response format, or whether this is a read-only operation (though 'get' in the name implies reading).

  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. The first sentence efficiently lists the comprehensive data provided, and the second adds important cost information. However, the list of data points could be more structured (e.g., grouped by category) for better readability.

  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 single parameter with full schema coverage and no output schema, the description provides adequate context about what data is returned and the cost. However, for a tool with no annotations and potentially complex return data (multiple metrics), it could benefit from more detail about response format or limitations.

  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 single parameter 'token_address' documented as 'Token address'. The description doesn't add any additional meaning about parameters beyond what the schema provides, so the baseline score of 3 is appropriate when the 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: providing comprehensive token data including price, volume, market cap, holder stats, and other metrics. It specifies the resource (token data) and scope (comprehensive), though it doesn't explicitly distinguish from sibling tools like 'check_token_risk' or 'watch_token' which might overlap in functionality.

  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_risk', 'check_token_risk_premium', and 'watch_token', there's no indication of how this tool differs or when it's preferred. The cost mention ($0.06) hints at a paid service but doesn't clarify usage context.

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

• marcus_threadB
  3.3/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 cost ($1.00) which is useful behavioral context, but doesn't disclose other traits like whether it's read-only, destructive, rate limits, authentication needs, or what the analysis entails beyond 'forensic.' For a tool with no annotations, this leaves significant gaps in behavioral understanding.

  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 highly concise with three short sentences that each add value: defines the tool's output format, suggests a use case, and states cost. It's front-loaded with the core purpose and wastes no 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 no annotations and no output schema, the description provides basic purpose and cost but lacks details on behavioral traits, output format beyond post count/char limit, or how it differs from siblings. It's minimally adequate for a 2-param tool but leaves gaps in understanding the tool's full context and results.

  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 fully documents both parameters (token_address and chain). The description doesn't add any parameter-specific meaning beyond what's in the schema, such as how these inputs affect the forensic analysis. 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 generates 'X/Twitter-thread-ready forensic analysis' with specific output characteristics (5-8 posts, each ≤280 chars) and mentions it's 'Perfect for research posting.' It specifies the verb (forensic analysis) and resource (token/blockchain via parameters), though it doesn't explicitly differentiate from sibling tools like marcus_forensics or marcus_quick.

  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 with 'Perfect for research posting' and mentions cost, but doesn't provide explicit guidance on when to use this tool versus alternatives like marcus_forensics or marcus_quick. It offers some implied context but lacks clear when/when-not instructions or named alternatives.

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

• get_kol_shillsB
  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 behavioral disclosure. It mentions cost ($0.06), which is useful context, but lacks details on permissions, rate limits, output format, or error handling. The description implies analysis but doesn't specify behavioral traits like data freshness 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.

  Conciseness4/5

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

  The description is appropriately sized and front-loaded with the core purpose, followed by cost information. Both sentences earn their place by defining functionality and operational context, though it could be slightly more structured for clarity.

  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 (analyzing influencer patterns), no annotations, no output schema, and 100% schema coverage, the description is minimally adequate. It covers purpose and cost but lacks details on output, error cases, or integration with sibling tools, leaving gaps for an AI agent.

  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 for the single parameter 'token_address', so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, but doesn't need to compensate for gaps.

  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 ('detection', 'promote') and resources ('KOL shill patterns', 'influencers', 'token'), distinguishing it from siblings like 'get_coordinated_buys' or 'get_social_osint' by focusing on influencer promotion timing and coordination 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 like 'get_coordinated_buys' or 'get_social_osint', nor does it mention prerequisites or exclusions. The cost mention hints at usage context but doesn't specify when to choose this over other tools.

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

• marcus_forensicsB
  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 full burden. It discloses time (~15-60s) and cost ($0.50) traits, which are valuable behavioral details. However, it doesn't mention error conditions, rate limits, authentication needs, or what specific output format to expect, leaving gaps for a comprehensive investigation 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: the first states purpose and scope, the second provides time and cost. It's front-loaded with the core functionality. Minor improvement could come from slightly better structuring of the investigation areas list.

  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 comprehensive investigation tool with 2 parameters, no annotations, and no output schema, the description provides adequate purpose and behavioral context (time/cost). However, it lacks details on output format, error handling, and differentiation from sibling tools, making it minimally complete but with clear gaps.

  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., no examples of valid addresses or chain selection guidance). 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 performs a 'full AI forensic investigation' covering multiple specific areas (deployer history, holder patterns, social OSINT, etc.), which provides a comprehensive verb+resource statement. However, it doesn't explicitly differentiate from sibling tools like 'marcus_quick' or 'marcus_ultra' that likely offer similar but different-scoped investigations.

  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 comprehensive token investigation with a time estimate (~15-60s) and cost ($0.50), providing some context. However, it doesn't explicitly state when to use this tool versus alternatives like 'marcus_quick' or 'check_token_risk', nor does it mention any exclusions or prerequisites for use.

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

• get_holder_deepdiveA
  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 full burden. It discloses the cost ('$0.10'), which is valuable behavioral context. However, it doesn't mention execution time, rate limits, authentication needs, or what specific output format to expect, leaving gaps for a tool with complex analysis capabilities.

  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 efficiently structured with a clear purpose statement followed by specific capabilities and cost information in just two sentences. However, the comma-separated list of analysis types could be slightly more readable with better formatting.

  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 complex analysis tool with no annotations and no output schema, the description provides good purpose and cost information but lacks details about what the analysis actually returns, how results are structured, or any limitations. The context signals suggest this is a single-parameter tool, but the analysis complexity warrants more complete documentation.

  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 one parameter clearly documented. The description doesn't add any parameter-specific information beyond what the schema provides, but with complete schema coverage, the baseline of 3 is appropriate as the schema handles the parameter documentation adequately.

  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 performs 'Deep holder analysis' with specific capabilities: sniper detection, Jito bundle analysis, fresh wallet clustering, whale concentration, and connected wallet patterns. It distinguishes from siblings by focusing on comprehensive holder analysis rather than risk checks, blacklists, or social intelligence.

  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 for detecting 'coordinated manipulation' in token holders, providing clear context. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the many sibling tools, though the analysis focus suggests differentiation from simpler checks.

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

• check_batch_riskA
  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 usefully adds cost information ('Cost: $0.30 (~$0.015 per token)') and throughput constraints ('up to 20 tokens at once'), which are valuable behavioral traits. However, it doesn't mention rate limits, authentication requirements, error handling, or response format details that would be helpful for a paid API 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 perfectly concise with three tightly packed sentences that each earn their place: first establishes core functionality, second specifies output, third provides cost and use case. No wasted words, and key 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?

  Given no annotations and no output schema, the description does well on purpose and cost transparency but leaves gaps. It doesn't describe the return format (what 'risk scores and recommendations' look like), error conditions, or authentication needs. For a paid batch processing tool with 2 parameters (one poorly documented), this is minimally adequate but 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?

  Schema description coverage is 50% (only 'tokens' parameter has a description). The description adds no specific parameter semantics beyond what's implied by 'tokens' and 'batch risk check.' It doesn't explain the 'chain' parameter's purpose or valid values, nor does it provide format details for token addresses. With partial schema coverage, the description doesn't adequately compensate for the undocumented 'chain' parameter.

  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 ('batch risk check'), resource ('tokens'), scope ('up to 20 tokens at once'), and output ('risk scores and recommendations for all tokens'). It distinguishes from siblings like check_token_risk (single token) and check_blacklist (different risk dimension) by emphasizing batch processing and portfolio screening context.

  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 ('ideal for portfolio screening'), implying it's for bulk analysis rather than single-token checks. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the 'batch' nature suggests it's for efficiency with multiple tokens.

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

• check_deployer_historyA
  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 full burden. It discloses cost ('Cost: $0.06'), which is useful behavioral context, but does not cover other traits like rate limits, authentication needs, response format, or error handling. The description adds some value but is incomplete for a tool with no annotations.

  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 in the first sentence, followed by usage context and cost. Every sentence earns its place with no wasted words, making it highly efficient 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 no annotations, no output schema, and a simple input schema, the description is adequate but has gaps. It covers purpose, usage, and cost, but lacks details on return values, error cases, or behavioral constraints. It meets minimum viability but could be more complete for trust evaluation.

  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 the single parameter 'deployer_address' documented in the schema. The description does not add meaning beyond the schema, such as format examples or constraints. 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.

  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 ('Check a token deployer's full history') and resource ('token deployer'), listing concrete outputs like tokens deployed, rug count, and classification. It distinguishes from siblings by focusing on deployer history rather than token risk, wallet checks, or other analytics.

  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 usage ('Essential for evaluating new token trustworthiness'), but does not explicitly state when not to use it or name specific alternatives among siblings. It implies usage for trust assessment but lacks explicit exclusions or comparisons.

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

• check_scammer_walletA
  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 states the core function and adds critical context about cost ('Cost: $0.02'), which is not covered by schema. However, it lacks details on rate limits, data sources, or response format, leaving some behavioral aspects 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 front-loaded with the core purpose in the first sentence and adds cost information efficiently in the second. Every sentence earns its place with no wasted words, 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's moderate complexity (single parameter, 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 data freshness, which are important for a scam-checking tool with financial implications.

  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 'wallet_address' documented in the schema. The description does not add any parameter-specific semantics beyond what the schema provides, such as address format or validation rules, so it meets the baseline for high schema 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 specific action ('Check if a wallet belongs to') and the target resource ('known scammer, serial rugger, or flagged entity'), distinguishing it from siblings like 'check_blacklist' or 'check_token_risk' by focusing on wallet-level scammer identification rather than general blacklisting or token-specific risks.

  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 (checking wallets for scammer status) but does not explicitly state when to use this tool versus alternatives like 'check_blacklist' or 'get_serial_ruggers'. It provides no exclusions or prerequisites, leaving usage guidance incomplete.

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

• marcus_quickA
  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 discloses key behavioral traits: latency (~5-30s) and cost ($0.15). It also hints at the AI's persona (Marcus Aurelius/Claude Sonnet 4) and output format (one-paragraph analysis). However, it doesn't cover 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 front-loaded with core purpose, efficiently lists output components, and includes operational details (latency, cost) in a single, waste-free sentence. Every element earns its place 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?

  For a tool with no annotations and no output schema, the description provides good context: purpose, output format, latency, and cost. It adequately covers the tool's behavioral profile, though could improve by mentioning error cases or output structure more explicitly.

  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 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter understanding.

  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: 'AI forensic verdict by Marcus Aurelius' with specific outputs (analysis with risk score, key flags, and Stoic wisdom). It distinguishes from siblings like 'check_token_risk' or 'marcus_forensics' by emphasizing a philosophical, narrative-driven analysis rather than just technical risk assessment.

  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 token analysis with optional questions, but lacks explicit guidance on when to choose this tool over alternatives like 'check_token_risk' or 'marcus_forensics'. No exclusions or prerequisites are mentioned, leaving the agent to infer context from the tool's name and description.

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

• marcus_ultraA
  4.1/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 discloses key behavioral traits: it's a paid service ('Cost: $2.00'), has extended processing time ('~30-120s'), and uses advanced AI ('Claude Opus 4 with extended reasoning'). It does not cover aspects like error handling or output format, but provides substantial operational context.

  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 highly concise and front-loaded, with every sentence adding value: it defines the tool's purpose, capabilities, processing time, and cost in a compact format without unnecessary words or redundancy.

  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 (AI forensic analysis) and no output schema, the description is moderately complete. It covers purpose, capabilities, time, and cost, but lacks details on output format, error cases, or limitations. With no annotations, it should provide more behavioral context for a high-stakes 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 description coverage is 100%, so the schema already documents both parameters fully. The description does not add any meaning beyond the schema, such as explaining how the token_address is used in analysis or chain implications. Baseline 3 is appropriate as 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 tool performs 'deepest AI forensic analysis' with specific capabilities like 'connected wallet clusters, timing correlations, historical rug playbook matching.' It distinguishes from siblings by emphasizing depth and extended reasoning, unlike quick checks or basic risk assessments.

  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 for in-depth forensic analysis on tokens, with context from sibling tools suggesting alternatives like 'marcus_quick' for faster checks or 'check_token_risk' for basic assessments. However, it does not explicitly state when to use this tool versus those alternatives, missing direct comparisons.

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

• check_token_riskA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and effectively discloses key behavioral traits: it's a read-only risk assessment tool (implied by 'check'), includes cost information, and details the comprehensive output (risk score, honeypot detection, etc.), though it lacks specifics on rate limits or error handling.

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

  Conciseness5/5

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

  The description is front-loaded with critical information ('CRITICAL: Check...'), uses efficient sentences that each add value (purpose, output details, cost), and avoids redundancy, 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 complexity of risk assessment, no annotations, and no output schema, the description is mostly complete: it covers purpose, usage timing, output details, and cost. However, it lacks information on response format or error cases, leaving minor gaps for a tool with rich functionality.

  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 additional parameter semantics beyond what the schema provides (e.g., it doesn't explain token_address formats or chain implications), but it doesn't need to compensate as schema coverage is high.

  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 ('check', 'returns') and resources ('token's rug pull risk score'), and distinguishes it from siblings by emphasizing it's for individual token risk assessment before transactions, unlike batch or premium checks.

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

  Usage Guidelines5/5

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

  It explicitly states when to use this tool ('BEFORE any transaction') and provides context on cost ('$0.04 per check'), helping users decide between this and alternatives like check_batch_risk or check_token_risk_premium based on urgency and budget.

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

• get_market_risk_indexA
  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 effectively describes key traits: it's a read operation (implied by 'get'), returns a daily index, includes cost information ($0.02), and explains what high values mean. It lacks details on rate limits or error handling, but for a zero-parameter tool, this is sufficient for good 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 highly concise and front-loaded, with every sentence earning its place: it defines the index, lists components, explains high values, and states the cost. There is no wasted text, making it efficient and well-structured for quick understanding.

  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 complexity (simple zero-parameter read), no annotations, no output schema, and 100% schema coverage, the description is mostly complete. It covers purpose, components, interpretation, and cost. However, it lacks details on output format (e.g., structure of the returned index), which would be helpful since there's no output schema, preventing a score of 5.

  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 input schema has 100% description coverage (though empty). The description adds no parameter information, which is appropriate. Since there are no parameters to document, a baseline of 4 is applied, as the description does not need to compensate for any gaps in schema 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 tool's purpose: it returns a daily market-wide rug risk index (0-100) with specific components listed (high_risk_ratio, rug_velocity, liquidity_drains, deployer_activity). It distinguishes itself from sibling tools by focusing on a broad market index rather than individual token or wallet checks, making the purpose specific and well-differentiated.

  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: to assess overall market rug risk, with a note that high values indicate more rugs happening and to exercise caution. However, it does not explicitly state when not to use it or name alternatives among sibling tools, such as for individual token checks, which would be needed for a score of 5.

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

• watch_tokenA
  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 and does well by disclosing key behavioral traits: it's a setup operation with ongoing monitoring, specifies cost ($0.20), duration (7 days), and the alert mechanism (POST to webhook). It could improve by mentioning rate limits or error handling, but covers essential 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 front-loaded with the core purpose, followed by key details (events, duration, uniqueness, cost) in a compact three-sentence format. Every sentence adds value without redundancy, making it highly efficient and easy to parse.

  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 complexity (setup for ongoing monitoring), lack of annotations, and no output schema, the description is largely complete: it covers purpose, behavior, parameters, and cost. It could be enhanced by specifying response format or error cases, but for a tool with structured input schema, it provides sufficient context for effective use.

  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 low (33%), with only webhook_url documented. The description compensates by adding meaning: it implies token_address is for monitoring, explains watch_type options (risk changes, rug detected, price drops), and clarifies the webhook_url's role in alerts. However, it doesn't detail token_address format or default behaviors beyond watch_type.

  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 ('Set up real-time token monitoring with webhook alerts') and resources ('token'), distinguishing it from siblings like check_token_risk (which appears to be a one-time check) by emphasizing proactive, continuous monitoring. It explicitly mentions unique features like 'proactive rug detection' and '7 days' coverage.

  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 real-time monitoring with alerts on specific events (risk changes, rug detected, price drops). However, it does not explicitly state when not to use it or name alternatives among siblings, such as check_token_risk for one-time assessments, leaving some guidance implicit.

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

• get_api_statusA
  4.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 communicates that the tool is free and non-destructive (implied by 'Get'), and it hints at a pre-call verification use case. However, it lacks details on rate limits, error handling, or response format, leaving some behavioral aspects unspecified.

  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 key information in two concise sentences: the first states the purpose and resources, and the second provides usage guidelines and cost. Every sentence adds value without redundancy, making it efficient 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 low complexity (0 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, and cost, but could improve by mentioning response format or error cases. For a simple status-check tool, this is sufficient but not exhaustive.

  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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by clarifying the tool's scope (e.g., 'service status, performance metrics') beyond what the empty schema indicates, justifying a score above the baseline 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 ('Get') and resources ('service status, performance metrics, trust score, and pricing'), distinguishing it from siblings focused on risk assessment, intelligence gathering, or monitoring. It explicitly identifies what information is retrieved, 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 Guidelines5/5

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

  The description provides explicit guidance on when to use this tool ('to verify the service is up before making paid calls') and includes a cost consideration ('FREE — no payment required'), which helps differentiate it from potentially paid alternatives. This gives clear context for its application.

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