Server Quality Checklist

Tool Scores

• deploy-mon-contractC
  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 offers minimal behavioral insight. It mentions 'testnet' which implies non-production use, but doesn't disclose critical traits like whether deployment is irreversible, requires gas fees, has rate limits, or returns a contract address. For a deployment tool, this is a significant 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?

  The description is a single, focused sentence with zero wasted words. It's appropriately sized for a straightforward deployment tool and front-loads the essential action and target environment.

  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 contract deployment tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deployment (e.g., returns contract address, transaction hash), error conditions, or environmental constraints. Given the complexity of smart contract deployment, more context is needed.

  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 adequately. The description adds no additional parameter context beyond what's in the schema (e.g., format examples, relationship between parameters). This meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('deploy') and resource ('smart contract on Monad testnet'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'send-mon-transaction' which might also involve contract interactions, 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. It doesn't mention prerequisites (e.g., needing ABI/bytecode), compare to other deployment methods, or specify use cases like testing vs production. 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.

• get-block-by-numberC
  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 the tool retrieves a block but omits critical details such as whether it's a read-only operation (implied by 'Get'), error handling for invalid block numbers, rate limits, or authentication needs. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

  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 is front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes essential information, earning its place with zero waste.

  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 operations, no annotations, and no output schema, the description is incomplete. It lacks details on return values (e.g., block structure), error cases, network-specific behaviors, or how it fits within the sibling toolset. For a tool with such sparse structured data, more context is needed to be fully helpful.

  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 'number' parameter documented as 'The block number to retrieve'. The description adds no additional meaning beyond this, such as format details (e.g., integer vs. hex) or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.

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

  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 ('a block by number'), specifying the target network ('on Monad testnet'). It distinguishes from siblings like 'get-latest-block' by focusing on specific block numbers rather than the latest. However, it doesn't explicitly contrast with all siblings, such as 'query-mon-nft' or 'watch-contract-events', which is why it's a 4 rather than 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?

  The description provides minimal guidance, implying usage when a specific block number is known on the Monad testnet. It lacks explicit when-to-use scenarios, alternatives (e.g., using 'get-latest-block' for recent blocks), or exclusions (e.g., not for querying NFTs). No context on prerequisites or limitations is given, making it basic but not entirely absent.

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

• get-mon-balanceC
  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 states what the tool does but lacks critical behavioral details: it doesn't specify if this is a read-only operation, mention rate limits, error conditions, or what format the balance returns (e.g., in wei or MON tokens).

  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 front-loads the core purpose without unnecessary words. However, it could be slightly more structured by explicitly stating it's a read operation or including key constraints, which would enhance clarity without sacrificing brevity.

  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 low complexity (one parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but omits behavioral context (e.g., read-only nature, return format) that would help an agent use it correctly, especially with no annotations to fill gaps.

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

  Parameters3/5

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

  The schema description coverage is 100%, with the single parameter 'address' well-documented in the schema as 'Monad testnet address to check balance for'. The description adds no additional parameter semantics beyond this, so it meets the baseline for high schema coverage.

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

  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 MON balance') and resource ('for an address on Monad testnet'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-block-by-number' or 'query-mon-nft', which prevents a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid testnet address) or compare it to sibling tools like 'send-mon-transaction' for balance changes, leaving usage context unclear.

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

• query-mon-nftC
  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 the full burden of behavioral disclosure but only states the action without details on permissions, rate limits, or response format. It doesn't mention if this is a read-only operation or potential side effects, which is inadequate for a tool with no annotation support.

  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 no wasted words, clearly front-loading the core purpose. It's appropriately sized for a simple query tool, 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 no annotations and no output schema, the description is incomplete. It doesn't explain what information is returned (e.g., metadata, owner), how errors are handled, or any behavioral traits, leaving gaps for the agent to understand the tool'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?

  The schema description coverage is 100%, so the input schema already documents both parameters thoroughly. The description doesn't add any extra meaning about the parameters beyond what the schema provides, 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 ('Query') and resource ('NFT information on Monad testnet'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'get-mon-balance' or 'get-block-by-number' that also query blockchain data, which prevents a perfect score.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as needing a contract address and token ID, or comparisons to other query tools in the sibling list, leaving the agent without usage direction.

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

• send-mon-transactionC
  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 the action but lacks critical details: it doesn't specify if this requires authentication, what the transaction cost or gas implications are, whether it's irreversible, or what the expected response format is. This is a significant gap for a transaction tool.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste—it 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 complexity of a transaction tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, error handling, or return values, leaving the agent with insufficient context to use the tool safely and 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, clearly documenting both parameters ('amount' and 'to'). The description adds no additional parameter semantics beyond what the schema provides, such as format details (e.g., address format, unit for amount) or constraints. Baseline 3 is appropriate as 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 ('Send MON transaction') and specifies the target environment ('on Monad testnet'), which distinguishes it from mainnet operations. However, it doesn't differentiate from potential sibling tools like 'deploy-mon-contract' that might also involve transactions, leaving room for improvement in sibling 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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a wallet or balance), exclusions, or comparisons to sibling tools like 'deploy-mon-contract' for contract deployments or 'get-mon-balance' for checking funds first.

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

• watch-contract-eventsC
  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 the tool 'watch for' events, implying a monitoring or subscription-like behavior, but doesn't clarify if this is a one-time query, a continuous stream, or how results are returned (e.g., real-time updates, batch retrieval). It also omits details like rate limits, authentication needs, or whether it's read-only (likely, but not stated). For a tool with potential ongoing behavior, this is a significant 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?

  The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action ('Watch for smart contract events') and specifies the context ('on Monad testnet'), making it easy to parse quickly. Every part of the sentence contributes 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?

  Given the complexity of blockchain event monitoring (which often involves streaming or subscription behavior), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., event logs, real-time notifications), how to handle the watch operation (e.g., polling, WebSocket), or error conditions. For a tool with 4 parameters and potential behavioral nuances, this leaves critical gaps for an AI agent to use it 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 clear parameter definitions (e.g., 'Contract ABI', 'Contract address to watch'). The description adds no additional semantic context beyond what the schema provides, such as explaining ABI format requirements or eventName matching rules. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.

  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 ('Watch for') and resource ('smart contract events on Monad testnet'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'query-mon-nft' or 'get-block-by-number' which might also involve blockchain data retrieval, leaving room for ambiguity about when this specific event-watching capability is needed versus other querying methods.

  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 a contract ABI), exclusions (e.g., not for historical data without 'fromBlock'), or comparisons to siblings like 'query-mon-nft' for NFT-specific queries. This lack of context makes it unclear when this tool is the appropriate choice.

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

• get-latest-blockB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but provides no information about rate limits, authentication requirements, network behavior, error responses, or what 'latest' means in practical terms (e.g., is it cached, real-time, etc.). For a blockchain query tool with zero 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 a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple query tool and front-loads the essential information. Every word earns its place in this minimal description.

  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 this is a blockchain query tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the block data will be returned in, what fields to expect, or any behavioral characteristics. For a tool that presumably returns complex blockchain data, more context about the response would be helpful despite the lack of output schema.

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

  Parameters4/5

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

  The tool has zero parameters, and schema description coverage is 100%. The description appropriately doesn't discuss parameters since none exist. It could theoretically mention that no parameters are required, but this is adequately covered by the structured schema. With 0 parameters, the baseline is appropriately 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 action ('Get') and resource ('latest block on Monad testnet'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get-block-by-number', but the focus on 'latest' provides some distinction. The description is specific enough to understand what the tool does without being tautological.

  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-block-by-number'. It doesn't mention prerequisites, error conditions, or any context about when this specific tool is appropriate. The agent must infer usage from the tool name alone, which is insufficient for optimal tool selection.

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