Server Quality Checklist

Tool Scores

• check_balancesB
  3.4/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 responsibility for behavioral disclosure. It states it reads balances (implying read-only), but doesn't disclose chain requirements (Base-specific), token standards supported, network behavior (RPC timeouts), or what happens with invalid addresses or non-ERC-20 token contracts. The Base chain constraint is mentioned but the behavioral implications aren't fully detailed.

  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 conveys the core purpose, chain scope, and optional token parameter concisely. It front-loads the primary function (get balances) and adds the optional token-checking behavior without redundancy. Minor room to add usage context, but the current text is tight.

  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 read-only balance-check tool with 100% schema coverage, the description is reasonably complete. It covers the main action, chain context, and token override behavior. However, with no output schema and no annotations, it could benefit from describing the return shape (e.g., a balance breakdown object) and handling of invalid tokens to be fully complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters. The description adds the detail that tokens are ERC-20 token addresses and that ETH is always included, which complements the schema. However, it doesn't explain wallet address format requirements beyond the schema's '0x...' hint, and doesn't clarify behavior when 'tokens' is omitted entirely.

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

  Purpose5/5

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

  The description uses a specific verb+resource ("Get ETH balance and ERC-20 token balances") and scopes it clearly to 'any wallet address on Base.' It distinguishes itself from siblings like check_allowance (which checks specific allowances) and get_token_info (which retrieves token metadata) by focusing on balance 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 the tool is for checking wallet balances but doesn't explicitly state when to use it over alternatives like check_allowance or resolve_address. It mentions Base chain context which helps, but there's no explicit when-not-to-use or alternative guidance. The clarity of purpose partially compensates for missing explicit usage conditions.

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

• get_gas_estimateB
  3.4/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 for behavioral disclosure. It states the output (ETH and USD-equivalent) but doesn't cover potential failure modes, whether it requires network calls, rate limits, or what happens with invalid addresses/calldata. For an estimation tool, the lack of error-behavior context is a gap.

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

  Conciseness5/5

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

  Two clean sentences, zero waste. Front-loaded with the action, then specifies inputs and output format immediately. Efficient and well-ordered.

  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?

  Adequate for a three-parameter estimate tool with full schema coverage and no output schema. However, with no annotations and no explicit return-value description beyond 'ETH and USD-equivalent,' it leaves the agent without clarity on edge cases — acceptable but not comprehensive.

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

  Parameters4/5

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

  Schema coverage is 100%, so all three parameters are documented in the schema. The description adds marginal context by noting data/value are 'optional' and frames the to as the primary input, reinforcing the schema's required flag. Schema does most of the work but description aligns well.

  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?

  Clear verb+resource (estimate gas for a transaction on Base) plus specific scope (to address, data/value). Clearly distinct from siblings like check_allowance and get_base_gas_price, though it doesn't explicitly contrast against them.

  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?

  Implied usage context — when you need an estimate before sending a transaction. No explicit when-not-to-use or alternatives named, though the distinction from get_base_gas_price (block-level price vs transaction-level estimate) is implicitly clear.

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

• get_tx_statusA
  3.5/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 what the tool returns (confirmation status, block, gas used, success/revert) which is helpful behavioral context. However, it doesn't mention timeout behavior for pending transactions or what happens with an invalid hash. The description does a reasonable job but has gaps around error handling.

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

  Conciseness5/5

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

  Two sentences, zero waste. States the purpose, the lookup key, and what's returned. Every word earns its place.

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

  Completeness3/5

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

  For a single-parameter lookup tool with no output schema, this is reasonably complete. It enumerates the returned fields (confirmation status, block, gas used, success/revert) which compensates somewhat for the missing output schema. However, it lacks details on error behaviors (invalid hash, pending tx) that would make it fully self-sufficient for an agent to invoke reliably.

  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?

  There's only one parameter (tx_hash) and schema coverage is 100%, so the schema fully documents it. The description adds the format detail '0x...' context from the schema but doesn't add much beyond clarifying it's the Base chain transaction hash. Baseline 3 is appropriate since 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 verb (Check), resource (transaction status on Base), and method (by hash). It distinguishes itself from siblings which are about addresses, gas, tokens, allowances, and balances. However, it doesn't explicitly differentiate from any sibling by name.

  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 checking transaction outcomes but doesn't explicitly say when to use it vs alternatives. It doesn't name any exclusions or alternatives, though the tool's purpose is fairly self-evident given the sibling context (others are about addresses/gas/tokens, not transaction status).

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

• resolve_addressA
  3.6/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 behavioral burden. It discloses the network (mainnet), which is useful behavioral context, and states the bidirectional capability. However, it doesn't disclose behavior for invalid inputs, reverse-lookup failures, normalization, or response format. For a read-only lookup tool, this is modest but reasonable disclosure.

  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 sentences, zero waste. Every sentence earns its place: first states the core bidirectional purpose, second states the network constraint. Very compact and front-loaded.

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

  Completeness3/5

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

  For a single-parameter, read-only lookup tool with a fully documented schema, the description is reasonably complete. It would benefit from noting the return format (resolved address vs name) and behavior for unresolvable names, but the absence of an output schema and the simplicity of the operation make the current level adequate. A bit more behavioral detail would strengthen it.

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

  Parameters3/5

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

  Schema coverage is 100%, and the single 'input' parameter is fully documented in the schema with examples. The description adds that the parameter can be either an ENS name or an address, which complements the schema. With 100% coverage, baseline 3 is appropriate since the description adds one small clarifying detail but doesn't go beyond the schema materially.

  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?

  Uses specific verb 'Resolve' with clear resources (ENS name to address, or address to ENS name). Explicitly states it uses Ethereum mainnet ENS registry, which clearly distinguishes it from sibling tools that handle tx status, gas, balances, etc. The bidirectional nature is stated upfront.

  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 (look up ENS resolution) and specifies mainnet scope, which is a meaningful constraint. However, it doesn't explicitly state when NOT to use this tool or mention alternatives. Sibling tools are functionally different enough that there's little confusion risk, but no exclusionary guidance is provided.

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

• check_allowanceA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the transparency burden. It explains the semantic meaning ('how many tokens an owner has approved a spender to use') which is genuinely informative. However, it doesn't describe return value format, whether it reverts for invalid tokens, or any edge-case behavior. With zero annotations, this is adequate but not rich.

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

  Conciseness5/5

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

  Two sentences, zero wasted words. The first sentence states the purpose, the second provides usage context. Everything earns its place with no redundancy.

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

  Completeness4/5

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

  For a simple read-only query with 3 fully-described parameters and no output schema, the description is largely sufficient. It would benefit from noting the return format (allowance value) since there's no output schema, but the purpose is clear enough that an agent could reasonably use it. The use-case guidance adds valuable context not in the schema.

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

  Parameters3/5

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

  Schema coverage is 100% — all three parameters have descriptions in the schema (token, owner, spender addresses). The description reinforces the roles ('owner has approved a spender') but doesn't add format details or validation constraints beyond the schema. Baseline 3 is appropriate since the schema already does the heavy lifting.

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

  Purpose5/5

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

  Specific verb+resource: 'Check ERC-20 token allowance' clearly states what it does. It names all three involved parties (owner, spender, token) and explains the approval concept. Distinguishes from siblings like check_balances and get_token_info by its specific purpose.

  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: 'Useful before executing swaps or transfers that require approval.' This gives a concrete scenario where the tool is relevant. While it doesn't explicitly name alternatives or state when NOT to use it, the use-case framing is strong and positions it relative to swap/transfer workflows.

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

• get_token_infoA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It correctly implies a read-only operation by stating it 'Gets' information rather than mutating state. However, it doesn't disclose potential failure modes (e.g., behavior on non-ERC-20 or invalid addresses), rate limits, or what happens with non-standard ERC-20s.

  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, tightly-written sentence that front-loads the action and resource, lists the concrete return fields, and scopes the tool to a specific network. Every word earns its place; zero wasted verbiage.

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

  Completeness4/5

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

  For a simple single-parameter metadata lookup tool with 100% schema coverage and no output schema, the description provides sufficient context—scoping to Base, enumerating return fields, and clarifying it works with any ERC-20. A brief note on network specification or error handling would push it to 5, but it's largely complete for this straightforward use case.

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

  Parameters3/5

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

  Schema coverage is 100% and there's only a single parameter (address) with a clear schema description ('Token contract address'). The description adds the context that the address must be an ERC-20 token contract on Base, but since the schema already fully documents the parameter, the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('Get') with a clear resource ('detailed ERC-20 token information on Base') and enumerates the exact fields returned (name, symbol, decimals, total supply). It unambiguously distinguishes itself from siblings like get_base_gas_price, get_tx_status, and check_allowance by focusing on 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 explicitly states it works with 'any ERC-20 token contract address,' giving clear context on when to use it. However, it doesn't explicitly state when NOT to use it or mention alternatives among siblings (e.g., for balance checks use check_balances, for allowances use check_allowance), so exclusions are implied rather than stated.

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

• get_base_gas_priceA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. The description names the data returned (gas price, priority fee, block info) and notes its purpose for transaction timing. However, it doesn't disclose whether this is a read-only network query, whether it may be slow, or whether it reflects current or cached state. For a reportedly simple network fetch, the disclosure is adequate but not rich.

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

  Conciseness5/5

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

  Two sentences, zero waste. The first sentence states what it returns; the second states when to use it. Every part earns its place.

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

  Completeness4/5

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

  For a zero-parameter, read-style network query with no output schema, the description adequately covers purpose and usage. It names the returned data categories (gas price, priority fee, block info). It doesn't describe the return format or units, but with no output schema and no annotations, this is a minor gap rather than a critical one for such a simple tool.

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

  Parameters4/5

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

  The tool has 0 parameters, so the description doesn't need to document any parameter meaning. The baseline of 4 for zero-parameter tools applies. The description appropriately focuses on what data is returned rather than parameter syntax.

  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 has a specific verb ('Get'), a specific resource ('Base chain gas price, priority fee, and block info'). It clearly distinguishes what this tool returns from sibling tools like get_gas_estimate (which likely estimates gas for a specific transaction) or get_tx_status. The resource scope is precisely defined.

  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 states 'Use to determine optimal timing for transactions,' providing a clear use case. However, it doesn't explicitly state when NOT to use this tool or name alternatives (e.g., when to prefer get_gas_estimate instead). The context is clear but lacks exclusions.

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