Server Quality Checklist

Tool Scores

• keeta_get_network_configB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s]' configuration and describes the return values, but it doesn't mention whether this is a read-only operation, if it requires authentication, potential rate limits, or error conditions. For a tool with zero annotation coverage, this leaves significant behavioral gaps, though it does add some context about the return structure.

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

  Conciseness5/5

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

  The description is appropriately sized and front-loaded: the first sentence clearly states the purpose, the second provides usage context, and the third specifies return values. Every sentence adds value without redundancy, and there's no wasted text. It efficiently conveys necessary information in a structured manner.

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

  Completeness3/5

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

  Given the tool's low complexity (1 parameter, no nested objects) and 100% schema coverage, the description is somewhat complete but has gaps. It explains the purpose and return values, but with no output schema and no annotations, it lacks details on behavioral aspects like safety or errors. For a simple read operation, this is adequate but not fully comprehensive, as it could benefit from more transparency about operational constraints.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the 'network' parameter documented as 'Network alias' and an enum of ['main', 'test']. The description doesn't add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain what 'main' or 'test' mean in context). Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to given the schema's completeness.

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

  Purpose4/5

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

  The description clearly states the verb 'Get' and resource 'configuration for a Keeta network', specifying what information is included (network ID, base token address, network account address). It distinguishes itself from siblings like keeta_anchor_execute or keeta_request_test_tokens by focusing on configuration retrieval rather than execution or token requests. However, it doesn't explicitly contrast with keeta_list_sdk_methods which might also provide informational content.

  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 provides implied usage guidance by stating 'This is useful for understanding the network you are operating on before making transactions,' which suggests using this tool for preparatory checks. However, it lacks explicit alternatives (e.g., when to use keeta_derive_account instead) or clear exclusions (e.g., when not to use it if you already have the configuration). The guidance is helpful but not comprehensive.

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

• keeta_builder_executeA
  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 explains the multi-step process (create client, call operations, optionally compute/publish) and mentions auto-resolving arguments, but lacks details on permissions, rate limits, error handling, or what happens if operations fail mid-sequence.

  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 appropriately sized and front-loaded with the core purpose. Each sentence adds value: explaining the builder pattern, referencing discovery tools, listing common methods, detailing the execution flow, providing examples, and clarifying argument resolution. Minor room for tightening exists in the example section.

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

  Completeness3/5

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

  For a complex tool with 5 parameters, no annotations, and no output schema, the description is adequate but has gaps. It covers the execution flow and parameter semantics well, but lacks information about return values (only mentions 'block hashes' briefly), error conditions, and operational constraints that would help an agent use it safely.

  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 description coverage is 100%, so the baseline is 3. The description adds significant value by explaining the structure of operations objects (method, args, options), providing example operations, clarifying that 'options' is passed as the last argument, and noting auto-resolving behavior. This compensates well beyond the schema's technical documentation.

  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 executes a sequence of operations using the UserClient Builder pattern, with specific verbs ('execute', 'compute', 'publish') and resources ('operations', 'blocks'). It distinguishes from siblings like keeta_client_execute by focusing on the builder pattern for batching operations.

  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 for when to use this tool (for batching multiple operations into blocks) and references keeta_list_sdk_methods for discovering available methods. However, it doesn't explicitly state when NOT to use it or compare it to alternatives like keeta_client_execute for single operations.

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

• keeta_derive_accountA
  4.2/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. It discloses key behavioral traits: deterministic output based on seed/index/algorithm combinations, the format of the returned address ('keeta_...'), and its role as an identifier in other tools. It doesn't cover error cases, performance, or security implications, but provides solid operational 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 efficiently structured: the first sentence states the core purpose, followed by key behavioral details, supported algorithms with brief context, and return format. Every sentence adds value with zero waste, and it's appropriately sized for a 3-parameter tool with no annotations.

  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 derivation tool with no annotations and no output schema, the description is quite complete. It explains the deterministic behavior, address format usage, algorithm options, and return structure. It doesn't cover error handling or edge cases, but given the straightforward schema and clear purpose, it provides sufficient context for an agent to use the tool 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?

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it mentions the seed comes from keeta_generate_seed and lists algorithm options with brief explanations, but doesn't provide additional syntax, constraints, or examples. Baseline 3 is appropriate when 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 specific action ('derive a Keeta account'), the resource ('public/private keypair'), and the inputs ('from a seed and index'). It distinguishes from sibling tools like keeta_generate_seed (which creates seeds) and keeta_request_test_tokens (which requests tokens) by focusing on deterministic key derivation.

  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 for when to use this tool: to create deterministic accounts from seeds and indices, with the returned address used in other tools. It doesn't explicitly state when not to use it or name alternatives among siblings, but the purpose naturally differentiates it from tools like keeta_generate_seed or execution tools.

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

• keeta_request_test_tokensA
  4.2/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 burden and does well: it discloses the network constraint (test only), the fixed amount (5 KTA), the purpose (development/testing), and what KTA is used for (transaction fees). It also describes the return structure. It doesn't mention rate limits or authentication needs, but covers key behavioral aspects.

  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 front-loaded with the core purpose, followed by constraints and return details. Every sentence earns its place: first states what it does, second specifies network and amount, third explains KTA's role, fourth documents returns. No wasted words, appropriately sized for the tool's complexity.

  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 single-parameter tool with no annotations and no output schema, the description is quite complete: it explains purpose, constraints, amount, usage context, and return structure. The only minor gap is lack of explicit error cases or rate limit info, but it covers most essential context given the tool's simplicity.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the single parameter 'address' documented as 'Keeta address (keeta_...) to fund'. The description adds that it's 'the given address' and implies it receives tokens, but doesn't provide additional syntax or format details beyond what the schema already states. Baseline 3 is appropriate when 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 specific action ('Request free KTA tokens'), resource ('from the Keeta test network faucet'), and scope ('Only works on the test network'). It distinguishes this tool from siblings like keeta_anchor_execute or keeta_builder_execute by focusing on faucet functionality rather than execution or account management.

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

  Usage Guidelines4/5

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

  The description explicitly states 'Only works on the test network' and mentions 'for development/testing', providing clear context for when to use this tool. However, it doesn't specify when NOT to use it (e.g., for production) or name alternatives explicitly, though the sibling tools suggest other options for different operations.

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

• keeta_user_client_executeA
  4.2/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 adds valuable context: it mentions 'authenticated operations requiring an account,' lists common methods and properties, and references auto-resolution rules via keeta_client_execute. However, it lacks details on error handling, rate limits, or specific authentication requirements beyond the seed parameter, leaving gaps for a mutation-capable tool.

  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 appropriately sized and front-loaded, starting with the core purpose. Each sentence adds value: the first defines the tool, the second guides usage, the third lists methods, the fourth details properties, and the fifth explains argument resolution. There's minimal waste, though the list of common methods is somewhat lengthy but informative.

  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 complexity (5 parameters, no annotations, no output schema), the description is moderately complete. It covers purpose, usage, methods, properties, and argument resolution, but lacks details on return values, error cases, or specific behavioral traits like side effects or permissions. Without annotations or output schema, more context on what to expect from executions would improve completeness.

  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 description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it explains that 'Arguments are auto-resolved (see keeta_client_execute for resolution rules),' clarifies that 'GET_PROPERTY' is used for reading properties with examples, and lists common methods and properties, enhancing understanding of the 'method' and 'args' parameters. This elevates the score above baseline.

  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: 'Execute any method on the Keeta UserClient (authenticated operations requiring an account).' It specifies the verb ('execute'), resource ('Keeta UserClient'), and scope ('authenticated operations requiring an account'), distinguishing it from sibling tools like keeta_client_execute (which handles argument resolution) and keeta_list_sdk_methods (which lists methods).

  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 provides explicit guidance on when to use this tool: it directs users to 'Use keeta_list_sdk_methods with target "UserClient" to discover available methods,' naming a specific alternative tool. It also clarifies that it's for 'authenticated operations requiring an account,' implying keeta_client_execute might be for non-authenticated or general cases, though not explicitly stated as an exclusion.

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

• keeta_generate_seedA
  4.5/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 of behavioral disclosure. It effectively describes key traits: the tool generates a random seed, which is foundational for deriving accounts and controlling funds, and emphasizes security implications. It also specifies the return format. While it covers critical aspects, it lacks details like rate limits or error handling, but this is sufficient for a high score given the 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 front-loaded with the core purpose in the first sentence, followed by essential context and a security warning, and ends with the return value. Every sentence adds value without waste, making it highly efficient and well-structured.

  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 complexity (simple generation with no parameters), no annotations, no output schema, and rich sibling context, the description is complete. It explains what the tool does, its role in the ecosystem, security considerations, and the return format, providing all necessary information for an AI agent to use 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?

  The tool has 0 parameters, and the schema description coverage is 100%, so the baseline is 4. The description does not need to add parameter information, and it appropriately focuses on the tool's purpose and output without redundancy.

  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 with a specific verb ('Generate') and resource ('new random cryptographic seed for the Keeta Network'). It distinguishes this from sibling tools like keeta_derive_account by explaining that the seed is the starting point for deriving accounts, making its role explicit and unique.

  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 on when to use this tool: as the 'starting point for all Keeta operations' and to derive accounts via keeta_derive_account. It includes a security warning about storing the seed securely. However, it does not explicitly state when not to use it or name alternatives, which prevents a perfect score.

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

• keeta_anchor_executeA
  4.6/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 burden and does well by explaining the dynamic runtime discovery system, auto-resolution of arguments, and the three subtarget types with their specific behaviors. It mentions seed omission for read-only operations (implied in schema but reinforced here). Could improve by explicitly stating whether operations are read-only or mutating.

  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 efficiently structured with a clear opening statement, bulleted subtarget explanations, and specific guidance sentences. Every sentence serves a distinct purpose with zero wasted content, making it easy to parse despite the tool's complexity.

  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 complex 9-parameter tool with no annotations and no output schema, the description provides substantial context about the execution model, subtarget semantics, and discovery mechanisms. It references related tools for additional functionality. Could be more complete by explaining return value expectations or error handling.

  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?

  With 100% schema description coverage, the baseline is 3, but the description adds significant value by explaining the semantic meaning of subtarget types (service, lib, metadata) with concrete examples, clarifying the relationship between parameters, and providing discovery guidance that goes beyond schema documentation.

  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 executes ANY anchor operation on the Keeta Network with fully dynamic runtime discovery. It distinguishes from siblings by specifying this is for anchor operations specifically, unlike keeta_client_execute or keeta_user_client_execute which handle different execution contexts.

  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 provides explicit guidance on when to use different subtargets (service, lib, metadata) and directs users to keeta_list_sdk_methods for discovery. It also references keeta_client_execute for argument resolution rules, creating clear relationships with sibling tools.

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

• keeta_client_executeA
  4.6/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 of behavioral disclosure. It effectively describes key traits: it's for 'read-only network operations' (indicating safety), mentions auto-resolution of arguments (important behavioral detail), and lists common methods. However, it doesn't cover potential rate limits, error handling, or response formats, leaving some gaps.

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

  Conciseness5/5

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

  The description is well-structured and front-loaded with the core purpose. Each sentence adds essential information: purpose, discovery method, common examples, and argument resolution rules. There's no wasted text, and it efficiently communicates complex concepts in a compact form.

  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 complexity (executing arbitrary methods with auto-resolved arguments) and lack of annotations or output schema, the description does a good job of covering key aspects: purpose, usage, and parameter behavior. However, it doesn't explain return values or potential errors, which could be important for a tool with no output schema, leaving some contextual gaps.

  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 description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema by explaining how 'args' are auto-resolved with specific examples (e.g., strings starting with 'keeta_' become Account objects). This clarifies parameter semantics that aren't evident from the schema alone, though it doesn't detail 'network' or 'method' 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 states the tool's purpose: 'Execute any method on the Keeta Client (read-only network operations).' It specifies the exact resource (Keeta Client) and verb (execute methods), and distinguishes it from siblings by emphasizing 'read-only network operations' and referencing keeta_list_sdk_methods for discovery.

  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 provides explicit guidance on when to use this tool: 'Use keeta_list_sdk_methods with target "Client" to discover available methods.' It also lists common methods as examples, helping users understand typical use cases versus alternatives like keeta_user_client_execute or other sibling tools.

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

• keeta_list_sdk_methodsA
  4.6/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 of behavioral disclosure. It effectively describes the tool's behavior: it's for runtime discovery, lists specific target categories (Core SDK fixed vs. Anchor SDK dynamic), and explains how dynamic targets auto-discover new services. However, it lacks details on output format, rate limits, or error handling, which are minor 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 well-structured and front-loaded with the core purpose. Each sentence earns its place by providing essential information: purpose, usage guidelines, parameter details, and examples. It avoids redundancy and is appropriately sized for the tool's complexity.

  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 complexity (runtime discovery with dynamic targets) and no output schema, the description is mostly complete. It covers purpose, usage, parameter semantics, and behavioral context. However, it doesn't describe the return format or what the discovered methods/properties look like, which is a minor gap given the lack of output schema.

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

  Parameters4/5

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

  The schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining the semantics of the 'target' parameter in detail, categorizing Core SDK vs. Anchor SDK, listing fixed and dynamic values with examples, and providing usage tips (e.g., 'start with AnchorCatalog'). This goes well beyond the schema's enum and 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 clearly states the tool's purpose: 'Discover available methods and properties on Keeta SDK objects at runtime.' It specifies the verb ('discover') and resource ('methods and properties on Keeta SDK objects'), and distinguishes it from sibling tools like execute tools by advising to use it FIRST to understand available operations.

  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 provides explicit guidance on when to use this tool: 'Use this FIRST to understand what operations are available before calling execute tools.' It includes alternatives for dynamic targets ('start with "AnchorCatalog" to see everything available, then drill into specific services/modules') and clarifies usage contexts (e.g., 'When in doubt, start with...').

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