Server Quality Checklist

Tool Scores

• get_token_infoB
  3.1/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 states the tool 'abfragen' (queries/retrieves), implying a read-only operation, but doesn't clarify aspects like rate limits, authentication needs, error handling, or whether it's a real-time query. For a tool with zero 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 appropriately sized and front-loaded: the first sentence states the purpose, the second lists returned data, and the 'Args' section explains the parameter. There's minimal waste, though the structure could be slightly improved by integrating the parameter explanation more seamlessly rather than as a separate labeled section.

  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 (1 parameter, no output schema, no annotations), the description is partially complete. It covers the purpose and parameter semantics adequately but lacks behavioral details (e.g., performance, errors) and usage guidelines relative to siblings. Without an output schema, it doesn't explain return values beyond listing fields, leaving some ambiguity about data format.

  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 schema description coverage is 0%, so the description must compensate. It adds meaningful semantics by explaining that the 'token' parameter can be either a token symbol (e.g., 'SOL', 'JUP') or a mint address, which clarifies usage beyond the schema's generic 'string' type. Since there's only one parameter, this effectively covers it, though it doesn't detail format constraints or examples beyond the two given.

  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: 'Metadaten eines Solana-Tokens abfragen' (retrieve metadata of a Solana token). It specifies the exact data returned (Name, Symbol, Supply, Decimals, Authorities), making the verb+resource combination specific. However, it doesn't explicitly differentiate from sibling tools like 'get_token_price' or 'check_token_safety', 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. With sibling tools like 'get_token_price' (for price data) and 'check_token_safety' (for safety checks), the description lacks explicit instructions on when this metadata-focused tool is appropriate, nor does it mention prerequisites or exclusions.

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

• get_transaction_historyB
  3.1/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 the tool retrieves recent transactions with specific fields, but lacks critical details: whether it's read-only (implied but not stated), rate limits, error conditions, authentication needs, or what happens with invalid addresses. The description adds minimal behavioral context beyond the basic operation.

  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, followed by details about displayed fields and parameter explanations. The Args section is clearly formatted. While efficient, the German language might add minor cognitive load for English-only agents.

  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 2 parameters with no output schema and no annotations, the description is minimally adequate. It covers the basic operation and parameters but lacks information about return format, error handling, performance characteristics, or how it differs from sibling tools. For a financial data tool, more context about data freshness or source would be helpful.

  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?

  With 0% schema description coverage, the description compensates well by explaining both parameters: 'wallet_address' format (Base58) and 'limit' details (default 10, maximum 50). This adds meaningful semantics beyond what the bare schema provides, though it doesn't cover edge cases or validation rules.

  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: retrieving recent transactions for a Solana wallet with specific details (type, description, timestamp). It uses a specific verb ('abrufen' - retrieve) and identifies the resource (Solana wallet transactions). However, it doesn't explicitly differentiate from sibling tools like 'get_wallet_balance' beyond the transaction focus.

  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 doesn't mention sibling tools like 'get_wallet_balance' for balance checks or 'check_token_safety' for token analysis, nor does it specify prerequisites or appropriate contexts beyond the basic function.

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

• get_usage_statsB
  3.1/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 describes what data is returned but doesn't disclose important behavioral traits: whether this requires admin permissions, if it's a read-only operation, how frequently data is updated, whether it includes historical data, or if there are rate limits. The description is purely functional without behavioral context.

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

  Conciseness4/5

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

  The description is appropriately concise with two short sentences that directly state the tool's function and what it displays. It's front-loaded with the main purpose. The German language structure is clear and efficient with no 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?

  For a zero-parameter tool with no output schema, the description provides adequate functional information about what data is returned. However, it lacks important contextual details: no information about permissions needed, data freshness, or whether this is a monitoring/admin tool versus general usage. Given that sibling tools are all DeFi-related, this server-monitoring tool's context isn't fully established.

  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 (schema coverage 100%), so there's no need for parameter documentation. The description appropriately focuses on what the tool returns rather than input parameters. With no parameters to document, this meets the baseline expectation.

  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: retrieving usage statistics for the MCP server, specifically listing total tool calls, calls per tool, and first/last call timestamps. It uses specific verbs ('abrufen' - retrieve, 'zeigt' - shows) and identifies the resource (MCP server usage statistics). However, it doesn't explicitly differentiate from sibling tools, which are all related to token/DeFi operations rather than server monitoring.

  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 doesn't mention prerequisites, appropriate contexts, or exclusions. Given that all sibling tools are focused on token/DeFi operations while this tool monitors server usage, the distinction is implicit but not stated.

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

• get_wallet_balanceB
  3.1/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 states what the tool returns (SOL balance and token positions) but doesn't mention important behavioral aspects like rate limits, authentication requirements, error conditions, or whether this is a read-only operation (though implied by 'abfragen').

  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 well-structured and appropriately sized. It starts with the core purpose, then specifies what's returned, and finally details the parameter with an example. The German language doesn't affect conciseness scoring. Every sentence adds value.

  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 single-parameter query tool with no annotations and no output schema, the description is adequate but has gaps. It explains what the tool does and the parameter well, but doesn't describe the return format in detail (beyond 'SOL-Balance und alle Token-Positionen') or address potential limitations or error cases.

  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?

  With 0% schema description coverage and only 1 parameter, the description provides excellent parameter semantics. It clearly explains the wallet_address parameter, specifies the required format (Base58), and gives a concrete example. This fully compensates for the lack of schema documentation.

  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: querying SOL and token balances for a Solana wallet. It specifies the verb ('abfragen' - query/retrieve) and resource (wallet balances), but doesn't explicitly differentiate from sibling tools like 'get_transaction_history' or 'get_token_info' which might also involve wallet 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. It doesn't mention sibling tools like 'get_token_info' or 'get_transaction_history' that might serve related purposes, nor does it specify prerequisites or appropriate contexts for balance queries.

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

• check_token_safetyA
  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 does well by describing what the tool checks (specific risk factors) and its helpfulness for scam detection, but lacks details on behavioral traits like rate limits, authentication needs, error handling, or what the output format looks like (since no output schema exists).

  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, starting with the core purpose followed by specific checks and usage context. The Args section is clear but slightly redundant with the schema. Every sentence adds value, though minor trimming (e.g., integrating the Args into the main text) could improve 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 complexity (safety analysis with multiple risk factors), no annotations, and no output schema, the description is moderately complete. It covers the purpose, parameters, and usage context well, but lacks details on output format, error cases, or limitations (e.g., data freshness, coverage), leaving gaps for an agent to use it effectively.

  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 description adds meaningful semantics for the single parameter 'token' by explaining it can be either a token symbol (e.g., 'BONK') or a mint address, which goes beyond the schema's generic string type. With 0% schema description coverage and only one parameter, this compensation is effective, though it could specify format constraints more precisely.

  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 ('Sicherheitscheck durchführen', 'Prüft') and resources ('Solana-Token'), listing exactly what it checks (RugCheck-Score, Mint/Freeze-Authority, etc.). It distinguishes itself from sibling tools like get_token_info or get_token_price by focusing specifically on safety/risk assessment rather than general information or pricing.

  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 ('Hilfreich um Scam-Tokens und Honeypots zu erkennen'), indicating it's for detecting malicious tokens. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools (e.g., use get_token_info for general details instead).

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

• compare_yieldsA
  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. It discloses key behavioral traits: searches across all Solana DEXs, compares APRs, and automatically filters out scam pools. However, it doesn't mention rate limits, authentication needs, error conditions, or what happens when no pools are found.

  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 three main sentences plus parameter explanations. It's front-loaded with the core purpose, though the Args section formatting could be slightly cleaner. Every sentence adds value with no 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?

  For a 2-parameter tool with no annotations and no output schema, the description covers the basic operation well but has gaps. It explains what the tool does and parameters but doesn't describe return format, error cases, or performance characteristics. Given the complexity of DeFi yield comparison, more context would be helpful.

  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?

  With 0% schema description coverage, the description compensates well by explaining both parameters. It clarifies that 'token' accepts either symbol or mint address with examples, and 'limit' is maximum total pools with default value. This adds meaningful context beyond the bare schema.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with specific verbs ('Sucht', 'vergleicht', 'Filtert') and resources ('Token', 'Pools', 'APRs'). It distinguishes from siblings by focusing on cross-DEX yield comparison rather than safety checks, general info, prices, 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 (comparing yields across Solana DEXs for a specific token). However, it doesn't explicitly state when NOT to use it or mention alternatives like 'get_defi_yields' among siblings, which might offer different yield-related functionality.

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

• get_defi_yieldsA
  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 adds valuable context about scam filtering (minimum TVL: $1,000) and multi-DEX coverage, which aren't obvious from the schema. However, it doesn't mention rate limits, authentication requirements, or what the output looks like (format, 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 well-structured with purpose statement, behavioral context, and parameter details in a clear format. Every sentence adds value, though the German-to-English mix might slightly hinder readability for some users. It's appropriately sized for a tool with two parameters and no annotations.

  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 parameters and purpose but has gaps. It doesn't describe the return format (e.g., list of pools with fields like APR, TVL), which is critical for a data retrieval tool. The scam filtering detail is helpful, but overall completeness is moderate for this complexity level.

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

  Parameters5/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 fully compensate. It provides comprehensive parameter details: 'sort_by' with three options (apr, tvl, volume) and defaults, and 'limit' with default (10) and maximum (25) values. This adds complete meaning beyond the bare schema, making parameters fully understandable.

  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: 'Top DeFi-Pool-Yields auf Solana abrufen (Raydium + Orca)' specifies retrieving yield data from specific DEXs on Solana. It distinguishes from siblings like 'compare_yields' by focusing on top yields rather than comparisons, and from 'get_token_info' by targeting pool yields rather than token metadata.

  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 get top yield opportunities from Raydium and Orca with scam filtering. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'compare_yields' for detailed yield comparisons, which would be helpful for sibling differentiation.

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

• get_token_priceA
  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 full burden and adds valuable behavioral context: it discloses the dual data source strategy (Jupiter primary, CoinGecko fallback) and specifies the currency (USD). However, it doesn't mention rate limits, error handling, or response format details that would be helpful for an agent.

  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 efficiently structured with a clear purpose statement, behavioral details, and parameter explanation in just three lines. Every sentence earns its place, and information is front-loaded with the core functionality stated first.

  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 single-parameter query tool with no annotations and no output schema, the description provides good context: purpose, data sources, parameter semantics. However, it doesn't describe the return value format (e.g., numeric price, timestamp, source attribution) which would help the agent interpret results.

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

  Parameters5/5

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

  With 0% schema description coverage and only 1 parameter, the description fully compensates by explaining the 'token' parameter accepts either a token symbol (e.g., 'SOL', 'BONK') or a mint address. This adds crucial semantic meaning beyond the bare schema's string 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 specific action ('Aktuellen USD-Preis...abfragen' - query current USD price) and resource ('eines Solana-Tokens' - of a Solana token). It distinguishes from siblings like 'get_token_info' (general info) and 'get_wallet_balance' (balance check) by focusing exclusively on price retrieval.

  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 it's for Solana tokens and mentions data sources (Jupiter primary, CoinGecko fallback), but doesn't explicitly state when to use this tool versus alternatives like 'get_token_info' (which might include price) or 'compare_yields' (which involves yield comparison). No explicit when-not-to-use guidance is provided.

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