Server Quality Checklist

Tool Scores

• get_balanceA
  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 must carry behavioral context. It discloses defaults (SUI) and the optional historical checkpoint feature, but does not explicitly state read-only behavior, permissions, or return format. For a non-mutating get operation, this is adequate but not comprehensive.

  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 two concise sentences that effectively convey purpose, default, and optional parameter. There is no redundancy or wasted wording.

  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 and all parameters are fully described in the schema. The description covers default behavior and historical queries, but it does not mention the return value or format. Given the absence of an output schema, adding return detail would improve completeness, but current coverage is solid for a straightforward balance query.

  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 descriptions cover 100% of parameters, including defaults for coin_type and at_checkpoint. The description adds no new parameter details beyond what is already in the schema; it only mentions defaults and the optional historical checkpoint, which are already documented.

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

  Purpose5/5

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

  The description clearly states the tool retrieves the balance of a specific coin type for a Sui address, with a default to SUI and optional historical checkpoint querying. This specific verb+resource combination distinguishes it from sibling tools like get_wallet_overview or list_owned_objects.

  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 querying coin balances but does not explicitly discuss when to prefer this tool over alternatives like get_wallet_overview or get_object. No exclusions or alternative recommendations are provided, so guidance is implied rather than explicit.

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

• get_defi_positionsA
  3.8/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the transparency burden. It discloses a key behavioral trait: it returns extracted position summaries (deposits, borrows, liquidity, fees) rather than raw on-chain data. However, it offers no detail on permissions, pagination, or behavior for addresses with no positions.

  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 compact at two sentences, starts with the action, and includes an enumerated list of protocols without extraneous language. Every sentence contributes useful information.

  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 description outlines the tool's scope and the nature of the returned data, which is important because no output schema is provided. It could be more explicit about return edge cases (e.g., empty positions) or network-specific behavior, but the schema's full coverage of network/address parameters helps. Overall, it is sufficient for an agent to decide when to invoke the 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 already fully documents both parameters (address and network) with descriptions, so the baseline is 3. The tool description doesn't add any additional parameter-level semantics beyond what the schema provides.

  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 identifies the tool's purpose: finding DeFi positions owned by a Sui wallet. It enumerates covered protocols (Suilend, Cetus LP, NAVI, Scallop, Bluefin, Bucket, and staked SUI), which differentiates it from sibling tools like get_balance or get_staking_summary. The verb 'Find' and resource 'DeFi positions' are specific.

  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 when a wallet's DeFi positions across specific protocols are needed, but it provides no explicit guidance on when to choose this tool over siblings such as get_wallet_overview or get_staking_summary. There are no stated exclusions or alternative tool recommendations.

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

• get_staking_summaryA
  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 burden. It discloses the return content (all StakedSui objects with pool, principal, activation epoch) and the verb 'Get' implies a read operation, but it does not explicitly state whether this is read-only, any permission requirements, or behavior when no staking exists.

  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, front-loaded, no fluff. Every word 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?

  While no output schema exists, the description summarizes the return values. For a simple two-parameter read tool, this is fairly complete, though it omits edge cases like empty staking or network behavior, but those are minor.

  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 covers both parameters with descriptions, so baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already provides.

  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 identifies the tool as retrieving staking positions for a wallet on Sui, listing specific output details (StakedSui objects, pool, principal, activation epoch). This distinguishes it from siblings like get_defi_positions or get_wallet_overview.

  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 when staking information is needed, but it does not explicitly state when to prefer this over alternatives such as get_defi_positions or get_wallet_overview, nor does it mention exclusions or prerequisites.

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

• resolve_nameA
  3.8/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 does not mention error handling, not-found behavior, network requirements beyond the schema, or any side effects. The read-only nature is implied but not explicitly stated, and there is no information about response format.

  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 front-loads the purpose and includes only the essential usage constraint. No wasted words.

  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?

  Given the tool's simplicity, the description covers the core purpose, the bidirectional resolution, and the input constraint. However, without an output schema or annotations, it could benefit from additional details about return values (though these are implied) and edge cases. Still, it is sufficiently complete for a straightforward lookup 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?

  Schema coverage is 100%, so the baseline is 3. The description adds meaningful constraint that at least one of 'name' or 'address' must be provided, which is not enforced in the schema, and clarifies the 'address' parameter is for reverse-lookup. This goes beyond the schema descriptions.

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

  Purpose5/5

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

  The description clearly states the tool resolves SuiNS names to addresses and performs reverse lookups, using a specific verb ('resolve') and resource (SuiNS name/address). It distinguishes itself from sibling tools like identify_address by focusing on SuiNS domain resolution.

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

  Usage Guidelines3/5

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

  The description implies usage context (when you need to resolve a SuiNS name or reverse-lookup an address) and states the constraint that at least one of 'name' or 'address' must be provided. However, it does not explicitly mention alternatives or when not to use this tool compared to siblings like identify_address.

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

• analyze_tokenA
  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 full burden. It discloses the returned data categories and input flexibility (coin type or symbol), but does not explicitly state that the call is read-only, nor does it mention rate limits, permissions, or error behavior. The 'get' and 'analysis' wording implies a safe read, but it is not explicit.

  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 plus an example, front-loaded with the recommendation and specific output list. Every sentence provides useful information 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?

  Given no output schema, the description compensates by listing exactly what is returned (metadata, price, change, supply, holders) and the accepted input formats. It does not explain error handling or network-specific behavior, but those are partially covered in the schema, so the description is sufficiently complete for an analysis 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?

  Schema description coverage is 100%, and the description's note about accepting coin type or symbol essentially restates the query parameter's own description. The description adds no extra semantics beyond what the schema already provides; hence, the baseline 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 explicitly states 'Get a comprehensive analysis of a Sui token' and enumerates specific data points (metadata, current price, 24h change, total supply, top 5 holders), clearly distinguishing it from price-only tools like get_token_prices or balance tools.

  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?

  Opens with '(Recommended for token research)' signaling the intended use case, and the description implies a comprehensive analysis without naming alternatives. However, it does not explicitly compare with sibling tools such as get_token_prices or identify_address, so it lacks explicit when-not instructions.

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

• find_poolsA
  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 full transparency burden. It reveals that the tool searches across specific DEXs and returns a pool_id, but does not disclose result format, potential empty results, sorting, or pagination behavior. This is adequate for a simple read-only search but lacks depth.

  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?

  Three concise sentences: the first states purpose, the second explains search scope, the third points to a follow-up. No filler or redundancy; purpose is front-loaded.

  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 search tool with no output schema, the description covers the primary use case, the exact protocols searched, and a clear next step. It mentions pool_id as a return field, but does not describe the full result structure or edge case behavior. Still, it is sufficient for an agent to invoke correctly.

  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 covers 100% of parameters with descriptions for token_a, token_b, network, and protocol. The tool description only mentions 'token pair' and 'tokens', which adds no meaning beyond the schema. The baseline of 3 applies because the schema carries the semantic load.

  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 opens with 'Find DeFi liquidity pools by token pair' — a specific verb and resource that clearly states the tool's function. It also names three protocols (Cetus, DeepBook, Turbos) it searches, which differentiates it from adjacent tools like get_defi_positions.

  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 usage context: use when you have a token pair and need to find matching liquidity pools. It explicitly recommends get_pool_stats for subsequent detail, giving a follow-up path. However, it does not contrast with siblings or state when not to use this tool.

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

• get_chain_infoA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosing behavior. It lists the returned fields, which gives insight into output, and implies a read-only operation. However, it does not explicitly state side effects, error behavior, or default network selection, leaving some gaps for a complete transparency profile.

  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 two sentences long, front-loaded with the core purpose, and every word adds value. It avoids repetition and clearly introduces the optional parameter in the second sentence.

  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?

  Given the tool's simplicity, no annotations, and fully described schema, the description covers the essential behavior. It names all returned fields and explains the epoch option. The lack of an output schema is partially compensated by the field list, though a more explicit response structure could improve 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?

  The schema already fully describes both parameters with high coverage (100%). The description's mention of 'optionally pass an epoch number' reinforces but does not add new semantic detail beyond the schema. The network parameter's detailed description is already in the schema, so the description adds no extra value here.

  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 'Get current Sui network info' and enumerates specific fields (chain ID, epoch, checkpoint height, timestamp, reference gas price), making the tool's function unambiguous. It is distinct from sibling tools like get_object or get_transaction, which target other data types.

  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 a clear use case: retrieving current network info, and also explains the optional epoch parameter for querying specific epochs. While it does not explicitly name alternatives or exclusion criteria, the context is sufficient given that no sibling tool offers this functionality.

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

• get_objectA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and does well by listing the returned fields (type, owner, version, content JSON, digest) and the automatic extraction of NFT display metadata. It could be more thorough about error handling, but it clearly conveys the operational 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 only two sentences, starts with the main action, and has no filler or redundant content. It is concise and well-structured.

  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 get tool, the description adequately explains the output and special NFT handling. The parameter schema is comprehensive, and no output schema exists. It lacks sibling comparison guidance, but that is covered under usage guidelines. Overall, it is complete enough for correct invocation.

  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 already contains full descriptions for all three parameters (object_id, network, version), so the description adds no additional parameter detail. Per the rubric, a baseline of 3 is appropriate given 100% 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 'Get a Sui object by its ID', which specifies the exact action and target. It distinguishes itself from sibling tools like list_owned_objects and get_transaction by focusing on retrieving a single object by ID.

  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 usage is implied: use this when you have a specific object ID to fetch. However, it does not explicitly state when to prefer this over alternatives like list_owned_objects, nor does it mention any exclusions or complementary tools.

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

• get_token_pricesA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full behavioral disclosure burden. It reveals that current prices use Aftermath with Pyth as fallback, and historical prices rely on the Pyth oracle at the given time, which provides meaningful insight into data source reliability. However, it does not mention failure modes (e.g., what happens if a price is unavailable) or rate limits.

  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, using three short sentences to convey the primary purpose, data source behavior, and input format. Every sentence adds value with no fluff, and the most important information (what it does) is front-loaded.

  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 read-only price query tool with no output schema, the description covers the core functionality, historical vs. current behavior, data sources, and required input format. It lacks explicit return structure (e.g., mapping from coin type to price) but the simplicity of the tool makes this acceptable. The network parameter is not mentioned in the description, though it is thoroughly documented 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?

  All parameters are fully described in the schema (100% coverage), so the description adds only redundant reinforcement (e.g., 'Accepts full coin type strings'). It does not provide new semantic meaning beyond the schema, such as return format or unit details, so 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.

  Purpose5/5

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

  The description clearly states the tool gets USD prices for Sui tokens, with a specific distinction between current and historical prices via the `at` parameter. It also specifies the data sources (Aftermath, Pyth) and input format, making it distinct from sibling tools like get_balance or analyze_token.

  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 explains when to use current vs. historical modes (when `at` is set) but does not explicitly compare against alternative sibling tools like analyze_token. It provides context on data source fallback but lacks explicit 'use this when' or 'instead of' guidance.

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

• get_transaction_historyA
  4/5.0
  Behavior3/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. It adds valuable context by describing the output as 'decoded' and 'human-readable,' implying a read-only, user-friendly feed. But it does not mention any potential limitations, rate limits, or error behavior, leaving some transparency 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 three sentences, each serving a clear purpose: stating recommendation, defining functionality with concrete examples, and providing usage guidance. There is no redundancy or unnecessary detail.

  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?

  Given the full schema coverage for parameters and a clear, detailed description of purpose and output, the description is nearly complete. It could mention pagination or network behaviors explicitly, but those are already covered by the schema, so it does not need to.

  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%, meaning all parameters are already documented in the input schema. The description adds no additional parameter-specific guidance beyond what the schema provides, so the baseline score 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 clearly states the tool's function: to get decoded transaction history for a Sui wallet, with specific output details like protocol names and token flow. It also distinguishes itself from the sibling query_transactions by explicitly recommending it for exploring wallet activity.

  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?

  Provides explicit usage context with 'Recommended for wallet activity' and directly names an alternative: 'Prefer this over query_transactions when exploring what a wallet has been doing.' However, it lacks a clear 'when not to use' statement, so it doesn't fully cover both sides.

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

• get_wallet_overviewA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the scope of the return data (balances, SuiNS, staking, NFTs, transactions) and the include_prices option for USD values. However, it omits potential caveats such as pagination, performance limits, or network-specific behavior, which leaves some gaps for a comprehensive aggregate 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 two sentences long, with the first sentence front-loading the tool's purpose and contents, and the second giving a concise parameter tip. Every word earns its place, and there is no filler or repetition.

  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?

  Although there is no output schema, the description sufficiently enumerates the major return categories (token balances, SuiNS name, staked SUI count, kiosk/NFT count, recent transactions) and explains the optional price inclusion. It also provides a clear usage context relative to sibling tools. It does not detail the exact result structure, but for a high-level overview tool this is acceptable and the sibling tools can provide more depth.

  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 already covers all parameters with detailed descriptions (100% coverage), so the baseline is 3. The description adds marginal value by highlighting include_prices as the way to get USD values and portfolio value, but this largely mirrors what the schema already explains. No additional syntax or format details are provided beyond 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 begins with a clear verb ('Get') and resource ('comprehensive overview of a Sui wallet'), and explicitly enumerates the included data (token balances, SuiNS name, staked SUI count, kiosk/NFT count, recent transactions). It also positions itself as the recommended first tool, which distinguishes it from sibling tools like get_balance or list_nfts.

  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 explicit usage guidance: 'Recommended first tool for wallets' and 'Start here before drilling into specific tools.' It clearly indicates when to use this tool as an entry point and implies that more specific tools should be used afterward. It does not name specific alternative tools, but the directive is clear and actionable.

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

• list_owned_objectsA
  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. It discloses key behavioral traits such as 'raw' (no kiosk resolution, no display metadata) and pagination support. However, it does not explain the return format or any potential limitations, leaving some ambiguity for a tool that lists raw objects.

  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, front-loaded sentences. The first sentence states the core function; the second gives alternative guidance. No filler or 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?

  The tool has no output schema, so return values are not documented. While the description clearly covers primary purpose and when to use alternatives, it leaves the exact structure of a 'raw object' response unspecified. Given the schema covers all parameters and the alternatives are well-stated, the description is mostly complete but not fully.

  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 all 5 parameters. The description merely mentions 'optional type filter and pagination', adding no new meaning beyond what the schema already provides.

  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?

  States clearly it lists raw Sui objects owned by an address, with optional type filter and pagination. It distinguishes itself from sibling tools by explicitly contrasting with list_nfts and get_wallet_overview.

  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?

  Provides explicit when-to-use guidance by directing NFT queries to list_nfts and wallet summaries to get_wallet_overview. This clearly maps scenarios to the right tool.

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

• get_transactionA
  4.3/5.0
  Behavior4/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 the return payload (sender, status, gas, events, balance changes, protocol-aware decoded actions), which is valuable behavioral context. The verb 'Get' implies a read-only operation, though it does not explicitly state absence of side effects or failure modes. Overall, it adds meaningful behavioral detail.

  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 two sentences long, front-loads the primary purpose, and wastes no words. It efficiently conveys the action, target, and examples of returned data ('swap on Cetus', 'deposit on Suilend'). Every sentence earns its place.

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

  Completeness5/5

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

  Given the tool's simplicity, the 100% schema coverage, and the fact that the description lists the return fields, the description is fully complete for an agent to select and invoke the tool. No output schema exists, but the description covers what would otherwise be returned. The only minor omission is explicit error behavior, but that is not critical for this kind of read operation.

  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%: both 'digest' and 'network' are fully described in the input schema, including details about defaulting and per-call behavior. The tool description adds no parameter-specific information beyond what the schema already provides, so the baseline score 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 states a specific verb and resource: 'Get a Sui transaction by its digest.' This clearly distinguishes it from sibling tools like 'query_transactions' (which searches/filters) and 'get_transaction_history' (which likely lists transactions for a wallet). It also enumerates the key returned data, making the tool's scope unambiguous.

  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: use this when you have a transaction digest and need full transaction details. It does not explicitly name alternative tools or state when not to use it, but the singular 'by its digest' implies a targeted lookup rather than a list query. This is clear context without explicit exclusions.

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

• identify_addressA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states that the tool returns a type classification plus contextual summaries with specific examples (balance + SuiNS for wallets, module list for packages, stake info for validators). This conveys the operational behavior and output richness without needing to describe side effects (as it is a read-only identification).

  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 two sentences. The first sentence states the core purpose and classification types; the second sentence describes the output and provides usage guidance. Every sentence earns its place, and the key information is front-loaded.

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

  Completeness5/5

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

  Given the tool's simplicity (2 params, no output schema, no annotations), the description covers the essential function, the nature of the return value, and when to use it relative to other tools. It is complete enough for an agent to select and invoke it correctly.

  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 baseline is 3. The description adds general context about what the return will be but does not add parameter-level detail beyond the schema. The schema already clearly describes 'address' and 'network', so the description is not required to compensate.

  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 ('Identify') and resource ('Sui address'), and clearly enumerates the classification categories (wallet, package, validator, object). This distinguishes it from sibling tools that query specific types (e.g., get_object, get_balance).

  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 recommends it as the 'Recommended first step' and says 'Use this before deciding which other tools to call,' giving clear when-to-use context. It does not explicitly name alternatives or state when not to use it, but the positioning is sufficient for a helper/classifier tool.

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

• list_nft_collectionsA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full transparency burden. It discloses key behaviors: it walks multiple sources ('kiosks plus direct-owned objects'), deduplicates, and returns a 'lightweight summary' with counts. It also mentions 'Backed by GraphQL' as an implementation detail. This adds meaningful context beyond the tool name and schema.

  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 two sentences, front-loaded with the primary purpose in the first sentence and behavioral details in the second. Every sentence adds value without redundancy or unnecessary elaboration.

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

  Completeness5/5

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

  The description is complete for a read-only summary tool. It explains what the tool does, how it operates (walking kiosks and direct-owned objects), what the output contains (deduplicated collection types with counts), and is backed by GraphQL. Given the simple two-parameter schema and absence of an output schema, the description sufficiently covers the tool's behavior and expected result.

  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 100% coverage for both parameters (address and network). The description does not add additional parameter-specific meaning beyond what the schema already states. Per the baseline rule for high schema coverage, this is a 3.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Get a lightweight summary of NFT collections owned by a wallet.' It specifies the resource and action, and further clarifies scope by mentioning 'Walks all kiosks plus direct-owned objects and returns deduplicated collection types with counts,' distinguishing it from siblings like list_nfts and list_owned_objects.

  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 implies a clear use case: obtaining a high-level NFT overview. It provides context by explaining it traverses kiosks and direct-owned objects and returns deduplicated collection types, which helps differentiate it from more detailed tools. However, it does not explicitly name alternatives or state when not to use this tool.

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

• enable_toolsA
  4.6/5.0
  Behavior4/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 session scoping ('for this session'), that newly enabled tools are callable immediately, and explains the default tool surface. It does not address idempotency or error behavior, but the disclosed context is valuable.

  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 long but well-organized with clearly labeled profiles and tool lists. The tool lists are necessary for choosing the right profile and each section earns its place. It is front-loaded with the key instruction.

  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 relatively simple tool with one parameter and no output schema, the description is complete: it explains purpose, profiles, and when to use. It could mention the return value or confirmation behavior, but it is not critical given the tool's simplicity.

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

  Parameters5/5

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

  The schema only provides the parameter description 'Profile to enable, or all.' The description enriches this significantly by explaining each profile and listing its constituent tools, making the parameter meaning far clearer than schema alone.

  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 states a clear verb+resource: 'Turn on additional Sui tool profiles for this session.' It clearly distinguishes itself from sibling tools (which are actual data lookup tools) by explaining that this is a meta-tool for enabling more tools.

  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?

  Explicit when-to-use guidance: 'Call this FIRST whenever the capability you need is not in your current tool list — the tool probably exists and is simply disabled.' It also advises against reimplementation and details what each profile contains, guiding profile selection.

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

• query_transactionsA
  4.7/5.0
  Behavior5/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 reveals the Sui GraphQL limitation (only one of affected_address, affected_object, or function may be used), explains the PTB attribution pitfall, and describes how include_functions mitigates it. This is high-value behavioral context beyond the schema.

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

  Conciseness4/5

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

  The description is long but structured into a purpose/guidance section and a warning paragraph. Each sentence earns its place, though the attribution warning is dense. It is appropriately detailed for a complex tool with 10 parameters but not perfectly concise.

  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 10-parameter tool with no output schema and no annotations, the description covers the most important contextual concerns: filter exclusivity, PTB attribution, and alternative tools. It stops short of describing the return shape or pagination behavior, but the raw transaction intent is clear enough for an agent to invoke it correctly.

  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 the baseline is 3, but the description enhances the meaning of tricky parameters: it explains why function filtering is dangerous for attribution and when to use include_functions. However, most parameter details are left to the schema, so the gain is modest but non-trivial.

  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 opens with 'Query raw Sui transactions with specific filters' and enumerates the filter types (sender, affected address/object, function, checkpoint range), making the tool's scope immediately clear. It also distinguishes itself from the sibling tool get_transaction_history by labeling itself 'raw' and explicitly directing human-readable queries to that sibling.

  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 gives explicit when-to-use guidance: 'For human-readable wallet activity, prefer get_transaction_history instead' and warns against using the function filter for per-protocol volume metrics, suggesting query_events as the alternative. It also states the mutual-exclusivity constraint among three filters, which is a crucial usage rule.

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

• list_nftsA
  4.9/5.0
  Behavior5/5

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

  No annotations exist, so the description carries full responsibility. It discloses pagination behavior ('pass cursor... next_cursor omitted when wallet is fully enumerated'), GraphQL page-boundary overshoot, and response contents (display metadata + raw Move structs). This is exceptionally transparent for a list 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?

  Every sentence earns its place: scope, response contents, backend rationale, pagination mechanics, and alternative. No filler or redundancy; front-loaded with the core purpose.

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

  Completeness5/5

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

  With no annotations or output schema, the description fully covers what the tool does, when to use it, how pagination works, and which sibling covers a different need. It leaves no ambiguity for correct invocation.

  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 covers all 4 params with descriptions (100% coverage), so baseline is 3. Description adds meaning to limit and cursor by explaining the overshoot rationale and the next_cursor omission behavior, which goes beyond schema text. Incremental context justifies a 4.

  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 opens with 'List NFTs owned by a wallet, including kiosk-stored NFTs' — a specific verb, resource, and scope. It also explicitly says '(Recommended for NFTs)' which differentiates it from sibling tools like list_owned_objects and list_nft_collections.

  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?

  Provides an explicit alternative: 'Use list_nft_collections for a cheaper count-only summary.' Also explains the GraphQL backend benefit ('no fullnode rate-limit risk') which clarifies when this tool is preferable to fullnode-backed alternatives.

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