Server Quality Checklist

Tool Scores

• iota_wallet_approveC
  2.7/5.0
  Behavior1/5

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

  No annotations are available, so the description carries the full burden of disclosing behavioral traits. It only says 'Approve a pending transaction' without explaining side effects (e.g., whether approval triggers submission, is irreversible, or requires additional confirmation). This is a mutating wallet operation with zero additional context, which is severely insufficient.

  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 sentence with no filler and front-loads the purpose. It is appropriately terse for a simple tool, though it sacrifices behavioral clarity. It earns its place as a concise statement of intent.

  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 is a mutating wallet operation with no annotations, no output schema, and a single parameter. The description fails to explain what happens after approval, any preconditions, or the result of the operation. This incomplete context leaves an AI agent uncertain about the tool's full impact.

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

  Parameters3/5

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

  The schema covers 100% of the parameters, with 'requestId' described as 'Request ID to approve'. The description adds nothing beyond the schema, so the baseline score of 3 applies given the 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 (approve) and the object (a pending transaction). It distinguishes from siblings like iota_wallet_reject, though it does not explicitly name alternatives. The verb+resource structure is specific enough for basic understanding.

  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. There is no mention of prerequisites, such as first listing pending transactions with iota_wallet_pending, or contrasting with iota_wallet_reject. The context for when approval is appropriate is absent.

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

• move_testC
  2.7/5.0
  Behavior1/5

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

  With no annotations available, the description must fully disclose behavioral traits. It fails to mention potential side effects like compilation, output format, or exit code behavior, leaving the agent without critical execution context.

  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, tightly-worded sentence with no superfluous content. It is front-loaded but may be too sparse to convey essential operational details.

  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 two parameters and no output schema, so the description should explain result formats or success/failure behavior. It only states the basic action, leaving significant gaps for an agent attempting 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?

  Both parameters have full schema descriptions ('Path to the Move package' and 'Test filter pattern'), so the schema covers semantics entirely. The description adds no parameter-specific insights, but the baseline of 3 applies due to high schema coverage.

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

  Purpose4/5

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

  The description clearly states the tool's function with a specific verb ('Run') and resource ('Move unit tests'). However, it does not differentiate from sibling tools like move_test_coverage, which could also be used for test execution.

  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 such as move_test_coverage or move_build. The description offers no exclusions or context for selecting it.

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

• iota_wallet_sign_executeC
  2.8/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full burden of behavioral disclosure. It states 'Sign and execute' but fails to disclose the irreversible nature of executing a transaction, whether it waits for confirmation, what happens on failure, or any side effects. This is a mutation tool, and the description offers no safety or outcome details.

  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 short sentence that is front-loaded and contains no filler. It is concise, though somewhat under-specified for a transaction-signing tool; however, that lack of detail is a completeness issue rather than a conciseness issue.

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

  Completeness1/5

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

  For a tool that signs and executes a transaction (a potentially irreversible action), the description is extremely inadequate. There is no output schema, no annotations, and no mention of success/failure behavior, confirmation, return values, or prerequisites. The description does not enable an agent to understand the tool's full behavior or consequences.

  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 provides 100% coverage of the single parameter txBytes with a clear description ('Base64-encoded unsigned transaction bytes'). The description's parenthetical 'base64 tx bytes' adds no meaning beyond the schema, 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.

  Purpose4/5

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

  The description clearly states the action ('Sign and execute') and the resource ('a transaction'), which is specific and unambiguous. However, it does not explicitly distinguish itself from sibling tools like iota_wallet_approve/reject or iota_transaction, though the verb makes the purpose understandable.

  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 such as iota_wallet_approve, iota_wallet_reject, or iota_cli. There is no mention of prerequisites, workflows, or conditions that indicate this is the appropriate tool.

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

• iota_wallet_switch_networkB
  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 responsibility for behavioral disclosure, but it only states the action without detailing side effects, reversibility, or impact on wallet operations. It does not describe whether switching persists, affects pending transactions, or requires confirmation.

  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, compact sentence with no unnecessary words. It is appropriately sized for a simple operation, every word contributes to the meaning, and it is front-loaded with the core concept.

  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 absence of annotations, output schema, and any parameter descriptions, the tool description is too minimal to be contextually complete. It does not explain the operation's effects, dependencies, or edge cases, leaving the agent to infer critical details about the network switch.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate, but it does not mention the 'network' parameter at all. While the parameter name and enum values are self-explanatory, the description adds no value beyond what the schema already provides, failing to explain the implications of choosing each network.

  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 'Switch wallet network' uses a specific verb ('Switch') and resource ('wallet network'), making the tool's purpose immediately clear. It also distinguishes itself from sibling tools, as no other tool in the list performs network switching.

  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, nor does it mention any prerequisites, exclusions, or context. There is no mention of other tools or when this operation would be appropriate, leaving the agent without usage context.

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

• iota_decompileB
  3.2/5.0
  Behavior2/5

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

  There are no annotations, so the description must disclose behavioral traits. It only states the function without mentioning whether the operation is read-only, what output to expect, or any side effects. This leaves significant gaps in understanding what the tool does beyond its basic action.

  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 is front-loaded with the action verb. It avoids unnecessary detail and is 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?

  Given there is no output schema, the description should explain return values or expected behavior. It only says "decompile" without clarifying what the output looks like or any caveats. Combined with missing annotations, the description is incomplete for a tool that interacts with on-chain data.

  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 both parameters with descriptions (Package ID, Module name), and the description adds no additional parameter-specific semantics. Since schema coverage is 100%, the baseline score of 3 is appropriate; the description doesn't elevate it.

  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 the specific verb "Decompile" and identifies the resource as "Move bytecode from a published package module", clearly distinguishing it from sibling tools like iota_package_info or move_build. No ambiguity.

  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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites or context such as needing a published package ID, nor does it specify scenarios where decompilation is appropriate. The usage is only implied by the tool's purpose.

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

• iota_transactionB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of disclosing behavior. It states 'Fetch' (implying read-only), but does not mention what is returned, any limitations, or potential errors. The description is too thin to provide adequate transparency for an agent.

  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, clear sentence with no unnecessary words. It is appropriately concise for a simple one-parameter tool.

  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 what the agent can expect as a return value or outcome, but it does not. It also does not mention error conditions or any special behavior, making it incomplete for an agent to fully understand the tool's 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 parameter 'digest', which is described as 'Transaction digest'. The description adds no extra meaning beyond the schema, so the baseline 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 clearly states the action ('Fetch') and the resource ('a transaction'), and identifies the key parameter ('by digest'). However, it does not explicitly differentiate itself from sibling tools like iota_object, which may also be fetchable by digest, so it lacks explicit sibling differentiation.

  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 you have a transaction digest, but it does not provide explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It is concise but lacks explicit context.

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

• move_test_coverageB
  3.2/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. It mentions generating a coverage report, implying a side effect, but it does not disclose whether files are created, whether compilation is required, or what the output format is. Limited behavioral insight beyond the core action.

  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 one concise sentence, front-loaded with the action and outcome. No wasted words, perfectly sized for the tool's simplicity.

  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 simple tool with one parameter and no output schema, the description is minimal. It lacks important context such as what a 'coverage report' entails, whether the operation is read-only, and what side effects it may have. The agent would need to infer too much.

  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 single parameter 'path' is described in the schema as 'Path to the Move package', providing full coverage (100%). The tool description adds no extra meaning beyond the schema, but since the schema is adequate, 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 'Run Move tests and generate coverage report' clearly states the tool's action (run tests) and its distinguishing outcome (generate coverage report). This differentiates it from sibling tools like move_test, which presumably runs tests without coverage.

  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 such as move_test. The description states what it does but does not explain when coverage is needed or why one would choose this over the plain test tool.

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

• iota_graphql_queryB
  3.3/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden. It does not disclose whether the query can mutate data, if there are rate limits, or how errors are handled. The description only states what the tool does, not behavioral characteristics such as safety or side effects.

  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?

  A single, concise sentence that is front-loaded with the action and resource. Every word earns its place, with no filler or 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?

  Given the tool's simplicity—one parameter, no output schema—the description is minimally viable. However, it lacks guidance on response format, mutation risk, or when to use this over dedicated tools, which would enhance completeness for an agent deciding between alternatives.

  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 'query' parameter, which is already documented as 'GraphQL query string'. The description adds little beyond this, only the context that it is a raw query against the IOTA endpoint. Baseline 3 is appropriate with full 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 uses a specific verb ('Run') and resource ('raw GraphQL query against the IOTA GraphQL endpoint'), clearly distinguishing it from the operation-specific sibling tools like iota_get_price or iota_epoch_info. It immediately signals a generic, flexible query tool.

  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 raw query tool versus the dedicated sibling tools. The word 'raw' implies it's for custom queries not covered elsewhere, but this is not explicitly stated, and there are no exclusions or alternative recommendations.

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

• iota_objectB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states 'Fetch details,' which implies a read operation, but does not disclose potential errors (e.g., object not found), return format, or any side effects. The description adds no additional context about the tool's behavior beyond what the name already suggests.

  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, clear sentence that states the tool's purpose without any redundant words. It is appropriately brief for a simple fetch tool, and the key information is front-loaded. Every word earns its place, making it highly concise and well-structured.

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

  Completeness3/5

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

  Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate. However, it does not explain what 'details' includes or what the caller should expect in the response. The lack of an output schema means the description should provide more context on return values, but it remains incomplete in that regard.

  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 for the single parameter 'objectId,' so the schema already explains it as an IOTA object ID. The description's 'by ID' adds no new semantic information. Per the rubric baseline, since schema coverage is high, a score of 3 is appropriate; the description does not enhance understanding of the parameter.

  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 'Fetch details of an IOTA object by ID' uses a specific verb ('fetch') and resource ('object'), and clearly specifies the lookup key (by ID). This distinguishes it from sibling tools like iota_objects_by_owner which lists by owner, and iota_get_coins which deals with coins, making the tool's purpose unambiguous.

  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 given on when to use this tool versus alternatives. It does not mention that the tool is for retrieving a single object by its unique ID, nor does it contrast with iota_objects_by_owner or iota_get_coins. The agent receives no usage context, so the description fails to help in tool selection beyond the basic purpose.

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

• iota_wallet_addressB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavior, but it only states 'Get', which implies a read operation without explicitly confirming no side effects. It also provides no details about the return value, format, or prerequisites (e.g., wallet initialization), leaving significant behavioral 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 a single, concise sentence that is front-loaded with the essential information. Every word contributes to the purpose, with no filler 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?

  For a tool with no parameters and no output schema, this description provides the core information needed to understand what the tool does. While it could mention the return format or any caveats, the simplicity of the tool makes this description reasonably complete for an agent.

  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, so the schema coverage is trivially 100%. Per the rubric, a zero-parameter tool gets a baseline score of 4 since the description does not need to explain parameter semantics.

  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 ('Get') and resource ('current IOTA Agent Wallet address'), clearly indicating the tool's function. However, it does not explicitly distinguish itself from sibling tools like iota_wallet_accounts, which might also relate to addresses.

  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 regarding when to use this tool instead of alternatives. An agent receives no context about whether this is the preferred tool for retrieving an address versus iota_wallet_accounts or other wallet-related tools.

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

• iota_cliB
  3.4/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full responsibility for behavioral disclosure. It states that it runs any CLI command but does not disclose potential side effects, safety implications, exit codes, or output format. For a tool that can execute arbitrary commands, this is a significant lack of transparency.

  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, front-loaded with the action and resource, and includes illustrative examples. Every word earns its place, and there is no redundant 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 tool's potential for arbitrary command execution and the absence of any output schema or annotations, the description is under-specified. It lacks safety warnings, expected return value structure, or guidance on how the tool interacts with the working directory. The medium complexity demands more context than a single line provides.

  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 schema already documents both parameters (cwd and args) with 100% coverage, giving a baseline of 3. The description adds value by providing example argument values ('client gas', 'client ptb'), which illustrate the expected format and help an agent construct valid invocations, so a 4 is warranted.

  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 purpose: running any IOTA CLI command, with concrete examples like 'client gas' and 'client objects'. The verb 'Run' and resource 'any IOTA CLI command' make it distinct from sibling tools that are specialized wrappers for specific IOTA operations.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this generic CLI runner versus the many specific sibling tools (e.g., iota_wallet_balance, iota_get_coins). The description does not mention that specialized tools should be preferred when available, or any scenarios where this tool is the right choice.

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

• iota_coin_metadataB
  3.4/5.0
  Behavior3/5

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

  The description implies a read-only operation via 'Get', but with no annotations it carries the full burden. It does not disclose response format, error behavior, or any operational constraints. For a simple metadata getter this is acceptable but minimal.

  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 filler. It directly states the action and target resource, making it maximally concise.

  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?

  With no output schema and no annotations, the description should explain what metadata is actually returned (e.g., symbol, decimals, supply). It only says 'metadata', leaving the return value ambiguous and the tool under-specified for an agent.

  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 of the single parameter, including a clear description and an example ('0x2::iota::IOTA'). The tool description adds no further parameter semantics, so baseline 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 uses a specific verb ('Get') and resource ('metadata for a coin type'), clearly distinguishing it from sibling tools like iota_get_price (price), iota_get_coins (coin balances), and iota_object (generic object data).

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives. There is no mention of when to prefer iota_coin_metadata over similar tools like iota_get_coins or iota_object, nor any exclusions.

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

• iota_objects_by_ownerB
  3.4/5.0
  Behavior2/5

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

  No annotations are present, so the description must convey behavioral traits. It correctly indicates a read-only listing operation but omits details about pagination, response format, or whether nested/wrapped objects are included. This is a significant gap 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, front-loaded sentence with no wasted words. It effectively communicates the core function without unnecessary detail.

  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 absence of an output schema and annotations, the description should explain what the response contains or any notable behavior. It only states the list action, leaving the agent to guess about result shape, pagination, and edge cases.

  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 clear descriptions for both 'address' and 'type' parameters. The tool description adds no additional semantic value beyond the schema, 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 uses a specific verb ('List') and resource ('objects owned by an address'), making the tool's function immediately clear. This distinguishes it from siblings like iota_get_coins (coins only) and iota_object (single object retrieval).

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

  Usage Guidelines3/5

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

  The description implies usage whenever all objects for an address are needed, but does not explicitly state when to prefer this over alternatives like iota_get_coins or iota_object. No exclusions or conditional guidance are provided.

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

• move_buildB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Build a Move package' without explaining side effects, whether network access is needed, whether it produces artifacts, or what the return value is. This is insufficient for a tool that likely compiles code and may modify the file system.

  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 sentence that is front-loaded and contains no wasted words. It efficiently communicates the core purpose without verbose explanations, earning a perfect conciseness score.

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

  Completeness2/5

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

  Given that there is no output schema and no annotations, the description is incomplete for a build tool. It does not explain what the build process entails, expected outputs, potential errors, or how this fits into the larger Move development workflow (e.g., building before testing or publishing). The description is too minimal to be fully actionable for an agent.

  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 has one parameter with 100% description coverage: 'Path to the Move package directory'. The tool description adds no additional meaning beyond the schema. Since schema coverage is high, the baseline of 3 applies; the description does not need to compensate but also does not enrich parameter understanding.

  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: 'Build a Move package on IOTA'. The verb 'Build' is specific, the resource 'Move package' is defined, and the platform 'IOTA' adds context. This distinguishes it from siblings like move_test or move_publish_unsigned, which perform different actions on Move packages.

  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 this is the build step for Move packages, but it does not explicitly say when to use this tool versus alternatives like move_test or move_publish_unsigned. There are no exclusions or preconditions mentioned, so the guidance is only implicit rather than explicit.

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

• iota_wallet_pendingA
  3.5/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. 'Get' implies a read-only operation, but no explicit statement is made about side effects, pagination, or ordering. The behavior is straightforward but minimally disclosed.

  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 fully captures the tool's purpose without waste. It is front-loaded with the action verb and resource.

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

  Completeness4/5

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

  For a zero-parameter list operation with no output schema, the description sufficiently states what the tool does. It does not explain the workflow context (e.g., that pending transactions can then be approved/rejected), but this is not strictly required for basic 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?

  The tool has zero parameters, so schema coverage is trivially complete. The description adds no parameter details because none exist, and the baseline for 0 params is 4.

  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 the resource ('pending transactions awaiting approval'), which distinguishes it from broader transaction listing tools like iota_transaction. It is specific and not a tautology, though it does not explicitly contrast with sibling 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?

  The description provides no guidance on when to use this tool versus alternatives such as iota_wallet_approve or iota_wallet_reject. There is no mention of prerequisites, typical use cases, or exclusions.

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

• iota_package_infoA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. The verb 'Fetch' implies a read-only operation, but the description does not mention any other behavioral aspects such as error handling, pagination, or prerequisites beyond the packageId.

  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 no redundant 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?

  For a tool with one parameter and no output schema, the description provides enough high-level detail: it identifies the resource (package info, modules, ABIs) and the required input. It lacks usage guidance but that is scored separately.

  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 the parameter documentation with 'Package object ID'. The description adds no additional meaning about the packageId parameter, so baseline 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 the specific verb 'Fetch' and clearly states the resource: 'Move package info, modules, and ABIs'. This distinguishes it from sibling tools like iota_object or iota_decompile.

  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 iota_object or iota_decompile. It only states what it does, leaving usage context implied.

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

• iota_wallet_rejectA
  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 alone must disclose behavioral traits. It only states 'Reject' without detailing side effects, reversibility, or whether it permanently removes the transaction. It doesn't mention if rejection requires confirmation or what happens to the wallet state, leaving significant behavioral unknowns for the agent.

  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 efficiently states the action and target, making it easy to parse. Conciseness is excellent.

  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 tool with one required parameter and full schema coverage, the description is largely sufficient. It clearly defines the action and scope. However, it lacks some contextual depth like behavior on non-pending transactions or return value details, but given the tool's simplicity, this is not a major gap.

  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 covers 100% of parameter semantics with the requestId description 'Request ID to reject'. The tool description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate given the schema's completeness.

  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 'Reject a pending transaction' uses a specific verb ('reject') and a clear resource ('pending transaction'). It clearly distinguishes from sibling tools like iota_wallet_approve, which handles the opposite action, and iota_wallet_pending, which likely lists pending transactions.

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

  Usage Guidelines3/5

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

  The description implies the tool is for pending transactions but provides no explicit guidance on when to use it versus alternatives. It does not mention that this should be used only after reviewing pending transactions via iota_wallet_pending, nor does it exclude cases like already-approved transactions. Usage context is implied but not detailed.

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

• iota_resolve_nameA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It states a simple 'resolve' action, which implies a read-only lookup, but it does not disclose error behavior, network requirements, or what happens for nonexistent names. The description is not misleading but adds little beyond the basic function.

  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 sentence of 11 words, front-loaded with the action and resource. Every word contributes meaning, with no redundancy or filler.

  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 low complexity (1 parameter, no output schema), the description adequately covers the essential inputs and the expected output (address). It could be more explicit about return format or failure modes, but it is sufficiently complete for a simple resolver.

  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 fully documents the single parameter 'name' with an example ('alice.iota'), achieving 100% coverage. The description adds no additional parameter meaning beyond what the schema already provides, 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.

  Purpose5/5

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

  The description uses the specific verb 'Resolve' and identifies both the input resource ('IOTA Name Service (IOTA NS) name') and the output ('address'). This clearly states what the tool does and distinguishes it from sibling tools, none of which perform name 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?

  No explicit guidance is given on when to use this tool versus alternatives. The name itself strongly implies usage for resolving IOTA NS names, but the description lacks any context or exclusion criteria. Usage is inferred rather than explicitly stated.

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

• move_publish_unsignedA
  3.9/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 does disclose the key safety trait ('does not execute'), but it does not describe what 'create' means in terms of side effects (e.g., returns a transaction object, writes to disk), nor does it mention any prerequisites. It adds some value but lacks deeper behavioral context.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence: 'Build and create an unsigned publish transaction (safe — does not execute)'. Every word earns its place, and the safety qualifier is essential and succinct. 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 description conveys the core purpose and safety property, but it does not explain the return value or how this tool fits into the transaction workflow (e.g., subsequent signing). Given the absence of an output schema, this is a notable gap, though the tool is simple and inputs are fully described.

  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%: both 'path' and 'gas_budget' have descriptive comments in the input schema. The tool description adds no parameter-specific meaning. Baseline 3 is appropriate because the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the action: 'Build and create an unsigned publish transaction', and explicitly notes 'does not execute', which distinguishes it from execution tools like iota_wallet_sign_execute. The verb+resource combination is specific and 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 that this tool creates an unsigned transaction and is 'safe' because it does not execute. While it doesn't explicitly name alternatives or exclusions, the 'does not execute' implies it should be used before signing/execution steps. This is clear context without formal exclusions.

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

• iota_epoch_infoA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. The verb 'Get' implies a read-only operation, but the description does not explicitly mention safety, side effects, or return format. For a zero-parameter getter this is minimally acceptable but lacks proactive disclosure.

  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?

  A single, front-loaded sentence with no filler. Every word adds meaning, making it highly 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?

  The description names the informational outputs (epoch, checkpoint, network stats) which is sufficient for such a simple read-only tool with zero parameters. No output schema exists, but the description adequately conveys the tool's scope, though it does not detail the exact structure or any caveats.

  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, so the input schema is trivially complete. Base baseline for 0 params is 4, and the description adds no parameter-specific information, which is unnecessary 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 uses a specific verb 'Get' with clear resources: 'current epoch, checkpoint, and network stats'. It clearly distinguishes this tool from siblings like price, wallet, and object tools.

  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: an agent would use this when needing current network state. However, no explicit alternatives, exclusions, or contextual guidance are provided, so it only meets the 'implied usage' criterion.

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

• iota_wallet_accountsA
  4/5.0
  Behavior3/5

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

  The description clearly indicates a read-only listing operation via the verb 'list', but it does not disclose any additional behavioral traits such as required permissions, side effects, or return format. Since no annotations are provided, the description carries the full burden, and the lack of detail beyond the core action is a slight 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, front-loaded sentence with no redundant or extraneous information. Every word contributes to the meaning, making it appropriately 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 zero-parameter, simple listing tool, the description is sufficient at a high level. However, without an output schema, it does not specify the exact return format (e.g., list of account strings or objects), which is a minor but non-critical omission.

  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, so the schema description coverage is trivially 100% and the description correctly implies no inputs are needed. The baseline for zero parameters is 4, and the description adds no unnecessary parameter information.

  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 ('List') and clearly identifies the resource ('all accounts in the IOTA Agent Wallet'), which distinguishes it from sibling wallet tools like balance, address, or pending. The purpose is unambiguous and immediately understandable.

  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 does not explicitly state when to use this tool versus alternatives, but the usage is clearly implied as the only account-listing tool among the siblings. No exclusions or alternative recommendations are provided, but the simple nature of the operation makes the implied usage sufficient.

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

• iota_get_coinsA
  4.1/5.0
  Behavior3/5

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

  Without annotations, the description carries the burden. It clarifies that the tool returns a collection of coin objects rather than a balance, but it doesn't disclose return format, pagination, or whether it includes spent coins. Still, 'Get' implies read-only, and the description gives a reasonable behavioral overview.

  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 core action and object type. No filler or redundant details.

  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 has no annotations and no output schema, so the description is the only source of behavioral context. It covers the main purpose but omits details like return shape, potential errors, or how it differs from balance tools. It's adequate for a straightforward getter but not comprehensive.

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

  Parameters4/5

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

  Schema coverage is 100%, but the description adds meaning by stating '(IOTA or any token)', clarifying that coinType can filter for any token, not just IOTA. This goes beyond the schema's bare 'Coin type' description.

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

  Purpose5/5

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

  The description uses a specific verb ('Get') and resource ('all coin objects for an address'), and further clarifies scope with '(IOTA or any token)'. This distinguishes it from sibling tools like iota_wallet_balance (which likely returns balances) and iota_objects_by_owner (which returns all 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 provides clear context of use: retrieving all coin objects for a given address, optionally filtered by coin type. However, it doesn't explicitly mention alternatives or exclusions (e.g., 'use iota_wallet_balance for aggregated balance'), so it's not fully explicit.

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

• iota_get_priceA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses the external data source (CoinGecko), implying a network call and read-only behavior. However, it doesn't mention potential latency, caching, or failure modes, so it's not fully transparent.

  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?

  One short sentence with no filler. It is front-loaded and efficient, earning a 5.

  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 parameterless read-only price tool, the description is largely complete. It names the source and the metric, but doesn't specify the return format or currency base. Given no output schema, a bit more detail could help, but the simplicity mitigates this.

  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 the schema is empty. Per the rubric, 0 params gives a baseline of 4. The description adds no parameter info, but none is needed.

  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 action ('Get') and resource ('current IOTA token price'), with a source ('via CoinGecko'). This clearly distinguishes it from sibling tools, none of which offer price data.

  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: this tool is for retrieving the current IOTA price. It doesn't mention alternatives or exclusions, but since there are no other price tools in the sibling list, this is sufficient. Still, it lacks explicit when/when-not guidance.

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

• iota_wallet_balanceA
  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 burden. It implies a read-only operation by using 'get', and scopes to the 'current wallet', but it does not disclose return format, unit, or potential network interaction. It adds minimal behavioral context beyond the core function.

  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?

  A single, front-loaded sentence with no fluff. Every word contributes to the meaning, and it is appropriately sized for a simple zero-parameter tool.

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

  Completeness4/5

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

  For a zero-parameter, no-output-schema tool, the description sufficiently covers the action. It does not explain the return value or units, but 'balance' is inherently clear. Slight gap in not specifying whether it returns e.g., a number or string, but overall complete for its simplicity.

  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 input schema has zero parameters, so there is nothing to explain. Baseline is 4 per the rubric, and the description correctly omits parameter details since none exist. No additional meaning is needed or provided.

  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 a specific verb and resource: 'Get IOTA balance of the current wallet'. It distinguishes itself from sibling tools by focusing on balance, while siblings like iota_get_price, iota_wallet_address, and iota_wallet_accounts target different concerns.

  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 to obtain the wallet's IOTA balance) without explicit alternatives or exclusions. While it doesn't mention when not to use it or name alternatives, the zero-parameter nature and distinct purpose make the usage straightforward.

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