Server Quality Checklist

Tool Scores

• get-account-infoC
  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. The description only states what the tool does ('Get current account information') without adding any behavioral context such as authentication requirements, rate limits, error conditions, or what the return format might look like. It's minimal and lacks details needed for safe and effective use.

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

  Conciseness5/5

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

  The description is extremely concise with a single sentence, 'Get current account information', which is front-loaded and wastes no words. Every part of the sentence contributes directly to stating the tool's purpose, 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.

  Completeness2/5

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

  Given the complexity (a tool with one required parameter in a blockchain context) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'current account information' entails, how it relates to other account tools, or what the output might contain. For a tool in this domain, more context is needed to ensure proper use.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the parameter 'networkName' fully documented in the schema itself. The description adds no additional information about parameters beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline score is 3 even if the description lacks param info, which applies here.

  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 'Get current account information' clearly states the verb ('Get') and resource ('current account information'), making the purpose understandable. However, it's somewhat vague about what specific account information is retrieved, and it doesn't differentiate from sibling tools like 'get-balance' or 'get-delegations', which might provide overlapping or related account 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. There are multiple sibling tools that might retrieve account-related information (e.g., 'get-balance', 'get-delegations', 'get-available-rewards'), but the description doesn't specify what makes this tool unique or when it should be preferred over others. No explicit context or exclusions are mentioned.

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

• get-block-infoC
  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. 'Get block information' implies a read-only operation, but it doesn't specify whether this requires authentication, has rate limits, returns structured data, or involves side effects. For a tool with no annotation coverage, this is a significant gap in describing behavioral traits.

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

  Conciseness5/5

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

  The description is extremely concise with just three words: 'Get block information'. It's front-loaded and wastes no space, making it easy to parse. Every word earns its place by conveying the core action and resource without unnecessary elaboration.

  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 blockchain tools, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'block information' includes (e.g., transactions, timestamps), how results are formatted, or error conditions. For a tool in this context with rich sibling tools, more detail is needed to guide the agent effectively.

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

  Parameters3/5

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

  The description adds no parameter semantics beyond what the input schema provides. With 100% schema description coverage, the schema fully documents both parameters ('height' and 'networkName'), including defaults and prerequisites. The description doesn't compensate or add extra meaning, so it meets the baseline of 3 for high schema coverage.

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

  Purpose3/5

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

  The description 'Get block information' states a clear verb ('Get') and resource ('block information'), but it's vague about what specific information is retrieved. It doesn't distinguish this tool from potential siblings like 'get-account-info' or 'query-network' beyond the resource type. The purpose is understandable but lacks specificity.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. While the input schema hints at usage by requiring 'networkName' and referencing the 'networks' resource, the description itself offers no explicit when-to-use, when-not-to-use, or alternative tool recommendations. This leaves the agent to infer usage from schema details alone.

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

• bank-sendC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but only states it 'supports sending multiple coins in one transaction.' It doesn't disclose critical behavioral traits like whether it's a write operation (implied by 'Send'), authentication needs, rate limits, transaction fees, confirmation times, or error conditions. This leaves significant gaps for a tool that likely modifies blockchain state.

  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?

  Two concise sentences with zero waste. The first sentence states the core purpose, and the second adds a useful behavioral detail. It's appropriately sized and front-loaded, though it could be slightly more structured with bullet points or separation of key points.

  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 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks information about return values, error handling, network dependencies (beyond the parameter hint), and behavioral implications like transaction finality or security considerations. This is inadequate for a tool that likely performs financial transactions.

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

  Parameters3/5

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

  Schema description coverage is 100%, providing clear documentation for all parameters (coins, memo, networkName, recipientAddress). The description adds minimal value beyond the schema, only reinforcing that multiple coins can be sent. No additional syntax, format, or constraints are provided beyond what's in the schema descriptions.

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

  Purpose4/5

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

  The description clearly states the action ('Send tokens') and resource ('to another address'), with the additional detail about supporting multiple coins. It distinguishes from siblings like 'get-balance' or 'delegate' by focusing on token transfers, though it doesn't explicitly contrast with similar tools like 'ibc-transfer'.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives like 'ibc-transfer' (for cross-chain) or 'contract-execute' (for smart contract interactions). The description implies it's for direct token transfers but lacks context about prerequisites, network selection, or comparison with siblings.

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

• claim-rewardsC
  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 the full burden of behavioral disclosure. It states 'claim rewards' which implies a write/transaction operation, but doesn't disclose critical traits: whether this requires authentication, has side effects (e.g., on-chain transaction), involves fees, is irreversible, or has rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, though it could be slightly more informative without losing conciseness (e.g., by hinting at transaction behavior).

  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 a blockchain transaction tool with no annotations and no output schema, the description is incomplete. It doesn't address key contextual aspects: what the tool returns (success/failure, transaction hash), error conditions, or behavioral implications (e.g., that it's a write operation). This leaves gaps for the agent to understand the tool's full impact.

  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 clear descriptions for all three parameters in the input schema (e.g., 'operatorAddress' as the validator address, 'networkName' with usage instructions). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 where 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 action ('claim rewards') and the target resource ('for a specific validator'), which provides a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get-available-rewards' or 'undelegate', which would require mentioning what makes this tool distinct (e.g., that it's a transaction vs. a query).

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing available rewards first), exclusions, or comparisons to siblings like 'get-available-rewards' (which might check rewards before claiming) or 'delegate' (which involves staking). This leaves the agent without context for tool selection.

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

• contract-executeC
  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 'changes state' which indicates this is a write/mutation operation, but doesn't describe transaction costs, gas requirements, confirmation times, error conditions, or what happens on failure. For a state-changing blockchain operation, this is a significant gap in 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.

  Conciseness5/5

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

  Single sentence, zero waste. Every word contributes to the core purpose. The description is appropriately sized and front-loaded with the essential information.

  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 state-changing blockchain operation with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, transaction lifecycle, or important behavioral aspects. The agent would need to guess about many critical operational details.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter information beyond what's in the schema. Baseline 3 is appropriate when the schema does the heavy lifting, though the description could have provided context about how these parameters interact.

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

  Purpose4/5

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

  The description clearly states the action ('execute a function') and target ('on a smart contract'), with the qualifier 'that changes state' indicating this is a write operation. It distinguishes from sibling 'contract-query' which would be read-only, but doesn't specify what kind of functions or state changes are possible.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives like 'bank-send', 'delegate', or other contract-related operations. The description implies it's for state-changing contract interactions, but doesn't specify prerequisites, constraints, or when other tools might be more appropriate.

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

• delegateC
  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 but only states the basic action. It doesn't disclose critical behavioral traits like whether this is a write operation (implied but not explicit), what permissions are needed, transaction costs, confirmation times, or what happens on failure. For a financial transaction tool with zero annotation coverage, 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.

  Conciseness5/5

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

  The description is extremely concise at just three words, with zero wasted text. It's front-loaded with the core action and target, making it immediately understandable.

  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 financial transaction tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or important behavioral context. The schema handles parameter documentation, but the description fails to provide necessary operational 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 all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema descriptions, meeting the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('Delegate/Stake tokens') and target ('to a validator'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'undelegate' or 'get-delegations' beyond the basic verb distinction.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like 'undelegate' or 'get-delegations'. The description only states what it does, not when it's appropriate or what prerequisites might exist.

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

• get-available-rewardsC
  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 the full burden of behavioral disclosure. It states it 'gets' rewards, implying a read-only query, but doesn't clarify if this is a safe operation, what permissions are needed, how data is returned (e.g., format, pagination), or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

  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 tool's complexity (querying rewards with 2 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'available rewards' entail, how results are structured, or any behavioral traits like safety or performance. This leaves the agent with insufficient context for effective use.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters ('address' and 'networkName') with descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining how 'address' relates to rewards or elaborating on 'networkName' usage. Baseline 3 is appropriate as the schema handles 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 action ('Get') and resource ('all available rewards for an address'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'claim-rewards' or 'get-balance', which might involve similar resources but different operations.

  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, exclusions, or compare to siblings such as 'claim-rewards' (which might be for claiming rather than querying) or 'get-balance' (which might retrieve different financial data).

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

• get-delegationsC
  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 but only states what the tool does without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, potential rate limits, authentication needs, error conditions, or response format, which are critical for a tool querying blockchain data.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

  Completeness2/5

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

  Given the complexity of blockchain/staking tools, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'staking information' entails (e.g., delegation amounts, validator details), potential response structure, or error handling, leaving significant gaps for agent 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?

  Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't clarify what 'current staking information' includes or how the address should be formatted), meeting the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('Get') and target resource ('current staking information for an address'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-available-rewards' or 'delegate', which also relate to staking operations, so it doesn't reach the highest 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 like 'get-available-rewards' or 'delegate'. It doesn't mention prerequisites, exclusions, or comparative contexts, leaving the agent with minimal usage direction beyond the basic purpose.

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

• get-validatorsC
  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 the full burden of behavioral disclosure. 'Get all validators' implies a read-only operation but doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the validators data takes. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.

  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 maximally concise at just three words. Every word earns its place: 'Get' specifies the action, 'all' indicates scope, and 'validators' identifies the resource. There's zero wasted language or unnecessary elaboration in this minimal but complete phrase.

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

  Completeness2/5

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

  For a tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'validators' means in this blockchain context, what data is returned, whether results are paginated, or any error conditions. Given the complexity implied by the sibling tools (delegation, contracts, DEX operations), this simple description leaves too much unspecified.

  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 mentions no parameters, which is appropriate since the single parameter 'networkName' is fully documented in the schema (100% coverage). The schema provides comprehensive details about the networkName requirement and even includes usage guidance about checking available networks first. The description correctly avoids duplicating this information.

  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 'Get all validators' states the verb ('Get') and resource ('validators'), making the basic purpose clear. However, it's vague about scope and doesn't differentiate from sibling tools like 'get-delegations' or 'get-account-info' that also retrieve blockchain data. The description lacks specificity about what 'all' means in this context.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get-delegations' and 'get-account-info' that also retrieve blockchain information, there's no indication of when this specific validator-focused tool is appropriate versus other data retrieval tools. The input schema mentions checking networks first, but this isn't part of the description itself.

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

• ibc-transferC
  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 but only states the basic action without disclosing behavioral traits. It doesn't mention whether this is a read-only or destructive operation, authentication requirements, rate limits, error conditions, or what happens on success/failure. For a complex 9-parameter tool with 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.

  Conciseness5/5

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

  The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core functionality. Every word earns its place in conveying the tool's 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?

  Given the tool's complexity (9 parameters, nested objects, no output schema, and no annotations), the description is insufficient. It doesn't explain what IBC transfer entails, what the expected outcome is, error handling, or how this differs from simpler transfer tools. For a tool with this level of complexity and no structured safety information, the description should provide more 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 all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.

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

  Purpose4/5

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

  The description clearly states the action ('Send tokens') and the mechanism ('via IBC transfer'), which is specific and distinguishes it from sibling tools like 'bank-send' that likely handle on-chain transfers. However, it doesn't explicitly differentiate from other cross-chain or transfer-related tools beyond the IBC specification.

  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 'bank-send' or 'dex-swap'. It lacks context about prerequisites (e.g., needing IBC channels set up) or scenarios where IBC transfers are appropriate compared to other transfer methods.

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

• undelegateC
  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 but only states the action without behavioral details. It doesn't disclose whether this is a transaction requiring fees, confirmation time, irreversible effects, or network-specific constraints. The agent must infer these critical aspects from context alone.

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

  Conciseness5/5

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

  The description is a single, efficient phrase that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

  Completeness2/5

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

  For a financial transaction tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It lacks crucial context about transaction behavior, outcomes, error conditions, or relationship to sibling tools like 'delegate' and 'get-delegations', leaving significant gaps for agent 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?

  Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional parameter semantics beyond implying 'tokens' relate to 'amount' and 'denom'. This meets the baseline for high schema coverage but doesn't enhance understanding.

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

  Purpose4/5

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

  The description clearly states the action ('Undelegate/Unstake') and resource ('tokens from a validator'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'delegate' beyond the opposite action, missing explicit comparison that would earn a 5.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., having delegated tokens first), contrast with 'delegate', or specify scenarios where undelegation is appropriate versus other actions like claiming rewards.

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

• dex-get-poolsB
  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 what the tool does but doesn't describe behavioral traits such as whether it's a read-only operation, potential rate limits, authentication requirements, or what the output format looks like (e.g., list structure, pagination). This is a significant gap for a tool with no annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.

  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 simplicity (one required parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks context on usage, behavioral details, and output expectations. For a tool with no annotations or output schema, more completeness would be beneficial to guide the agent effectively.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the parameter 'networkName' fully documented in the schema itself. The description adds no additional meaning beyond what the schema provides, such as explaining why network selection is necessary or how it affects the results. This meets the baseline of 3 when schema coverage is high.

  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 verb 'Get' and the resource 'all available liquidity pools from the DEX', which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'dex-find-routes' or 'dex-simulate-swap', which also involve DEX operations but for different purposes.

  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 (e.g., needing to check networks first, as hinted in the parameter description) or compare it to other DEX-related tools like 'dex-find-routes' for routing or 'dex-simulate-swap' for simulations.

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

• contract-queryB
  3.2/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 but only states it's 'read-only' without detailing behavioral aspects like error handling, response format, rate limits, or authentication needs. It mentions executing a function but doesn't explain what happens if the contract address is invalid or the query fails.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('Query a smart contract') with a clarifying detail ('executing a read-only function'). There is no wasted verbiage, and it directly communicates the essential information without redundancy.

  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 3 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on behavioral traits, error cases, or output format, leaving gaps in understanding how to use it effectively beyond the basic purpose. The schema covers parameters, but the description doesn't compensate for missing context.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional semantic context beyond implying 'queryMsg' is for read-only functions, which is already suggested by 'read-only' in the description. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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

  Purpose4/5

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

  The description clearly states the action ('query') and target ('smart contract') with the specific operation mode ('executing a read-only function'). It distinguishes from siblings like 'contract-execute' by specifying read-only nature, though it doesn't explicitly contrast with all query-related tools like 'get-balance' or 'query-network'.

  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 read-only contract interactions, suggesting when to use it versus write operations. However, it doesn't provide explicit guidance on when to choose this over other query tools like 'get-balance' or 'query-network', nor does it mention prerequisites like network availability checks referenced in the schema.

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

• get-balanceB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the default behavior for the address parameter, which is useful context. However, it doesn't describe what the balance represents (e.g., native tokens, specific denomination), whether this is a read-only operation (implied but not stated), potential rate limits, authentication requirements, or error conditions. For a financial tool with zero annotation coverage, this leaves significant gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that immediately conveys the core functionality and key behavioral nuance (the default address). Every word earns its place with zero redundancy or unnecessary elaboration. The structure is front-loaded with the primary purpose followed by the important qualification.

  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 (financial balance query), no annotations, no output schema, and 100% schema coverage, the description is minimally adequate. It covers the basic purpose and one behavioral aspect (default address), but doesn't address what the return value contains, error conditions, or relationship to sibling tools. The description works but leaves the agent with unanswered questions about the operation's full 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 both parameters thoroughly. The description adds marginal value by reinforcing the default behavior for the address parameter ('defaults to your own address if none provided'), but doesn't provide additional semantic context beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.

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

  Purpose4/5

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

  The description clearly states the verb 'Get' and resource 'balance of an address', making the purpose immediately understandable. It distinguishes from siblings like 'get-account-info' or 'get-delegations' by focusing specifically on balance retrieval rather than broader account information. However, it doesn't explicitly contrast with these similar tools, preventing 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 Guidelines3/5

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

  The description provides implied usage guidance by mentioning the default behavior when no address is provided, which helps understand when to omit the parameter. However, it doesn't explicitly state when to use this tool versus alternatives like 'get-account-info' (which might include balance among other data) or provide any exclusion criteria. The guidance is helpful but incomplete.

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

• dex-find-routesA
  3.6/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. While it mentions a prerequisite check, it doesn't describe what the tool actually returns (e.g., route details, costs, limitations), whether it's read-only or has side effects, or any performance/rate limit considerations. For a tool that finds swap routes with no annotation coverage, this leaves significant behavioral gaps.

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

  Conciseness5/5

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

  The description is extremely concise and front-loaded: the core purpose is stated first, followed by a crucial prerequisite instruction. Both sentences earn their place by providing essential information without any wasted words, making it easy for an agent to parse quickly.

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

  Completeness2/5

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

  Given that there's no output schema and no annotations, the description should provide more context about what the tool returns and its behavioral characteristics. While it helpfully mentions a prerequisite, it doesn't explain the output format, potential errors, or how routes are determined, leaving the agent with incomplete information for proper tool invocation and result interpretation.

  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 fully documents all three parameters (networkName, tokenInDenom, tokenOutDenom). The description doesn't add any additional parameter semantics beyond what's in the schema, such as format examples or constraints. This meets the baseline expectation when schema coverage is complete.

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

  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: 'Find available swap routes between two tokens.' This specifies the verb ('find') and resource ('swap routes'), making it immediately understandable. However, it doesn't explicitly distinguish this tool from its sibling 'dex-simulate-swap' or 'dex-swap', which likely involve similar swap-related functionality.

  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 usage guidance: 'must first check two tokens are available in the DEX pools by using `dex-get-pools`.' This clearly indicates a prerequisite action and names the specific alternative tool to use first, helping the agent understand when and how to properly sequence operations.

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

• dex-swapA
  3.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 the prerequisite check but doesn't describe key behavioral traits: it doesn't state that this is a destructive/write operation (implied by 'Execute' but not explicit), doesn't mention transaction costs, rate limits, or error conditions, and doesn't specify what happens on success/failure. For a financial transaction 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that immediately states the core purpose and provides critical usage guidance. Every word earns its place, with no redundancy or unnecessary elaboration. It's perfectly front-loaded with the main action.

  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 of a DEX swap (financial transaction with multiple parameters) and the absence of both annotations and output schema, the description is incomplete. It provides excellent usage guidance but lacks behavioral context about the transaction's nature, costs, or outcomes. The 100% schema coverage helps with parameters, but for a tool that likely modifies state and involves financial risk, more behavioral disclosure would be expected.

  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 6 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

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

  Purpose4/5

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

  The description clearly states the action ('Execute a token swap') and the resource ('on the DEX'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'dex-simulate-swap' or 'dex-find-routes', which prevents a perfect score, but the verb 'Execute' suggests this performs the actual transaction rather than simulation or route finding.

  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 explicitly states when to use this tool ('must first check two tokens are available in the DEX pools by using `dex-get-pools`'), providing clear prerequisites and naming a specific alternative tool. This gives strong guidance on the required sequence of operations, which is crucial for correct usage in a DEX context.

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

• query-networkA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses that this is a generic query execution tool requiring pre-checks of OpenAPI specs and network availability, which adds useful behavioral context. However, it doesn't mention error handling, rate limits, authentication needs, or response formats, leaving gaps for a tool with 6 parameters.

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

  Conciseness4/5

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

  The description is appropriately sized with two sentences that are front-loaded: the first states the purpose and usage condition, the second provides prerequisites. Every sentence adds value, though it could be slightly more streamlined by integrating the prerequisites more seamlessly.

  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 (6 parameters, no output schema, no annotations), the description is partially complete. It covers usage context and prerequisites well but lacks details on behavioral traits like error handling or response structure. For a generic query tool with many siblings, more guidance on typical use cases would enhance completeness.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds minimal parameter semantics beyond the schema, only implying that 'networkName' and 'path' relate to OpenAPI specs. It doesn't explain how parameters interact or provide examples, meeting the baseline for high schema coverage.

  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: 'Execute a generic network gRPC Gateway query against chain APIs.' It specifies the action (execute query) and target (chain APIs via gRPC Gateway). However, it doesn't explicitly differentiate from sibling tools like 'contract-query' or 'get-balance' beyond being a fallback option.

  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 usage guidance: 'when you cannot find the required information from other tools.' It instructs to first check available queries via the OpenAPI spec and networks via the networks resource, establishing clear prerequisites and when to use this tool versus alternatives.

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

• dex-simulate-swapA
  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. It clearly indicates this is a simulation (non-executing) operation, which is valuable behavioral context. However, it doesn't mention potential limitations like whether it accounts for slippage, gas fees, or pool depth, which would be helpful for a simulation 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?

  Two concise sentences that are front-loaded with the core purpose and followed by essential prerequisite guidance. Every word earns its place with no redundancy or unnecessary elaboration.

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

  Completeness3/5

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

  For a simulation tool with no annotations and no output schema, the description provides good purpose and usage guidance but lacks information about what the simulation returns (expected output amounts, fees, success indicators). The context about checking pools first is helpful but doesn't fully compensate for the missing output details.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description doesn't add any additional parameter information beyond what's in the schema, maintaining the baseline score 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 ('simulate a token swap'), the resource ('tokens'), and distinguishes it from execution ('to get expected outcome without executing it'). It differentiates from sibling 'dex-swap' which would be the actual execution tool.

  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?

  Explicitly states when to use this tool ('to get expected outcome without executing it') and provides a prerequisite action ('must first check two tokens are available in the DEX pools by using `dex-get-pools`'). This gives clear guidance on the proper workflow and distinguishes it from the execution alternative.

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