Server Quality Checklist

Tool Scores

• check_api_statusC
  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 must carry the full burden of behavioral disclosure. It only states 'check' implying a read-only operation, but does not describe what the response contains, whether authentication is needed, or any side effects. This is a significant gap for a tool that checks API key status.

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

  Conciseness4/5

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

  The description is concise, front-loaded with the verb, and free of fluff. It is a single sentence that is appropriately sized for a simple status-check tool. However, it lacks structure (no sections) and could have used the space to add a bit more useful detail without becoming verbose.

  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 has no output schema, the description should at least hint at what the return value looks like or what 'configuration' refers to. It also fails to mention usage context or limitations. For a simple tool, it is minimally adequate but leaves clear gaps about expected output and behavior.

  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% for the single optional parameter (include_limits), so the schema already explains the parameter's meaning and default. The tool description adds no additional context, but since the schema carries the weight, a baseline score of 3 is appropriate.

  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 uses a specific verb ('Check') and identifies the resource ('API key status and configuration'), which clearly distinguishes it from sibling tools like get_network_status or get_account_balance. However, 'configuration' is somewhat vague and could be more explicit about what aspects of the API key are checked.

  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 does not mention scenarios, prerequisites, or explicitly exclude other tools. The context signals suggest a set of related tools, but no comparative usage information is given.

  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.9/5.0
  Behavior2/5

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

  With no annotations available, the description carries the full burden of behavioral disclosure. It only states 'Get information about a specific block' without detailing read-only nature, error handling, or output structure.

  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 front-loaded sentence with no unnecessary words. It precisely communicates the core action in minimal space.

  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?

  The description is too sparse for a tool with no output schema and no annotations. It doesn't explain what 'information' is returned, pagination, or error scenarios, making it incomplete for practical 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 provides full descriptions for both blockId and network, covering 100% of parameters. The description adds no additional parameter semantics beyond what the schema already offers.

  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 uses the specific verb 'Get' with the resource 'information about a specific block', clearly distinguishing it from sibling tools like get_transaction_info and get_network_status. However, 'information' is vague and doesn't specify what block data is included.

  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 simply states what it does without mentioning any prerequisites, exclusions, or related tools.

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

• get_network_statusC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It only states the action and resource, but does not disclose what 'blockchain information' includes, how network affects output, or any side effects. It is safe to assume read-only, but no explicit detail is given.

  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?

  One concise sentence front-loads the purpose. No wordiness, though it could be more informative without losing conciseness.

  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?

  The tool has no output schema, so the description should explain what return information is provided. It only says 'blockchain information', which is vague. Also, the potential confusion with check_api_status is not resolved. Despite simplicity, it's incomplete for practical use.

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

  Parameters3/5

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

  Schema description coverage is 100% with a clear description 'Network to query' and enum values. The description adds no extra meaning beyond the schema, so baseline 3 applies.

  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 a 'Get' action on 'network status and blockchain information', which is specific and distinct from siblings like check_api_status. However, it does not explicitly differentiate from similar tools.

  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 on when to use this tool vs alternatives like check_api_status, or any context such as network availability or when blockchain information is needed. No exclusion criteria or alternative mentions.

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

• search_transactionsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It only states the action without disclosing side effects, return format, pagination, or rate limits. Since it is a search, it is implicitly read-only, but there is no explicit statement about behavior beyond the literal action.

  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 concise sentence with no wasted words. It effectively front-loads the purpose, though it could have added brief context (e.g., return format) without sacrificing conciseness.

  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 simple search tool with full schema coverage, the description provides the minimum viable information. However, it doesn't mention what the response looks like, and with no output schema or annotations, it leaves some ambiguity about the results. It is adequate but not 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 all three parameters (address, limit, network). The description adds no extra meaning beyond the schema, which meets the baseline of 3.

  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 with a specific verb ('Search') and resource ('transactions'), and the key parameter ('by address'). It is distinct from siblings like 'get_transaction_info' which implies a single transaction lookup, though it doesn't explicitly differentiate from them.

  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?

  There is no guidance on when to use this tool versus alternatives such as 'get_transaction_info' or 'get_account_balance'. The description implies it is for searching by address, but does not state when not to use it or provide context for choosing among siblings.

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

• get_transaction_infoB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry all behavioral transparency. It only says 'Get information' without disclosing return format, error handling, network behavior, or read-only guarantees. For a potentially complex transaction lookup, this is insufficient.

  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, seven words, front-loaded with the operation. Every word is necessary with no redundancy.

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

  Completeness3/5

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

  The tool is simple with two parameters and no output schema, but the description doesn't explain what transaction information is returned, network defaults, or behavior when the transaction is not found. This is adequate but leaves gaps for an agent without further 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 coverage is 100%, with txId and network both documented in the schema. The description adds no additional parameter semantics, so baseline 3 applies.

  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 uses a clear verb-resource structure ('Get information about a transaction by ID') and specifies the lookup key. It distinguishes from sibling tools like search_transactions and get_block_info by focusing on a single transaction ID, though it doesn't detail what 'information' includes.

  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 used when a transaction ID is known, but doesn't explicitly state when to prefer it over search_transactions or other lookup tools. No alternatives or exclusions are mentioned.

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

• generate_accountB
  3.4/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 responsibility for behavioral disclosure. It says 'Generate' and mentions outputs but does not indicate side effects (e.g., whether the account is persisted, security handling of the private key, or whether it contacts the network). For a key-generation tool, this missing context could lead an agent to misuse it.

  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, focused sentence that states the action and essential output details. It contains no filler or redundant information, making it highly efficient.

  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?

  There is no output schema, so the description should explain return values. 'Basic info' is vague and does not clarify the exact structure (e.g., address, mnemonic, key format). It also does not state whether generation is random, deterministic, or has preconditions, leaving significant gaps for a generation tool.

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

  Parameters3/5

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

  The input schema fully describes the only parameter 'network' with an enum and description. The tool description does not mention this parameter or add extra meaning, but since schema description coverage is 100%, a 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 'Generate' with a clear resource 'Stacks account' and specifies the output includes 'private key and basic info'. This distinguishes it from the sibling tools, which are all read/query operations (get_account_balance, get_transaction_info, etc.).

  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?

  Usage is implied: the tool is for creating a new Stacks account. However, the description does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisites. The contrast with read-only siblings is visible in the sibling list, but not in the description itself.

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

• get_account_balanceA
  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 must carry the full burden of behavioral disclosure. It only says 'Get,' which implies a read-only operation, but it doesn't explicitly confirm safety, mention any side effects, network behavior, or error conditions. For a getter this is a minimal but acceptable disclosure, yet it lacks the context expected without annotations.

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

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the action and resource. There is no fluff or redundant information, making it easy to parse quickly.

  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?

  The tool is simple with only two parameters and no output schema. The description provides a high-level summary of the return content ('balance and account information'), which is sufficient for basic usage. However, it could be more explicit about what 'account information' includes, such as nonce or token balances, given the output schema is absent.

  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% for both parameters (address and network), so the schema already fully documents their meaning and defaults. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 applies.

  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 function: 'Get STX balance and account information for a Stacks address.' It uses a specific verb ('Get') and identifies a distinct resource (STX balance/account) that differentiates it from siblings like get_transaction_info or get_block_info.

  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?

  Usage context is implied by the purpose: use this when you need a Stacks address's balance or account details. However, there is no explicit guidance about when NOT to use it, no mention of alternatives, and no prerequisites or network selection advice beyond the schema.

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

• call_read_only_functionA
  3.7/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 burden of disclosure. It does state that the call is 'read-only' and 'without creating a transaction', which is a key behavioral trait. However, it does not disclose other aspects like error behavior, network requirements, or response format, leaving some 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, front-loaded sentence that directly communicates the tool's purpose without any filler. Every word contributes meaning, and it includes the important distinction 'without creating a transaction'.

  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 and the absence of an output schema, the description provides the essential purpose but does not mention what the return value represents (the Clarity function result) or any caveats about read-only function behavior. The schema covers parameters, but the overall context is not 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?

  The input schema has 100% parameter description coverage, including examples for functionArgs and default values for sender and network. The description adds no extra parameter information, so it does not exceed the baseline set by the 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 action ('Call a read-only function') and the resource ('on a Stacks smart contract'), and adds the key qualifier 'without creating a transaction' which distinguishes it from any transaction-based tool. It is specific and differentiates from sibling tools focused on accounts, transactions, and blocks.

  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 calls that don't require a transaction, but it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. No alternative tools are mentioned, so the guidance is only implicit.

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