Netfluid

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 this is a read-only informational tool ('Returns general information'), which is clear. However, it doesn't disclose any behavioral traits like authentication requirements, rate limits, or what specific format the information will be returned in beyond 'a json object containing the schema'. The description doesn't contradict any annotations since there are none.

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

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

The description is poorly structured with inconsistent formatting and capitalization ('tools' instead of 'tool', mixed punctuation). It contains redundant elements like '@return: a json object containing the schema' which is better handled by the output schema. The 'Start Here ! Everything Netfluid' could be integrated more smoothly. While brief, it lacks professional polish.

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

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

Given that this is a simple informational tool with 0 parameters, no annotations, but has an output schema, the description provides adequate context. It explains what information is returned and suggests it's a starting point. The output schema will handle the return format details, so the description doesn't need to explain return values. However, it could better clarify the relationship to other informational tools.

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

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

The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to add parameter information since there are no parameters, and it correctly indicates this is a parameterless tool through its description of what it returns.

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

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

The description clearly states what the tool does: 'Returns general information about netfluid, domains in use, website addresses, policies, support contacts'. It specifies the verb ('returns') and resource ('general information about netfluid') with specific categories listed. However, it doesn't explicitly distinguish this from sibling tools like 'ai__help_ping' or 'ai__support' that 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.

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

The description provides explicit usage guidance with 'Start Here ! Everything Netfluid', indicating this should be the first tool to use when exploring the Netfluid system. It also mentions 'This tools provides reference information in the "referenced_tools" schema', which helps the agent understand the context of when to use this tool versus others.

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

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 a mutation tool (blocks access), requires specific permissions (administrator privileges), and affects all systems. It could improve by mentioning potential side effects (e.g., duration of pause, impact on users) or rate limits, but it covers the essential safety and authorization context well.

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

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

The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by context and parameters. Every sentence adds value, with no redundant information. Minor improvements could include bullet points for parameters, but it remains efficient and well-structured.

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

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

Given the tool's complexity (a mutation with security implications), no annotations, and an output schema present (which handles return values), the description is reasonably complete. It covers purpose, usage context, and parameter meanings. To be fully complete, it could mention error conditions or confirm the temporary nature more explicitly, but it meets most needs effectively.

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

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

The schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for both parameters: 'api_key' is described as 'The api key with administrator privileges' (clarifying privilege requirements), and 'wallet_fk' as 'The wallet_fk to pause' (indicating the target). This goes beyond the bare schema, though it could provide more detail on parameter formats or constraints.

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

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

The description clearly states the specific action ('temporarily blocks access') and resource ('the wallet'), distinguishing it from siblings like 'ai__access_resume' (which presumably resumes access) and 'ai__account_pause' (which likely pauses accounts rather than wallet access). The verb 'blocks' is precise and the scope 'for all systems' clarifies the extent of the action.

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

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

The description explicitly states when to use this tool: 'Temporarily blocks access to the wallet for all systems.' It also provides prerequisites: 'This end point requires an api_key with administrator privileges.' However, it does not explicitly mention when not to use it or name alternatives (e.g., 'ai__access_resume' for resuming access), 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.

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

Annotations are empty, so the description carries full burden. It mentions that assignment 'makes getting a session token much easier in the future,' hinting at future authentication benefits, but fails to disclose critical behavioral traits such as whether this is a read-only or destructive operation, required permissions, rate limits, or error handling. This leaves significant gaps in understanding the tool's behavior.

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

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

The description is moderately concise but has redundancy (the first two sentences are identical) and includes param annotations that could be streamlined. It front-loads the core purpose but wastes space on repetition. While not overly verbose, it lacks optimal efficiency in structure.

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

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

Given 5 parameters with 0% schema coverage and no annotations, the description partially compensates by explaining some parameters and hinting at usage benefits. An output schema exists, so return values need not be described. However, the gaps in parameter documentation and behavioral transparency make it incomplete for a tool with multiple required inputs and no annotation support.

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

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. It lists three parameters (api_key, token, wallet_fk) with brief explanations (e.g., 'The api key allocated to your application'), but omits two required parameters (user_id, platform) entirely. This incomplete coverage fails to adequately explain parameter meanings beyond the schema, leaving key inputs undocumented.

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

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

The description clearly states the action ('assigns') and the resources involved ('wallet_fk to a channel user id'), specifying the channels as discord, telegram, and whatsapp. However, it does not explicitly differentiate from sibling tools like 'ai__access_platform_login' or 'ai__access_platform_wallet_list', which might handle related platform interactions, leaving some ambiguity in sibling distinction.

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

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

The description includes a guideline to 'prompt the customer to do this, as it makes getting a session token much easier in the future,' which implies a preferred usage context. However, it does not specify when to use this tool versus alternatives (e.g., 'ai__access_platform_login' for login vs. assignment) or any exclusions, providing only implied rather than explicit guidance.

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

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 behavioral traits: the one-attempt limit and the consequence of failure (user must return to website). It also clarifies the tool's scope ('works on any wallet_fk and PIN combination') and return type ('a json object'). However, it doesn't cover potential error responses, rate limits, or authentication requirements beyond the PIN.

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

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

The description is front-loaded with the core purpose but contains redundant repetition ('Retrieves a session token...' appears twice). The @param/@return annotations are helpful but could be integrated more smoothly. Overall, it conveys necessary information but could be more streamlined without sacrificing clarity.

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

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

For a 2-parameter authentication tool with no annotations but an output schema, the description provides good context. It covers purpose, usage constraints, parameter basics, and return type. The output schema likely details the 'json object' structure, so the description doesn't need to explain return values. However, it lacks details on error handling or security implications.

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

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

Schema description coverage is 0%, so the schema provides no parameter documentation. The description compensates by defining both parameters: 'wallet_fk: The wallet_fk' and 'pin: The 5-digit numerical pin associated with this wallet_fk.' It adds crucial semantics for 'pin' (5-digit, numeric) but provides minimal context for 'wallet_fk' (just repeats the name). Given the coverage gap, this is adequate but not comprehensive.

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

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

The description clearly states the tool's purpose: 'Retrieves a session token based on a wallet_fk and 5-digit (numeric) PIN.' It specifies the verb ('retrieves'), resource ('session token'), and input requirements. However, it doesn't explicitly differentiate this from sibling tools like 'ai__session_2_token' or 'ai__session', which might offer alternative ways to obtain session tokens.

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

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: 'if you have a wallet_fk, but no session token, it's a shortcut to the session token.' It also includes a critical constraint: 'Only 1 attempt is allowed, get the PIN wrong and you have to send the user back to the website to get a session key.' This offers practical guidance, though it doesn't explicitly compare to alternatives like 'ai__session_2_token' or mention prerequisites beyond having the wallet_fk and PIN.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal important constraints: the tool only works if wallets have been previously assigned to the specific channel and user ID, and it's part of a workflow to obtain session tokens. However, it doesn't disclose whether this is a read-only operation, what authentication might be required, potential rate limits, or error conditions. The description adds some context but leaves significant behavioral aspects unspecified.

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

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

The description is reasonably concise but has some redundancy: the first sentence is repeated verbatim. The information is front-loaded with the core purpose, followed by usage context and parameter details. However, the repetition wastes space, and the structure could be more streamlined by eliminating the duplicate opening sentence.

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

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

Given the tool's moderate complexity (2 parameters, no annotations, but has output schema), the description provides adequate coverage. It explains the purpose, usage context, and parameter meanings. Since an output schema exists, the description doesn't need to explain return values. The main gap is the lack of behavioral details like authentication requirements or error handling, but the core functionality is sufficiently described for an agent to understand when and how to use this tool.

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

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

With 0% schema description coverage and 2 parameters, the description provides essential semantic context through @param annotations. It explains that 'user_id' is 'The chat, channel user-id specific to this chat customer' and 'platform' is 'The channel platform: discord, telegram, whatsapp'. This adds meaningful interpretation beyond the bare schema types (both strings). However, it doesn't provide format examples, constraints, or validation rules for these parameters.

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

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

The description clearly states the tool's purpose: 'Retrieves a list of wallets associated with the channel (discord, telegram or whatsapp) and user id'. It specifies the verb ('retrieves'), resource ('wallets'), and scope ('associated with the channel and user id'). However, it doesn't explicitly differentiate from sibling tools like 'ai__wallet_accounts_list' or 'ai__wallet_accounts_list_verbose', which appear to have similar wallet-related functions.

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

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: 'once you have a wallet_fk you can get a session token' and 'This only works if the wallet_fk has been previously assigned to this channel and user id'. It implies this is a prerequisite step for obtaining session tokens. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools.

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

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

Annotations are empty, so the description carries the full burden. It discloses that the tool returns an object with specific fields (key, first_name, etc.), which adds useful context beyond the input schema. However, it lacks details on security implications (e.g., sensitivity of private key recovery), error handling, or rate limits, which are important for a recovery operation.

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

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

The description is moderately concise but has redundancy (the first two sentences are nearly identical). It is front-loaded with the core purpose, but the '@param' and '@return' annotations are informal and could be integrated more smoothly. Some sentences, like 'It's preferable that the person trying to recover', are vague and add little value.

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

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

Given the complexity (recovery operation with security implications), no annotations, and an output schema exists (implied by '@return'), the description is fairly complete. It explains the action, parameters, and return structure. However, it misses behavioral details like authentication needs or potential side effects, which are crucial for such a tool.

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

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. It provides semantic meaning for both parameters: 'api_key' is 'allocated to your application' and 'words' are '24 recovery words, space delimited'. This clarifies the format and purpose, though it could add more on constraints (e.g., word list source). With 0% coverage, this is strong but not exhaustive.

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

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

The description clearly states the tool's purpose: 'Recovers the Netfluid wallet's private key from a set of 24 keywords.' It specifies the verb ('recovers'), resource ('private key'), and mechanism ('from a set of 24 keywords'). However, it does not explicitly differentiate from sibling tools like 'ai__access_pause' or 'ai__access_resume', which appear to be related to access control but have different functions.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions it's 'preferable that the person trying to recover' but does not specify prerequisites, exclusions, or compare it to siblings like 'ai__access_platform_wallet_list' or 'ai__wallet_mnemonic'. This leaves the agent without context for tool selection.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a mutation operation (resumes access), requires specific permissions (admin privileges via api_key), and acts on a specific resource (paused wallet). It doesn't mention side effects, rate limits, or response details, but covers essential mutation and auth context adequately for a tool with no annotations.

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

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

The description is front-loaded with the misleading first sentence, which wastes space. After that, it efficiently states the purpose, requirements, and parameters. However, the structure is slightly awkward due to the initial error, and it could be more streamlined by removing the contradictory opening line.

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

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

Given the tool's complexity (mutation with admin requirements), no annotations, 0% schema coverage, but with an output schema (indicated by @return and context signals), the description does well. It explains the action, permissions, and parameters. The output schema handles return values, so the description doesn't need to detail them. It's mostly complete but could benefit from clarifying the misleading first part.

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

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

Schema description coverage is 0%, so the schema provides no parameter descriptions. The description compensates fully by explaining both parameters: 'api_key: The api key with administrator privileges' and 'wallet_fk: The wallet_fk to resume.' This adds crucial meaning beyond the bare schema types, clarifying the purpose and constraints of each parameter.

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

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

The description starts with 'Temporarily blocks access to the wallet' which is misleading and contradicts the actual purpose stated in the second sentence: 'Resumes access to a paused wallet.' The first sentence appears to be a copy-paste error from a sibling tool (likely ai__access_pause). While the second sentence correctly identifies the verb ('resumes') and resource ('a paused wallet'), the initial misleading statement reduces clarity.

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

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

The description provides some usage context by stating 'This end point requires an api_key with administrator privileges,' which implies when to use it (when admin privileges are available). However, it doesn't explicitly differentiate from siblings like ai__access_pause (which likely pauses instead of resumes) or ai__account_resume (which might resume accounts rather than wallet access). The guidance is implied but not comprehensive.

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

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

With no annotations provided, the description carries full burden. It states this is a change/mutation operation (implied behavioral trait) and specifies the PIN format constraint. However, it doesn't disclose critical behavioral aspects: whether this requires authentication beyond the parameters, if it's reversible, rate limits, error conditions, or what specific changes occur in the system. For a security-sensitive operation like PIN change, this is a significant gap.

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

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

The description is reasonably concise but has structural issues: the first two lines are redundant duplicates, and parameter documentation uses @param/@return syntax that's somewhat verbose. The core information is front-loaded, but the repetition wastes space. It could be more efficiently structured without losing clarity.

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

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

Given this is a mutation tool with no annotations, 4 parameters, and an output schema exists (so return values are documented elsewhere), the description is moderately complete. It covers the basic operation and parameters but lacks important context about security implications, error handling, and system behavior changes that would be crucial for safe PIN modification.

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

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

With 0% schema description coverage, the description compensates well by explaining all 4 parameters: api_key ('allocated to your application'), token and wallet_fk ('provided by /access/login'), and new_pin ('must be 5 numeric digits'). It adds meaningful context about parameter origins and constraints that the bare schema doesn't provide, though it could elaborate more on format expectations beyond '5 digits'.

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

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

The description clearly states the tool's purpose: 'Changes the wallet PIN' with the specific constraint 'must be 5 digits'. This is a specific verb+resource combination that distinguishes it from siblings like wallet-related tools that don't modify PINs (e.g., wallet_accounts_list, wallet_verify). However, it doesn't explicitly differentiate from potential PIN-related siblings that might exist in other contexts.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions prerequisites (api_key, token, wallet_fk from /access/login) but doesn't indicate scenarios where PIN change is appropriate versus other wallet operations or what might happen if used incorrectly. No sibling tools are referenced for comparison.

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

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

No annotations are provided, so the description carries full burden. It states this returns 'public information' which implies read-only access, but doesn't specify authentication requirements, rate limits, or error conditions. The @return annotation adds some value by indicating JSON output format, but behavioral details are minimal.

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

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

The description is appropriately brief with two sentences: one stating the tool's purpose and parameters, another specifying the return format. No unnecessary information is included, though the @return notation could be integrated more smoothly.

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

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

Given the tool has an output schema (which handles return value documentation), 1 parameter with 0% schema coverage, and no annotations, the description provides adequate context. It explains what the tool does, what parameter it takes, and the return format, though more behavioral details would be helpful given the lack of annotations.

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

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

With 0% schema description coverage and only 1 parameter, the description adds significant value by explaining that 'account_fk' is used to retrieve public account information. It doesn't specify the format or constraints of account_fk beyond being an integer, but provides clear semantic context for the single parameter.

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

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

The description clearly states the tool's purpose: 'Returns public information associated with an account_fk' with specific fields listed (address, commodity, currency, type). It distinguishes from siblings like ai__account_info by specifying 'public information' and listing exact fields, though it doesn't explicitly contrast with other account-related tools.

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

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. With many sibling tools like ai__account_info, ai__account_address, and ai__accounts, the description doesn't indicate when this specific tool is appropriate versus those other account information tools.

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

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 mentions validation and verification but doesn't disclose behavioral traits such as what happens on success/failure, whether it's a read-only operation, authentication requirements, rate limits, or error conditions. The mention of '@return: a json object' is minimal and doesn't add meaningful context beyond what the output schema likely provides.

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

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

The description is brief and front-loaded with the core purpose, followed by a minimal return statement. It avoids unnecessary verbosity, though the '@return' note could be more integrated. Overall, it's efficiently structured with little waste.

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

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

Given the tool has an output schema (which likely details the return object), the description doesn't need to explain return values. However, with no annotations, 0% schema coverage for the single parameter, and complexity around validation/verification, the description is incomplete—it lacks details on behavior, error handling, and parameter specifics, making it only minimally adequate.

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

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 for the undocumented parameter 'account_address'. The description only states it's for a 'Netfluid account address (not blockchain address)', which adds some semantic meaning (clarifying it's not a blockchain address) but doesn't explain format, constraints, or examples. This partial compensation is insufficient for the coverage gap.

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

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

The description states the tool 'Validates and verifies the existence of a Netfluid account address' which provides a clear verb ('validates and verifies') and resource ('Netfluid account address'). However, it doesn't distinguish this from potential sibling tools like 'ai__account' or 'ai__account_info' that might also handle account-related operations, making it somewhat vague about its specific niche.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to sibling tools like 'ai__account' or 'ai__account_info', leaving the agent with no contextual usage information.

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

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 indicates this is a mutation tool ('Sets'), includes a caution ('Confirm before executing'), and hints at uniqueness ('try and use unique names'). However, it lacks details on permissions, side effects, error handling, or rate limits. It adds some context but falls short of fully describing behavioral traits for a mutation tool.

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

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

The description is somewhat structured with a purpose statement, caution, and parameter explanations, but it is repetitive (e.g., 'Sets a friendly name/alias on an account' appears twice) and includes informal notes ('try and use unique names'). It could be more streamlined and front-loaded for clarity, with some sentences not earning their place efficiently.

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

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

Given the tool's complexity (mutation with 4 parameters), no annotations, and an output schema present (which handles return values), the description is moderately complete. It covers purpose, basic usage caution, and parameter semantics, but lacks behavioral details like error cases or security requirements. It is adequate but has clear gaps for a mutation tool.

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

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

Schema description coverage is 0%, so the schema provides no parameter details. The description adds semantic information for all four parameters, explaining their purposes (e.g., 'api_key: The api key allocated to your application'). However, it does not specify formats, constraints, or examples beyond basic explanations, leaving gaps in practical usage guidance.

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

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

The description clearly states the tool's purpose: 'Sets a friendly name/alias on an account.' This specifies the verb ('Sets') and resource ('friendly name/alias on an account'), making it easy to understand. However, it does not explicitly differentiate from sibling tools like 'ai__account_rename' or 'ai__bridge_rename', which might have similar renaming functions, so it misses full sibling differentiation.

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

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

The description includes a usage guideline: 'Confirm (yes/no) before executing,' which implies a cautionary step for this mutation operation. However, it does not specify when to use this tool versus alternatives (e.g., other account modification tools), nor does it detail prerequisites or exclusions. The guidance is implied but incomplete.

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

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 mentions a confirmation step, which adds some context, but fails to disclose critical traits such as whether this is a destructive/mutative operation (implied by 'purchases'), authentication needs (only hinted via parameters), rate limits, error handling, or what the JSON return object contains. This is inadequate for a financial transaction tool.

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

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

The description is moderately concise but has structural issues: it repeats the first sentence verbatim, and includes parameter annotations in a non-standard format that could be confusing. While it's front-loaded with the main purpose, the repetition and informal @param/@return tags reduce clarity and efficiency.

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

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

Given the complexity of a financial purchase tool with 4 parameters, 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It lacks details on behavioral aspects, error cases, and doesn't fully explain parameters or return values, making it insufficient for safe and effective use.

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

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. It lists parameters with brief explanations (e.g., 'The api key allocated to your application'), but these add minimal semantic value beyond naming. Key details like parameter formats, constraints, or how to obtain values (e.g., 'account_fk from which to buy') are missing, leaving significant gaps.

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

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

The description clearly states the action ('Purchases a digital asset') and the resource ('from the account's FIAT balance'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'ai__account_sell' or 'ai__account_swap', which would require a 5.

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

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

The description includes a usage guideline ('Confirm (yes/no) before executing'), which provides implied context for when to use it (i.e., after confirmation). However, it lacks explicit guidance on when to use this tool versus alternatives like 'ai__account_buy_telco' or other purchase-related siblings, and doesn't mention prerequisites or exclusions.

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

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

Annotations are empty, so the description carries the full burden of behavioral disclosure. It mentions a confirmation step and that the tool performs a purchase (implying a write/mutation operation), but it lacks details on permissions, rate limits, error handling, or what the purchase entails (e.g., is it irreversible?). For a financial transaction tool with no annotations, this is insufficient, though it does add some context beyond basic purpose.

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

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

The description is somewhat redundant, repeating 'Purchases airtime by converting currency to minutes and seconds.' twice, which wastes space. It's front-loaded with the purpose, but the parameter explanations are listed in a block without clear structuring. Overall, it's moderately concise but could be improved by removing repetition and better organizing the information.

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

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

Given the complexity (financial transaction tool), empty annotations, 0% schema coverage, but presence of an output schema (which handles return values), the description is partially complete. It covers purpose, parameters, and a confirmation step, but lacks behavioral details like safety, permissions, or error handling. The output schema mitigates some gaps, but for a tool with no annotations, more context is needed to be fully adequate.

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

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. It provides parameter semantics for all 5 parameters (e.g., 'api_key: The api key allocated to your application', 'amount: The amount in currency, 2 decimals'), adding meaning not present in the schema. However, it doesn't explain relationships between parameters (e.g., how 'account_fk' relates to 'token') or provide examples beyond currency codes, so it's not a perfect 5.

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

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

The description clearly states the tool's purpose: 'Purchases airtime by converting currency to minutes and seconds.' This specifies the verb ('purchases'), resource ('airtime'), and mechanism ('converting currency to minutes and seconds'). However, it doesn't explicitly differentiate from sibling tools like 'ai__account_buy' or 'ai__account_charge', which might have overlapping financial transaction purposes, so it's not a perfect 5.

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

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

The description includes a usage guideline: 'Confirm (yes/no) before executing,' which implies a confirmation step is needed. However, it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., compared to 'ai__account_buy' or other telco-related tools), nor does it specify prerequisites or exclusions. This leaves usage context implied rather than clearly defined.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the need for user confirmation ('Confirm (yes/no) before executing'), authentication requirements ('The payer must present a valid PIN'), and that it's a transactional operation ('Charges the account'). However, it doesn't mention potential side effects like rate limits, idempotency, or error handling, 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.

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

The description is moderately concise but has redundancy: the first two sentences are nearly identical. The parameter list is clear but could be more integrated. It's front-loaded with the core purpose, but the structure feels slightly disjointed with repetitive lines and a separate param block.

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

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

Given the tool's complexity (financial transaction with 7 params, no annotations), the description does a decent job: it explains the purpose, key behavior (confirmation, PIN), and parameters. With an output schema present, it doesn't need to detail return values. However, it misses some context like error cases or idempotency, which would be helpful for a charge operation.

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

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. It lists all 7 parameters with brief explanations (e.g., 'The amount to charge'), adding meaning beyond the bare schema. However, explanations are minimal and don't cover details like formats, constraints, or relationships between parameters (e.g., how account_fk relates to account_address). This provides basic semantics but lacks depth.

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

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

The description clearly states the tool's purpose: 'Charges the account based on a presented QR-code or NFC card.' It specifies the verb ('charges') and resource ('account'), and distinguishes it from siblings like ai__account_pay or ai__account_send by focusing on QR/NFC-based charging. However, it doesn't explicitly differentiate from all payment-related siblings, keeping it at 4 rather than 5.

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

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

The description provides some usage context: 'Confirm (yes/no) before executing' and mentions the payer must present a valid PIN. It implies this is for QR/NFC transactions but doesn't explicitly state when to use this versus alternatives like ai__account_pay or ai__account_send, nor does it mention prerequisites or exclusions. This gives implied guidance but lacks explicit alternatives.

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

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 the tool returns information, implying it's a read-only operation, but doesn't disclose behavioral traits like authentication needs (though parameters hint at it), rate limits, or what 'detailed' entails. This is a significant gap for a tool with no annotation coverage.

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

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

The description is somewhat repetitive ('Returns detailed account information.' is duplicated) and includes param annotations that could be structured better. It's front-loaded with the purpose, but the repetition and inline param details reduce efficiency, though it's not overly verbose.

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

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

Given the tool has an output schema (implied by 'Has output schema: true'), the description doesn't need to explain return values. However, with no annotations, 3 parameters at 0% schema coverage, and complexity in sibling tools, the description adds some param semantics but lacks behavioral context, making it minimally adequate but with clear gaps.

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

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. It provides param annotations explaining each parameter's purpose and source (e.g., 'api_key: The api key allocated to your application'), adding meaningful context beyond the bare schema. However, it doesn't cover all potential semantics like format constraints, so it's not a perfect 5.

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

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

The description states the tool 'returns detailed account information and balances,' which provides a clear verb ('returns') and resource ('account information'). However, it doesn't differentiate from sibling tools like 'ai__account' or 'ai__accounts,' which likely serve similar purposes, making the purpose somewhat vague in context.

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

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

The description offers no guidance on when to use this tool versus alternatives. With many sibling tools related to accounts (e.g., 'ai__account', 'ai__accounts', 'ai__account_statement'), there's no indication of context or exclusions, leaving the agent without usage direction.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Performs a FIAT withdraw' which implies a financial transaction, but doesn't disclose critical behavioral traits like whether this is irreversible, what permissions are needed, potential fees, rate limits, or what happens if the FIAT balance is insufficient. The description is too sparse for a financial transaction tool.

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

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

The description is appropriately concise with the main purpose stated first. However, the parameter documentation uses @param/@return syntax which is redundant with the schema, and the overall structure could be more front-loaded with critical behavioral information. The sentences earn their place but could be more efficiently organized.

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

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

For a financial transaction tool with 4 parameters, 0% schema description coverage, no annotations, and an output schema (though not shown), the description is incomplete. It covers basic purpose and parameters but lacks critical context about transaction behavior, error conditions, security requirements, and relationship to sibling tools. The presence of an output schema helps, but doesn't compensate for the missing behavioral context.

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

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. It lists all 4 parameters with brief explanations, but these add minimal semantic value beyond the parameter names themselves. For example, 'api_key: The api key allocated to your application' doesn't explain format or where to obtain it. The parameter explanations are too basic to adequately document a financial transaction tool with 0% schema coverage.

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

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

The description clearly states the action ('Issues a Netfluid voucher') and resource ('Performs a FIAT withdraw'), with additional context about applicability ('Only applicable on FIAT balances'). It distinguishes from sibling tools like 'ai__account_merchant_voucher_redeem' by specifying the 'issue' action, but doesn't explicitly contrast with other financial tools like 'ai__withdraw' or 'ai__account_send'.

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

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

The description provides minimal usage guidance. It mentions 'Only applicable on FIAT balances' which gives some context, but doesn't specify when to use this tool versus alternatives like 'ai__withdraw' or 'ai__account_send', nor does it mention prerequisites or constraints beyond the FIAT balance requirement. No explicit when/when-not guidance is provided.

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

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

Annotations are empty, so the description carries the full burden. It mentions the tool performs a quote and returns specific data (merchant commission and amount charged), which provides basic behavioral context. However, it lacks details on potential side effects (e.g., if this quote is cached or affects limits), authentication requirements beyond parameters, rate limits, or error conditions. The description does not contradict annotations, but it is insufficient for a mutation-like operation with no annotation coverage.

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

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

The description is moderately concise but has structural issues. It repeats the purpose in two slightly different sentences ('Performs a quote to before issuing...' and 'STEP 1: Performs a quote...'), which is redundant. The parameter explanations are clear but could be more efficiently integrated. Overall, it conveys necessary information but with some verbosity and awkward phrasing.

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

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

Given the complexity (a financial quote operation with 4 parameters), no annotations, and an output schema present, the description is reasonably complete. It explains the purpose, parameters, and return value ('a json object' with commission and charged amount details). The output schema likely covers return structure, so the description doesn't need to elaborate further. However, it could improve by addressing behavioral aspects like idempotency or error handling.

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

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. It provides semantic meaning for all four parameters: api_key ('allocated to your application'), token ('wallet_api_token provided by /access/login'), account_fk ('from which to issue the voucher'), and amount ('to issue the voucher for in up to 2 decimals'). This adds crucial context beyond the bare schema types, though it could be more detailed (e.g., format examples or constraints).

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

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

The description clearly states the tool's purpose: 'Performs a quote to before issuing a Netfluid voucher as a merchant' and 'Returns the merchant commission as well as the amount charged to the customer.' This specifies the verb (quote), resource (Netfluid voucher), and outcome (commission and charged amount). It distinguishes from sibling 'ai__account_merchant_voucher_issue' by indicating this is a preliminary quote step rather than the actual issuance.

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

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

The description implies usage context through phrases like 'before issuing' and 'as a merchant,' suggesting this is a preparatory step for voucher issuance. However, it does not explicitly state when to use this tool versus alternatives like 'ai__account_merchant_voucher_issue' or other quote-related tools, nor does it mention prerequisites or exclusions beyond the parameters listed.

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

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. While 'redeems' implies a write/mutation operation, the description doesn't specify whether this is idempotent, what happens on duplicate redemption attempts, what permissions are required, or what side effects occur. The description mentions authentication parameters but doesn't explain their purpose or how to obtain them.

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

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

The description is reasonably concise with a clear purpose statement followed by parameter documentation. However, the structure could be improved by separating the purpose from parameter details more clearly. The @param/@return formatting is helpful but somewhat technical. The description earns its place but isn't optimally structured for quick scanning.

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

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

Given that this is a mutation tool with no annotations but with an output schema, the description provides adequate basic information. The parameter documentation is strong, but behavioral aspects are under-specified. The presence of an output schema means the description doesn't need to explain return values, but it should provide more context about the operation's effects and constraints.

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

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

With 0% schema description coverage, the description provides crucial parameter documentation that the schema lacks. Each parameter gets a clear explanation: api_key is 'allocated to your application', token comes from '/access/login', account_fk specifies 'into which to redeem', and voucher_code includes a helpful format example. This compensates well for the schema's lack of descriptions.

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

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

The description clearly states the verb 'redeems' and the resource 'Netfluid voucher', making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'ai__account_merchant_voucher_issue' or 'ai__account_merchant_voucher_quote', which appear to be related voucher operations.

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

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. With siblings like 'ai__account_merchant_voucher_issue' and 'ai__account_merchant_voucher_quote', there's no indication of when redemption is appropriate versus issuing or quoting vouchers. The description also doesn't mention prerequisites beyond the listed parameters.

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

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 adds context beyond basic functionality: it warns of costs, describes the asynchronous nature ('may take several seconds'), and notes the need for confirmation. This provides useful behavioral insights, though it could detail more about error handling or permissions.

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

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

The description is somewhat repetitive (first two sentences are similar) and could be more streamlined. It front-loads key information but includes redundant phrasing. Overall, it is moderately concise but has room for improvement in structure to eliminate waste.

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

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

Given the complexity of a minting operation with 5 parameters, no annotations, and an output schema present, the description provides basic context like costs and asynchronicity. However, it lacks details on prerequisites, error cases, or what the 'json object' return entails, making it adequate but with clear gaps for informed tool use.

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

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. It lists parameters with brief explanations (e.g., 'api_key: The api key allocated to your application'), but these are minimal and do not fully clarify semantics like format or constraints. For 5 parameters, this adds some value but is insufficient to bridge the coverage gap.

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

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

The description clearly states the verb 'mints' and the resource 'a new account of an account type into the wallet', making the purpose specific. However, it does not explicitly distinguish this tool from sibling tools like 'ai__account' or 'ai__account_types', which could provide context on account creation or types, though the action 'mint' is distinct.

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

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

The description includes a cautionary note to 'Confirm (yes/no) before executing' and mentions costs and asynchronous behavior, which implies usage context. However, it does not explicitly state when to use this tool versus alternatives like 'ai__account' or provide clear exclusions, leaving some ambiguity.

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

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

Annotations are empty, so the description carries the full burden. It mentions a confirmation step ('Confirm (yes/no) before executing'), which adds behavioral context beyond basic function. However, it lacks details on permissions, rate limits, or potential side effects (e.g., whether this overwrites an existing PIN). The description adds some value but is not fully transparent about behavioral traits.

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

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

The description is somewhat repetitive, starting with a sentence that is then repeated verbatim, which wastes space. The parameter explanations are clear but could be more integrated. It is front-loaded with the main purpose, but the repetition and lack of tight structure reduce efficiency, making it adequate but not optimal.

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

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

Given 5 parameters with 0% schema coverage and an output schema (indicated by '@return: a json object'), the description does well by explaining all parameters and the return type. However, it lacks details on error cases or the structure of the JSON response. For a tool with no annotations and complex inputs, it is mostly complete but could benefit from more behavioral or output context.

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

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. It provides semantic details for all parameters: 'api_key' (allocated to application), 'token' (from /access/login), 'address' (account address), 'pin' (5-digit numeric), and 'expire_date' (optional, with format and timezone). This adds meaningful context beyond the bare schema, though it could specify constraints like PIN length more explicitly (e.g., exactly 5 digits).

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

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

The description clearly states the tool's purpose: 'Assigns a PIN to an account for use by a QR-Code or NFC card.' It specifies the verb ('assigns'), resource ('account'), and context ('for use by QR-Code or NFC card'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'ai__access_wallet_pin_change', which might be a related PIN operation, so it doesn't reach the highest score.

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

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

The description includes a usage guideline: 'Confirm (yes/no) before executing,' which implies a confirmation step is needed. However, it does not specify when to use this tool versus alternatives (e.g., 'ai__access_wallet_pin_change' for changing an existing PIN) or provide explicit exclusions. The guidance is implied but not comprehensive, falling short of explicit alternatives or detailed context.

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

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

With no annotations, the description carries full burden. It discloses critical behavioral traits: the restriction is temporary, requires admin reversal, involves a confirmation step, and prevents fund exits. It also explains the 'lock' parameter's effect (system lock preventing customer removal). However, it doesn't mention authentication needs beyond parameters, rate limits, or error conditions.

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

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

The description is moderately concise but has structural issues: it repeats the first sentence verbatim, creating redundancy. The content is front-loaded with purpose and warnings, but the parameter explanations are somewhat terse. It could be more streamlined without losing essential information.

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

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

Given a mutation tool with no annotations, 4 parameters (3 required), 0% schema coverage, but with an output schema (returning JSON), the description does well. It covers purpose, warnings, parameters, and behavioral context. The output schema handles return values, so the description doesn't need to explain them. It's mostly complete for this complexity level.

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

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. It provides semantic meaning for all 4 parameters: 'api_key' as application key, 'token' as wallet API token from login, 'account_fk' as account identifier from accounts list, and 'lock' as system lock setting. This adds significant value beyond the bare schema, though it doesn't detail formats or constraints.

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

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

The description clearly states the tool's purpose: 'Temporarily restricts an account from performing any function that would result in funds exiting the account.' It specifies the action (restricts) and resource (account), but doesn't explicitly differentiate from siblings like 'ai__account_resume' or 'ai__account_unlock' beyond mentioning it's temporary and requires admin reversal.

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

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

The description provides clear usage context: 'Can only be undone by an administrator, warn before using! Confirm (yes/no) before executing.' This gives explicit warnings and prerequisites, though it doesn't directly compare to alternatives like 'ai__account_resume' for reversal or specify when to use this over other account management tools.

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

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 mentions the need for confirmation, which adds some context, but fails to describe critical traits such as whether this is a destructive operation, authentication requirements beyond parameters, rate limits, or error handling. For a financial transaction tool, this is a significant gap.

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

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

The description is front-loaded with the core purpose and a usage note, but it repeats the first sentence unnecessarily and includes parameter annotations in a verbose format. While not overly long, it could be more streamlined by eliminating redundancy and integrating parameter info more efficiently.

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

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

Given the tool's complexity (financial transaction with 5 parameters), no annotations, and an output schema (which reduces need to describe returns), the description is partially complete. It covers the basic action and parameters but lacks details on behavior, error cases, and sibling differentiation, making it minimally adequate but with clear gaps.

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

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 by explaining parameters. It lists each parameter with brief notes (e.g., 'The api key allocated to your application'), but these are minimal and don't add substantial meaning beyond the schema's type definitions. For 5 parameters with no schema descriptions, this is inadequate.

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

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

The description clearly states the action ('Charges') and resource ('the account a transaction fee'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'ai__account_charge' which might have similar functionality, preventing a perfect score.

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

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

The description includes a usage guideline ('Confirm (yes/no) before executing'), which provides implied context for when to use this tool. However, it lacks explicit guidance on when to choose this tool over alternatives like 'ai__account_charge' or prerequisites, leaving room for improvement.

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

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

With no annotations, the description carries full burden. It discloses that the action is irreversible (administrator-only undo) and requires confirmation, which are critical behavioral traits. However, it lacks details on permissions needed, rate limits, or error handling, leaving gaps for a mutation tool.

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

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

The description is front-loaded with key information but has redundancy (the first sentence is repeated verbatim). The parameter explanations are helpful, but the repetition wastes space. Overall, it's adequately sized but could be more efficient.

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

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

Given a mutation tool with no annotations, 0% schema coverage, and an output schema (implied by '@return'), the description does well: it explains purpose, irreversible nature, confirmation need, and parameter semantics. It covers essential context, though more behavioral details (e.g., auth requirements) would enhance completeness.

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

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. It adds meaningful semantics for all three parameters: 'api_key' as allocated to the application, 'token' as from /access/login, and 'account_fk' as from /wallet/accounts_list. This clarifies sources and purposes beyond basic schema types.

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

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

The description clearly states the verb ('Resumes') and resource ('full trading capability for an account'), specifying it applies to previously paused accounts. It distinguishes from siblings like 'ai__account_pause' by indicating the opposite action, though it doesn't explicitly mention all alternatives like 'ai__access_resume'.

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

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

The description provides clear context: use for resuming a paused account, with a warning about irreversibility ('Can only be undone by an administrator') and a confirmation prompt. It implies usage by distinguishing from pause operations but doesn't explicitly name when-not-to-use scenarios or all sibling alternatives.

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

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

Annotations are empty, so the description carries the burden. It mentions 'Provides tools to create and manage' and 'reference information,' implying it might be a meta-tool or informational, but doesn't disclose behavioral traits like permissions needed, side effects, or rate limits. The @return note adds some context about output format, but overall, it lacks details on how it behaves operationally beyond basic intent.

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

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

The description is brief with three sentences, but it's not well-structured or front-loaded. The first sentence is clear but vague, the second is confusing ('This tools provides reference information in the "referenced_tools" schema'), and the third is a technical note. It could be more concise and organized, with some sentences not earning their place due to awkward phrasing.

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

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

Given the complexity (managing wallet accounts), empty annotations, 0% schema coverage, but an output schema exists, the description is moderately complete. It hints at functionality and output format, but lacks details on behavior, error handling, or how it integrates with sibling tools. The output schema reduces the need to explain return values, but more context is needed for a tool with such a broad scope among many siblings.

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

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

Schema description coverage is 0%, but there's only one parameter (api_key). The description doesn't add specific meaning to this parameter, but with zero parameters being the baseline for a single required parameter, it's acceptable. However, it doesn't explain what the api_key is for or how it's used, so it doesn't fully compensate for the lack of schema descriptions, keeping it from a perfect score.

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

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

The description states 'Provides tools to create and manage wallet accounts,' which gives a general purpose but is vague about what specific actions it performs. It doesn't distinguish itself from sibling tools like 'ai__account' or 'ai__wallet_accounts_list,' making it unclear if this is a meta-tool, a management interface, or something else. The phrase 'Provides tools' is ambiguous rather than specifying a clear verb+resource combination.

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

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

There is no guidance on when to use this tool versus alternatives. With many sibling tools related to accounts and wallets (e.g., 'ai__account', 'ai__wallet_accounts_list'), the description fails to indicate if this is for high-level management, creation only, or reference purposes. The mention of 'reference information' hints at usage but doesn't provide explicit when/when-not instructions or alternatives.

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

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

Annotations are empty, so the description carries the full burden of behavioral disclosure. It mentions a confirmation step ('Confirm (yes/no) before executing'), which adds some context, but fails to disclose critical behavioral traits such as whether this is a destructive/mutative operation (implied by 'sells' but not stated), authentication needs (hinted by api_key and token parameters but not explained), rate limits, error handling, or what happens on execution. For a financial transaction tool with no annotations, this is a significant gap.

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

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

The description is moderately concise but has redundancy: the first sentence is repeated verbatim. It's front-loaded with the core purpose, but the parameter annotations are included inline, which adds length without strong structure. While not overly verbose, it could be more streamlined by removing repetition and better organizing information.

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

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

Given the complexity (a financial sell operation with 5 parameters), empty annotations, and an output schema exists (implied by '@return: a json object'), the description is incomplete. It lacks details on behavioral aspects like safety, authentication, and error handling, and while it mentions parameters, it doesn't fully explain them. The output schema might cover return values, but the description doesn't provide enough context for safe and effective use.

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

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 by explaining parameters. It lists parameters with brief annotations (e.g., '@param api_key: The api key allocated to your application'), which adds some semantics beyond the schema. However, it doesn't fully clarify the meaning or usage of all parameters (e.g., what 'account_fk' or 'digital_asset_fk' represent in practice, format of 'amount'), leaving gaps. With 5 parameters and low schema coverage, this is inadequate.

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

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

The description clearly states the tool's purpose: 'Sells a digital asset and returns the proceeds to the account's FIAT balance.' It specifies the verb ('sells'), resource ('digital asset'), and outcome ('returns proceeds to FIAT balance'), which is clear and specific. However, it doesn't explicitly differentiate from sibling tools like 'ai__account_buy' or 'ai__account_swap', which would be needed for a score of 5.

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

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

The description includes a usage guideline: 'Confirm (yes/no) before executing,' which implies a confirmation step is required. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'ai__account_buy' or 'ai__account_swap', nor does it mention prerequisites or exclusions. This leaves usage context partially implied but incomplete.

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

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

Annotations are empty, so the description carries the full burden. It discloses key behavioral traits: it's a send operation (implies mutation), includes currency conversion ('The FIAT sent is converted to the destination account's currency'), and cross-wallet capability ('This function can send FIAT across wallets'). However, it doesn't cover critical aspects like authentication needs (though params hint at it), rate limits, error conditions, or irreversible effects. With no annotations, this is a moderate disclosure.

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

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

The description is verbose and repetitive, with redundant sentences like 'Sends FIAT from this account to another Netfluid account. Optionally save as a beneficiary. Confirm (yes/no) before executing' followed by a similar line. The param explanations are thorough but could be more streamlined. It's front-loaded with purpose but wastes space on repetition, reducing efficiency.

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

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

Given the complexity (8 parameters, no annotations, but has output schema), the description is mostly complete. It explains the tool's purpose, parameters, and key behaviors like currency conversion. The output schema exists, so return values don't need explanation. However, it lacks details on error handling, security implications, or integration with sibling tools, leaving minor gaps.

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

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 fully. It provides detailed parameter semantics for all 8 parameters, explaining each one's purpose (e.g., 'api_key: The api key allocated to your application', 'destination: The destination's internal account address (not it's crypto address, not it's account id)'). This adds significant meaning beyond the bare schema, fully documenting the parameters.

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

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

The description clearly states the tool's purpose: 'Sends FIAT from this account to another Netfluid account' and 'Sends FIAT from this account to an account address.' It specifies the resource (FIAT) and action (send), though it repeats this information. It doesn't explicitly differentiate from sibling tools like 'ai__account_wire' or 'ai__account_pay', which might have similar functions, so it doesn't reach a 5.

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

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

The description includes some usage guidance: 'Optionally save as a beneficiary' and 'Confirm (yes/no) before executing,' which implies procedural steps. However, it doesn't specify when to use this tool over alternatives like 'ai__account_wire' or 'ai__account_pay' from the sibling list, nor does it mention prerequisites or exclusions. This provides implied context but lacks explicit alternatives.

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

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 behaviors: it's a transactional tool that charges the account, has geographic limitations (South Africa, Botswana, Zimbabwe, UK), non-guaranteed delivery, and per-submission/per-character charging. This covers critical operational aspects, though it could mention error handling or rate limits.

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

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

The description is somewhat repetitive ('Sends a Mobile SMS...' appears twice) and could be more streamlined. However, it's front-loaded with key information and uses a structured @param/@return format that aids readability. Some sentences could be combined for better flow, but overall it's adequately concise.

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

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

Given the tool's transactional nature (sending SMS with financial charges), no annotations, and 0% schema coverage, the description does a good job covering purpose, parameters, behavioral traits, and output format (@return). The presence of an output schema reduces the need to detail return values. It could be more complete by mentioning error cases or authentication requirements beyond the parameters.

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

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

With 0% schema description coverage, the description fully compensates by providing detailed semantic explanations for all 5 parameters. Each @param annotation clearly explains the purpose, format requirements (e.g., 'e164 international format (no +)', 'charged per 160 characters'), and source context (e.g., 'provided by /access/login'), adding significant value beyond the bare schema.

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

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

The description clearly states the tool 'sends a Mobile SMS and charges this account' with specific verb (send) and resource (SMS), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'ai__account_send' or 'ai__text_message', which might have overlapping functionality, so it doesn't reach the highest score.

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

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

The description provides some context with 'Confirm (yes/no) before executing' and lists destination countries and charging details, which implies usage scenarios. However, it lacks explicit guidance on when to use this tool versus alternatives like 'ai__account_send' or 'ai__text_message', and doesn't specify prerequisites or exclusions beyond the listed destinations.

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

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 describes the tool as a read operation ('Returns'), which implies it's non-destructive. It provides useful context about default behaviors (1000 entries if max_rows not provided, 60 days of data if start_date not provided, GMT timezone). However, it doesn't mention authentication requirements beyond the parameters, rate limits, error conditions, or what happens with invalid dates/parameters.

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

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

The description is reasonably concise with two purpose statements followed by parameter documentation. However, there's some redundancy (the purpose is stated twice in slightly different ways) and the structure could be improved by separating the high-level description from parameter details more clearly. The @param/@return format is helpful but could be more efficiently organized.

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

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

Given the tool has 5 required parameters with 0% schema description coverage, the description does an excellent job of documenting parameter semantics. The presence of an output schema means the description doesn't need to explain return values. However, for a financial data retrieval tool, the description could provide more context about what constitutes a 'detailed account statement' - whether it includes transactions, balances, fees, etc.

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

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

With 0% schema description coverage, the description must fully compensate for the lack of parameter documentation in the schema. It successfully documents all 5 parameters with clear explanations of their purpose, sources, defaults, and formats. The @param annotations provide specific details about where to obtain values (e.g., 'provided by /access/login', 'provided by /wallet/accounts_list') and format requirements ('YYYY-MM-DD HH:MM:SS'). This adds significant value beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Returns detailed account FIAT statement' and 'Returns detailed account statement from a start date for a maximum of entries.' It specifies the resource (account statement) and scope (FIAT, date range, entry limit). However, it doesn't explicitly differentiate from sibling tools like 'ai__account' or 'ai__account_info' which might provide different account-related information.

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

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. With many sibling tools like 'ai__account', 'ai__account_info', and 'ai__accounts', there's no indication of what makes this tool unique or when it should be preferred over other account-related tools. The description only explains what the tool does, not when to use it.

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

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 hints at a confirmation step, implying user interaction or safety checks, but fails to detail critical aspects like whether this is a destructive/write operation (implied by 'swaps'), rate limits, error handling, or what the 'json object' return entails. This leaves significant gaps in understanding the tool's behavior.

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

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

The description is moderately concise but has structural issues: it repeats the opening sentence unnecessarily and mixes usage notes with parameter documentation in a somewhat cluttered format. While it avoids excessive verbosity, the repetition and lack of clear separation between purpose and details reduce its effectiveness.

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

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

Given the tool's complexity (7 parameters, no annotations, but with an output schema), the description is partially complete. It covers the basic purpose and parameters but misses critical context like authentication flow (linking to 'ai__access_login' for the 'token'), error cases, and sibling tool differentiation. The output schema existence means return values are documented elsewhere, but overall completeness is limited.

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

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. It lists all 7 parameters with brief explanations (e.g., 'api_key: The api key allocated to your application'), adding basic semantics beyond the schema. However, it lacks details on parameter formats, constraints (e.g., valid ranges for 'amount'), or the meaning of 'fk' suffixes, resulting in partial but incomplete parameter guidance.

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

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

The description clearly states the verb 'swaps' and the resource 'digital asset for another on an account level', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'ai__crypto_swap' or 'ai__account_sell', which appear related to asset exchanges, leaving room for ambiguity in tool selection.

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

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

The description provides minimal usage guidance, only mentioning a confirmation step ('Confirm (yes/no) before executing') and a note about using 'digital_asset_fk=0' for FIAT. It lacks explicit when-to-use scenarios, prerequisites (e.g., authentication context from sibling tools like 'ai__access_login'), or alternatives among the many sibling tools, offering insufficient direction for optimal tool selection.

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

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

Annotations are empty, so the description carries full burden. It mentions 'typically static information' which hints at read-only behavior and infrequent changes, but doesn't explicitly state if it's safe, requires authentication, has rate limits, or what happens on errors. For a tool with no annotations, this leaves significant behavioral gaps.

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

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

The description is poorly structured with redundant lines ('Lists all account types' appears twice) and mixes purpose with parameter documentation in an informal format. It's not front-loaded effectively, and the repetition wastes space without adding value.

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

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

Given the tool has an output schema (which covers return values), 1 parameter with 0% schema coverage (partially compensated in description), and no annotations, the description is minimally adequate. It states the purpose and documents the key parameter, but lacks behavioral details and usage context that would be helpful for an AI agent.

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

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

Schema description coverage is 0%, but the description documents one parameter (@param api_key: The api key allocated to your application) which adds meaning beyond the schema's type-only definition. However, it doesn't explain format, sourcing, or security implications. With 1 parameter and partial documentation, this meets the baseline for minimal viability.

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

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

The description states 'Lists all account types, typically static information' which provides a clear verb ('Lists') and resource ('account types'), but it's somewhat vague about what 'account types' specifically refers to in this context. The repetition of 'Lists all account types' adds no value and slightly reduces clarity. It distinguishes from many siblings (e.g., ai__account, ai__accounts) but not from similar list tools like ai__currency_types.

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

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's no mention of prerequisites (e.g., authentication context), comparison to other account-related tools (e.g., ai__account, ai__accounts), or typical use cases. The description only states what it does, not when it should be used.

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

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

With no annotations, the description carries full burden. It implies a state-changing operation ('Unlocks'), which suggests mutation, but doesn't disclose permissions beyond admin privileges for api_key, rate limits, or side effects. The confirmation hint adds some behavioral context, but lacks details on what 'unlocking' entails operationally.

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

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

The description is somewhat repetitive ('Unlocks a locked account' appears twice) and includes param annotations in the main text, which could be structured better. However, it's front-loaded with the core purpose and confirmation requirement, with param details following logically.

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

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

For a mutation tool with no annotations, 0% schema coverage, but with output schema, the description does well: it explains the purpose, provides usage guidance, and documents all parameters thoroughly. The output schema handles return values, so the description focuses appropriately on inputs and behavior.

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

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. It provides detailed semantics for all 3 parameters: api_key requires 'admin privileges', token comes from '/access/login', and account_fk is 'provided by /wallet/accounts_list'. This adds significant value beyond the bare schema types.

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

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

The description clearly states the verb ('Unlocks') and resource ('a locked account'), with specific status transition details ('from status_fk=10 to status_fk=1'). It distinguishes from siblings like ai__account_pause or ai__account_resume by focusing on unlocking, but doesn't explicitly contrast with all account status tools.

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

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

The description provides clear context for usage: 'Confirm (yes/no) before executing' indicates a prerequisite confirmation step. It doesn't explicitly state when not to use or name alternatives among siblings, but the confirmation requirement offers practical guidance.

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

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 useful context: the warning to confirm before executing implies a destructive or irreversible action, and it notes system conversion for FIAT and blockchain association requirements. However, it doesn't cover other critical traits like authentication needs (implied by api_key and token but not explained), rate limits, error handling, or what 'json object' return entails. This leaves gaps for a mutation tool.

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

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

The description is moderately concise but has redundancy: the first sentence is repeated verbatim. It front-loads the core purpose but includes param listings that could be more integrated. The structure is functional but not optimized, with some wasted space from repetition and a loose organization of notes and parameters.

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

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

Given the tool's complexity (a mutation with 7 params, no annotations, but an output schema exists), the description is partially complete. It covers the basic operation and parameters but misses key contextual details: no sibling tool differentiation, incomplete behavioral traits, and minimal param semantics. The output schema mitigates the need to explain return values, but overall, it's adequate only for minimal understanding with clear gaps.

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

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 fully for parameter documentation. It lists all 7 parameters with brief explanations (e.g., 'digital_asset_fk: The digital_asset_fk to wire, use 0 for FIAT'), which adds meaning beyond the bare schema. However, the explanations are minimal and lack details on formats, constraints, or examples (e.g., what 'account_fk' represents, valid ranges for 'amount'). Given the low schema coverage, this is insufficient to fully guide usage.

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

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

The description clearly states the tool's purpose: 'Sends FIAT or Digital Assets from this account to a blockchain address.' It specifies the verb ('Sends'), resource ('FIAT or Digital Assets'), and destination ('blockchain address'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'ai__account_send' or 'ai__withdraw', which may have overlapping functionality, preventing a perfect score.

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

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

The description provides some implied usage guidance: it mentions that 'FIAT is converted by the system' and includes a prerequisite that 'The FIAT account must be associated to the same blockchain as the destination address.' It also has a warning 'Confirm (yes/no) before executing,' which hints at caution. However, it lacks explicit when-to-use vs. alternatives (e.g., compared to 'ai__account_send' or 'ai__withdraw'), and no exclusions are stated, making it only moderately helpful.

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

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 mentions the return type ('a json object containing the schema'), which adds some context about output format. However, it doesn't cover other behavioral aspects like whether it's read-only (implied by 'returns'), performance characteristics, error handling, or authentication needs. The description adds basic value but leaves gaps for a tool with zero annotation coverage.

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

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

The description is relatively concise, consisting of two sentences that cover the purpose and output. It's front-loaded with the main function. However, the second sentence is somewhat redundant with the first and could be more streamlined (e.g., by integrating the return info into the initial statement), and there's minor grammatical awkwardness ('This tools provides').

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

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

Given the tool's complexity is low (0 parameters, output schema exists), the description is fairly complete. It explains what the tool does and hints at the output structure. With an output schema present, it doesn't need to detail return values extensively. However, for a reference tool in a large set of siblings, it could benefit from more explicit differentiation or usage context to fully guide an agent.

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

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

The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it doesn't contradict the schema. Since there are no parameters, the baseline is 4, as the description appropriately doesn't waste space on non-existent inputs.

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

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

The description clearly states the tool's purpose: 'Returns a list of tools that work with bridges, off-ramps, on-ramps, cross-blockchain transfers, virtual accounts.' It specifies the verb ('returns') and resource ('list of tools'), making the function clear. However, it doesn't explicitly differentiate from sibling tools like 'ai__bridges', 'ai__off_ramps', or 'ai__on_ramps', which appear to be more specific implementations rather than reference tools.

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

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

The description implies usage by stating it 'provides reference information in the "referenced_tools" schema,' suggesting it should be used for looking up related tools. However, it lacks explicit guidance on when to use this tool versus alternatives like the specific bridge/ramp tools listed as siblings, or prerequisites such as needing certain permissions or contexts. The implication is there but not clearly articulated.

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

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

Annotations are empty, so the description carries the full burden. It mentions parameters like api_key and token, implying authentication needs, but doesn't disclose behavioral traits such as rate limits, response formats beyond 'a json object', error handling, or whether it's read-only or mutative. The description is minimal and lacks crucial operational details needed for safe and effective use.

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

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

The description is front-loaded with the purpose, followed by param explanations. However, it includes redundant information (e.g., repeating '@param' and '@return' tags that might be structured elsewhere) and lacks efficient structuring. Sentences are minimal but could be more polished; it's concise but not optimally structured for clarity.

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

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

Given the complexity (4 parameters, no annotations, 0% schema coverage, but has output schema), the description is partially complete. It explains parameters but misses behavioral context like authentication flow, error cases, or usage scenarios. The output schema exists, so return values don't need explanation, but overall, it's adequate with clear gaps in operational guidance.

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

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. It adds meaning by explaining each parameter: api_key is 'allocated to your application', token and wallet_fk are 'provided by /access/login', and prompt is 'the string prompt'. This clarifies the source and purpose of parameters beyond their types, though it doesn't detail formats or constraints. With 0% schema coverage, this is good but not exhaustive.

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

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

The description states 'Performs a Gemini AI prompt' which indicates the tool sends a prompt to Gemini AI. This is a clear verb+resource combination, but it's somewhat vague about what 'performs' entails (e.g., is it a simple query, a complex interaction, or something else?). It doesn't distinguish from sibling tools like 'ai__about' or 'ai__help_ping' which might also involve AI interactions, so it lacks sibling differentiation.

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

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. With many sibling tools available (e.g., 'ai__about', 'ai__help_ping'), there's no indication of whether this is for general AI queries, specific Gemini interactions, or other contexts. It mentions parameters like api_key and token but doesn't explain prerequisites or when this tool is appropriate compared to others.

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

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

With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses that the process creates a Solana wallet, grants access to virtual bank accounts, involves legal responsibility transfer to a human, and takes up to 30 seconds. It also implies this is a write/mutation operation (signup). However, it doesn't mention error conditions, rate limits, or authentication requirements beyond the parameters.

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

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

The description is poorly structured and repetitive: the first 8 lines are duplicated verbatim, wasting space. It's front-loaded with purpose but includes redundant sentences. The parameter documentation is thorough but could be more efficiently organized. Overall, it lacks conciseness due to duplication and could be streamlined.

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

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

Given the tool's complexity (7 parameters, mutation operation, financial/legal implications) and no annotations, the description does a good job: it explains purpose, prerequisites, outcomes, timing, and detailed parameter semantics. With an output schema present ('@return: a json object'), it doesn't need to explain return values. However, it could better address error handling or security considerations.

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

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 fully. It provides detailed semantic explanations for all 7 parameters: format requirements (e.g., 'e164 format'), examples ('27821234567'), defaults ('use 7 (ZAR)'), usage guidance ('if not available use a blank string'), and suggestions ('Generate 3 natural language words'). This adds substantial meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Automated signup for autonomous agents' to create a wallet that enables autonomous payments. It specifies the resource (wallet) and outcome (autonomous transactions with bank/blockchain access). However, it doesn't explicitly distinguish this from sibling tools like 'ai__signup' or 'ai__automated_signup' (which appears to be a duplicate name), missing full sibling differentiation.

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

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

The description implies when to use this tool: for setting up autonomous agent wallets, with prerequisites (human KYCed wallet as sponsor). It mentions the outcome ('fully enabled to perform any transaction') but doesn't explicitly state when NOT to use it or name alternatives among the many sibling tools (e.g., vs. regular 'ai__signup'), leaving usage context somewhat implied rather than explicit.

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

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

The description adds valuable behavioral context beyond the empty annotations. It discloses that the 'Process can take up to 30 seconds' (performance expectation) and instructs to 'direct the human customer to the kyc url for them to complete the identity verification process' (post-signup workflow). However, it doesn't mention error handling, authentication requirements, or rate limits.

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

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

The description is somewhat repetitive ('Automated signup for new customers' appears twice) and could be more efficiently structured. However, it's appropriately sized for a complex signup tool with multiple parameters and workflow instructions. The parameter explanations are well-organized but the initial paragraph could be more concise.

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

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, signup workflow), the description provides good context: purpose, usage guidelines, behavioral expectations, and detailed parameter semantics. With an output schema present, it doesn't need to explain return values. The main gap is lack of error handling or edge case information, but overall it's quite complete for its purpose.

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

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

With 0% schema description coverage, the description fully compensates by providing detailed semantic information for all 5 parameters. Each parameter includes practical guidance: 'secret' explains uniqueness requirements and suggests generation methods, 'pin' suggests meaningful numbers, 'mobile' specifies e164 format, and 'currency_fk' provides logic for South African vs. other users. This adds significant value beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Automated signup for new customers' with the specific action of signing up human customers. It distinguishes itself from sibling tools like 'ai__signup' by being the 'preferred method' for automated signups, indicating a specialized use case.

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

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

The description provides explicit usage guidelines: 'AI should use this tool as the preferred method to signup human customers.' It also specifies when to use an alternative tool: 'Should the human need more tries at identity verification, call wallet_kyc_session_create.' This gives clear direction on when to use this tool versus others.

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

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 indicates the tool provides reference information and returns a JSON object, which suggests a read-only, non-destructive operation. However, it doesn't detail aspects like response structure, error handling, or any constraints (e.g., rate limits or authentication needs), leaving gaps in behavioral understanding.

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

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

The description is repetitive, with the first two sentences being nearly identical ('Provides reference information...'), which adds no value. The third sentence about the 'referenced_tools' schema and return type is useful but could be integrated more efficiently. Overall, it's somewhat concise but suffers from redundancy and could be better structured.

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

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

Given the tool's low complexity (0 parameters, no annotations) and the presence of an output schema (which handles return values), the description is minimally adequate. It explains the tool's purpose and output format, but lacks details on usage context or behavioral traits, making it incomplete for optimal agent guidance despite the structured support.

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

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

The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add any parameter-specific information, which is appropriate here. Since there are no parameters, the baseline score is 4, as the description doesn't need to compensate for missing schema details.

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

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

The description states the tool 'provides reference information on the term "beneficiary" or "beneficiaries"', which clarifies its purpose as an informational lookup tool. However, it doesn't differentiate itself from similar reference tools like 'ai__about' or 'ai__terms', nor does it specify the scope or format of the reference information beyond mentioning it's in the 'referenced_tools' schema, making it somewhat vague.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any specific contexts, prerequisites, or exclusions, such as when to choose this over 'ai__beneficiaries_list' or other informational tools. This lack of usage context leaves the agent without clear direction.

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

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

Annotations are empty, so the description carries the full burden. It states the tool lists beneficiaries, implying a read-only operation, but does not disclose behavioral traits such as authentication requirements (beyond parameter descriptions), rate limits, pagination, or error handling. The mention of '@return: a json object' is minimal and does not elaborate on response structure or potential outcomes.

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

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

The description is poorly structured, with redundant repetition of the first sentence and parameter details embedded in a comment-like format. It is not front-loaded effectively, and the inclusion of '@return: a json object' adds little value given the presence of an output schema. The text could be more streamlined and organized.

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

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

Given the complexity of a 4-parameter tool with no annotations, the description provides basic purpose and parameter semantics but lacks behavioral context. The output schema exists, so explaining return values is unnecessary, but gaps remain in usage guidelines and transparency. It is minimally adequate but has clear room for improvement.

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

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. It provides detailed semantics for all four parameters (api_key, token, wallet_fk, account_fk), explaining their purposes, sources (e.g., '/access/login'), and special cases (e.g., account_fk=0 returns all wallet beneficiaries). This adds significant value beyond the bare schema, though it could be more structured.

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

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

The description states the tool 'Lists all beneficiaries on this wallet or on this account', which provides a clear verb ('Lists') and resource ('beneficiaries'). However, it does not distinguish this from sibling tools like 'ai__beneficiaries' or 'ai__beneficiary_add', making the purpose somewhat vague in context. The repetition of the same sentence adds no clarity.

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

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

The description includes no explicit guidance on when to use this tool versus alternatives. It mentions that 'account_fk' can be set to 0 to list all wallet beneficiaries, but this is parameter-specific and does not provide broader usage context or comparisons to sibling tools like 'ai__beneficiaries' or 'ai__beneficiary_add'.

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

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

With no annotations provided, the description carries the full burden. It indicates this is a creation/mutation operation ('Creates'), implying it modifies data, but doesn't disclose behavioral traits like authentication requirements (beyond parameter hints), rate limits, side effects, or error handling. The description adds minimal context beyond the 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.

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

The description is front-loaded with the purpose, but it repeats the first sentence unnecessarily ('Creates a beneficiary on this wallet or on this account' appears twice). The parameter explanations are thorough but could be more streamlined. Overall, it's adequately structured but not optimally concise.

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

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

Given the complexity (8 required parameters, 0% schema coverage, no annotations), the description does a good job explaining parameters and the basic action. However, it lacks behavioral context (e.g., permissions, errors) and doesn't leverage the output schema (which exists but isn't referenced). For a mutation tool with no annotations, it's reasonably complete but could be enhanced.

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

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

Schema description coverage is 0%, so the description must fully compensate. It provides detailed semantic explanations for all 8 parameters, including their purposes, sources (e.g., 'provided by /access/login'), constraints (e.g., 'may not be 0'), and relationships (e.g., 'set to 0 if either name or address is provided'). This adds significant value beyond the bare schema.

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

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

The description clearly states the action ('Creates a beneficiary') and the target ('on this wallet or on this account'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'ai__beneficiaries' or 'ai__beneficiary_remove', which would be needed for a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing authentication via other tools first) or compare it to related sibling tools like 'ai__beneficiaries_list' or 'ai__beneficiary_remove', leaving the agent without context for tool selection.

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

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

With no annotations provided, the description must fully disclose behavioral traits. It states the tool deletes a beneficiary (implying a destructive operation) but doesn't mention permissions required, whether deletion is reversible, or any side effects. The contradictory second sentence about creating beneficiaries adds confusion rather than clarity. No rate limits, authentication details beyond parameters, or error handling are described.

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

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

The description is poorly structured and not front-loaded. The first sentence states deletion, but the second contradicts it with creation, wasting space and confusing the reader. The param annotations are useful but could be integrated more smoothly. Overall, it lacks efficiency and clarity in presentation.

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

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

Given 4 parameters with 0% schema coverage and no annotations, the description partially compensates with param semantics but fails to provide a clear, consistent purpose or behavioral context. The output schema exists (implied by '@return: a json object'), so return values needn't be detailed, but the core functionality is muddled by the contradiction, leaving gaps in understanding the tool's role.

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

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. It provides param annotations for all four parameters (api_key, token, account_fk, beneficiary_id) with brief explanations of their purposes and sources (e.g., 'provided by /access/login' for token). This adds meaningful context beyond the bare schema, though some details like format expectations or example values are missing.

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

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

The description starts with 'Deletes a beneficiary' which clearly states the action and resource, but then immediately contradicts itself with 'Creates a beneficiary on this wallet or on this account' in the next sentence. This creates confusion about whether the tool deletes or creates beneficiaries, making the purpose unclear and somewhat misleading despite having a specific verb+resource initially.

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

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. There are sibling tools like 'ai__beneficiaries', 'ai__beneficiaries_list', and 'ai__beneficiary_add' that likely handle listing and adding beneficiaries, but the description doesn't mention these or specify when deletion is appropriate versus other operations.

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

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

With no annotations, the description carries full burden. It discloses the critical behavioral trait that sending non-USDC tokens 'may be lost' (destructive risk) and mentions the confirmation requirement. However, it doesn't cover other important behaviors like whether this is an irreversible operation, what permissions are needed, rate limits, or what happens after bridge creation.

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

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

The description is reasonably concise but has structural issues. The first sentence is repeated verbatim, creating redundancy. The parameter documentation is well-structured with @param tags, but the overall flow could be improved by eliminating the repetition and better integrating the warnings with the main description.

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

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

Given the tool's complexity (blockchain bridge creation with 8 parameters), no annotations, and an output schema present (so return values don't need description), the description does a good job. It covers the core purpose, critical warnings, parameter meanings, and confirmation requirement. The main gap is lack of behavioral details about the bridge creation process itself.

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

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

With 0% schema description coverage, the description provides valuable parameter semantics beyond the bare schema. It explains what each parameter represents (e.g., 'api_key: The api key allocated to your application'), lists possible values for 'blockchain' and 'currency', and clarifies that 'alias' is optional with async default. This significantly compensates for the schema's lack of descriptions.

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

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

The description clearly states the tool 'creates a blockchain to blockchain bridge' with the specific purpose of enabling USDC transfers between blockchains. It distinguishes from siblings like 'bridge_list' or 'bridge_delete' by focusing on creation, but doesn't explicitly contrast with other bridge-related tools like 'bridge_on_ramp' or 'bridge_off_ramp_ach_wire'.

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

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

The description provides explicit guidance to 'Confirm (yes/no) before executing' and warns 'Only supports USDC transfers. Do not send any other tokens as these may be lost.' This gives clear when-to-use context (USDC transfers only) and risk warnings, though it doesn't specify alternatives for non-USDC transfers or compare with other bridge tools.

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

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

With no annotations provided, the description carries full burden. It states 'Deactivates the Bridge' which implies a destructive/mutative operation, but doesn't clarify if this is reversible, what permissions are needed, or any rate limits. The confirmation requirement is helpful but insufficient for a mutation tool with zero annotation coverage.

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

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

The description is reasonably concise but has structural issues - the first line repeats 'Deactivates the Bridge' unnecessarily. The parameter documentation is helpful but could be better integrated. Overall efficient but with some redundancy.

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

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

For a mutation tool with no annotations, 4 parameters at 0% schema coverage, but with output schema present, the description covers parameters well but lacks behavioral context. The confirmation guidance helps, but more details about the mutation's effects would improve completeness.

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

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

With 0% schema description coverage for 4 parameters, the description compensates well by documenting all parameters with source information (e.g., 'found on /bridge/list' for external_account_id). This adds significant value beyond the bare schema, though some parameter purposes could be clearer.

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

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

The description states 'Deactivates the Bridge' which provides a clear verb+resource, but it's repetitive and doesn't differentiate from sibling tools like 'ai__bridge_list' or 'ai__bridge_rename'. The purpose is understandable but lacks specificity about what 'Bridge' refers to in this context.

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

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

The description includes 'Confirm (yes/no) before executing' which provides some procedural guidance, but it doesn't explain when to use this tool versus alternatives or what prerequisites exist. No explicit when/when-not instructions or sibling tool comparisons are provided.

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

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 describes what a bridge is and the transfer_type parameter, but doesn't reveal whether this is a read-only operation, what authentication levels are needed, potential rate limits, error conditions, or pagination behavior. The description adds some context about bridge types but misses key behavioral traits for a tool with 5 required parameters.

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

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

The description is repetitive and poorly structured. It repeats 'Returns bridges based on the transfer_type' and the bridge definitions, and includes redundant @param/@return annotations that belong in schema documentation. The content could be condensed to 2-3 clear sentences without losing meaning, making it inefficient rather than concise.

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

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

Given the tool's moderate complexity (5 parameters, no annotations, but has output schema), the description is partially complete. It explains the core concept of bridges and transfer_type values well, and the output schema existence means return values don't need description. However, it lacks sufficient parameter explanations and behavioral context, making it adequate but with clear gaps for proper tool invocation.

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

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. It provides detailed explanations for transfer_type (defining possible values and their meanings) and mentions account_fk context, but doesn't explain api_key, token, or wallet_fk parameters beyond their names. With 5 parameters and only 1-2 adequately described, the description doesn't sufficiently compensate for the schema's lack of descriptions.

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

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

The description clearly states the tool's purpose: 'Returns bridges based on the transfer_type' with specific definitions of what a bridge is (on-ramp, off-ramp, blockchain). It distinguishes the tool's function from siblings like ai__bridge_on_ramp or ai__bridge_off_ramp_sepa by focusing on listing bridges by type rather than creating or managing them. However, it doesn't explicitly differentiate from ai__bridges (which might list all bridges without filtering).

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

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

The description implies usage context by stating 'Bridges are only available on blockchain accounts' and listing transfer_type values, suggesting when to use this tool for specific bridge types. However, it lacks explicit guidance on when to choose this over sibling tools like ai__bridges or ai__bridge_on_ramp, and doesn't mention prerequisites or exclusions beyond the account_fk requirement.

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

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 mentions the confirmation requirement, which is useful, but lacks critical details: it doesn't specify whether this is a destructive/write operation (implied by 'creates'), what permissions or authentication levels are needed beyond the listed parameters, rate limits, or what happens on failure. The description adds minimal behavioral context beyond the 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.

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

The description is poorly structured and redundant: the first two sentences are nearly identical, and the parameter documentation is lengthy but necessary due to 0% schema coverage. It's not front-loaded effectively, and the repetition wastes space, reducing overall efficiency despite the essential parameter details.

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

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

Given the high complexity (16 parameters, 0% schema coverage, no annotations) and the presence of an output schema (indicated by @return), the description is mostly complete. It thoroughly documents all parameters and their semantics, which is critical. However, it lacks behavioral details like error handling or side effects, and the output schema's existence means return values don't need explanation, but more context on the tool's operation would improve completeness.

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

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

The schema description coverage is 0%, so the description must fully compensate. It provides detailed parameter semantics for all 16 parameters, including descriptions, possible values, defaults, and applicability conditions (e.g., 'Only applicable when destination_rail = "wire"'). This adds significant meaning beyond the bare schema, fully documenting the inputs.

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

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

The description clearly states the tool's purpose: 'Creates a blockchain to FIAT off-ramp in the USA supporting both ACH/WIRE bank networks.' It specifies the action (creates), resource (off-ramp), and geographic scope (USA). However, it doesn't explicitly differentiate from sibling tools like 'bridge_off_ramp_sepa' or 'bridge_on_ramp', which would be needed for a perfect score.

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

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

The description includes a usage guideline: 'Confirm (yes/no) before executing,' which provides some context about when to use it (after confirmation). However, it doesn't specify when to use this tool versus alternatives like 'bridge_off_ramp_sepa' for SEPA networks or 'withdraw_to_bank' for withdrawals, leaving gaps in sibling differentiation.

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

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 mentions a confirmation step ('Confirm (yes/no) before executing'), which hints at a safety measure, but doesn't disclose critical behavioral traits: whether this is a mutating operation (likely yes, given 'creates'), what permissions are needed, potential side effects, rate limits, or what the return JSON contains. For a creation tool with 19 parameters and no annotation coverage, this is inadequate.

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

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

The description is front-loaded with the core purpose and a confirmation note, but it's verbose due to the extensive parameter documentation. While the parameter details are necessary given the schema gap, the overall structure could be improved by separating usage guidelines from parameter semantics more clearly. Some repetition exists (the purpose is stated twice). It's appropriately sized for the complexity but not optimally structured.

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

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

Given the high complexity (19 parameters, creation operation), no annotations, and an output schema (true), the description is partially complete. It excels in parameter semantics but lacks behavioral transparency, usage guidelines, and sibling differentiation. The output schema handles return values, so that's covered. However, for a tool that likely involves financial transactions and mutations, more context on safety, errors, and operational constraints is needed.

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

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 fully. It provides detailed parameter documentation for all 19 parameters, including purpose, examples (e.g., 'examples BEL for Belgium'), conditional logic (e.g., 'If type of entity is and "individual", provide...'), and defaults (e.g., 'set by async default if none is provided'). This adds substantial meaning beyond the bare schema, fully addressing the coverage gap.

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

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

The description clearly states the tool's purpose: 'Creates a blockchain (USDC) to FIAT off-ramp in Europe for SEPA supporting bank accounts.' It specifies the action (creates), resource (off-ramp), and geographic/technical scope (Europe, SEPA, USDC to FIAT). However, it doesn't explicitly differentiate from sibling tools like 'ai__bridge_off_ramp_ach_wire' or 'ai__bridge_on_ramp', which would be needed for a perfect score.

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

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

The description includes a usage note: 'Confirm (yes/no) before executing,' which provides some procedural guidance. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., other off-ramp tools like 'ai__bridge_off_ramp_ach_wire'), prerequisites beyond the parameters, or typical scenarios. The guidance is minimal and doesn't address key decision points for an agent.

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

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

With no annotations provided, the description carries full burden. It discloses the creation action (implies mutation), the 'one per rail' limitation, and the confirmation requirement. However, it doesn't mention permissions needed, rate limits, idempotency, or what happens if a rail already has a bridge. The description adds some behavioral context but leaves significant gaps for a financial tool.

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

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

The description is moderately concise but has structural issues. The first two sentences are redundant ('Creates a virtual account...' appears twice). The parameter documentation is thorough but presented in a dense block. While informative, it could be more efficiently structured with better separation between the tool purpose and parameter details.

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

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

Given the complexity (9 parameters, financial bridge creation), no annotations, but with output schema present, the description does reasonably well. It explains the tool's purpose, constraints, and all parameters in detail. The main gaps are lack of explicit differentiation from sibling tools and incomplete behavioral context (security, error handling). The output schema handles return values, so that's appropriately omitted.

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

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 fully. It provides detailed parameter documentation: all 9 parameters are listed with clear explanations, including possible values for 'blockchain', 'currency', and 'source_rail'. The descriptions clarify what each parameter represents (e.g., 'wallet_fk: The wallet_fk provided by /access/login') and default behaviors for optional parameters.

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

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

The description clearly states the tool 'creates a virtual account to blockchain bridge' with specific payment rails (SEPA/ACH/WIRE). It distinguishes from siblings like 'bridge_list' or 'bridge_delete' by focusing on creation. However, it doesn't explicitly differentiate from other bridge-related tools like 'bridge_blockchain' or 'bridge_off_ramp' tools in terms of direction (on-ramp vs off-ramp).

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

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

The description provides some usage context: 'Confirm (yes/no) before executing' and 'Limited to one virtual account per payment rail'. It implies this is for setting up inbound payment channels. However, it doesn't explicitly state when to use this versus alternatives like 'bridge_off_ramp' tools or 'virtual_account' tools, nor does it mention prerequisites beyond the parameters listed.

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

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

Annotations are empty, so the description must fully disclose behavioral traits. It mentions a confirmation step, which adds some context, but fails to describe other critical behaviors: it does not state whether this is a destructive operation (likely yes, as it changes data), authentication requirements beyond parameters, rate limits, error handling, or what the 'json object' return entails. The description is insufficient for a mutation 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.

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

The description is poorly structured and repetitive: it starts with 'Changes the Bridge's descriptive name. Confirm (yes/no) before executing', then repeats 'Changes the Bridge's descriptive name.' unnecessarily. The parameter explanations are listed but could be more integrated. It is front-loaded with the purpose but wastes space on redundancy, reducing overall efficiency.

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

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

Given a mutation tool with 5 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is partially complete. It explains parameters well and states the return is a 'json object', but lacks behavioral details (e.g., side effects, error cases) and does not leverage the output schema to clarify return values. It meets minimal needs but has clear gaps in safety and usage context.

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

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. It provides semantic explanations for all 5 parameters (e.g., 'api_key: The api key allocated to your application', 'external_account_id: The bridge's unique reference, found on /bridge/list'), adding meaningful context beyond the schema's type definitions. This effectively covers the parameters, though some details like format constraints are missing.

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

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

The description clearly states the action ('Changes') and resource ('Bridge's descriptive name'), making the purpose evident. However, it does not explicitly differentiate from potential siblings like 'ai__account_alias' or 'ai__bridge_list', which might handle similar naming operations, though the tool name itself suggests Bridge-specific renaming.

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

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

The description includes a usage guideline: 'Confirm (yes/no) before executing,' which implies a confirmation step is needed. However, it does not specify when to use this tool versus alternatives (e.g., other Bridge-related tools like 'ai__bridge_list' for reference or 'ai__account_alias' for other aliases), nor does it provide context on prerequisites or exclusions.

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

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 describes the return type ('a json object containing the schema') and hints at reference data, but lacks details on permissions, rate limits, or side effects. Since annotations are empty, the bar is lower, and the description adds some context (e.g., it's a read operation returning structured data), but it's not comprehensive enough for a higher score.

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

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

The description is relatively concise but could be more front-loaded. The first sentence clearly states the purpose, but the second sentence ('This tools provides reference information...') is somewhat redundant and includes a grammatical error ('tools' instead of 'tool'). The third sentence ('@return: a json object...') adds value but could be integrated more smoothly. Overall, it's adequate but not optimally structured.

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

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

Given the tool's low complexity (0 parameters, no annotations, but has an output schema), the description is fairly complete. It explains what the tool returns and hints at the output structure. Since an output schema exists, the description doesn't need to detail return values extensively. However, it could better address usage context relative to siblings, keeping it from a perfect score.

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

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

The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it doesn't contradict the schema. According to the rules, 0 parameters warrants a baseline of 4, as the description appropriately avoids unnecessary parameter explanation.

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

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

The description clearly states the tool's purpose: 'Returns a list of tools that work with bridges, off-ramps, on-ramps, cross-blockchain transfers, virtual accounts.' It specifies the verb ('returns') and resource ('list of tools'), and identifies the domain (bridges, transfers, virtual accounts). However, it doesn't explicitly differentiate from sibling tools like 'ai__bridge_list' or 'ai__off_ramps', which might serve overlapping purposes, so it doesn't reach a perfect 5.

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

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

The description provides minimal guidance on when to use this tool. It mentions that it 'provides reference information in the "referenced_tools" schema,' but doesn't specify when to choose this over alternatives like 'ai__bridge_list' or 'ai__off_ramps' from the sibling list. No explicit when/when-not scenarios or prerequisites are stated, leaving usage context vague.

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

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

No annotations are provided, so the description carries full burden. It mentions 'retrieve' (implying read-only) and references 'referenced_tools' schema, but doesn't disclose behavioral traits like authentication needs, rate limits, or what 'retrieve' entails. The @return note is minimal.

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

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

Two sentences with redundancy ('Provides tools' repeated). The second sentence is confusing and doesn't add clarity. It's brief but not effectively structured or front-loaded.

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

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

Has output schema, so return values are covered. However, for a tool with no annotations and minimal description, it lacks context on what 'commodities' means, how retrieval works, or integration with sibling tools. Incomplete for understanding its role in the system.

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

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

Parameter count is 0, so there are no parameters to document. Schema description coverage is 100%, but with no parameters, the description doesn't need to add semantic value. Baseline is 4 as per rules for 0 parameters.

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

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

The description states 'Provides tools to retrieve Netfuid commodities' which gives a basic verb+resource, but 'Netfuid' appears to be a typo (likely 'Netfluid' based on sibling tools). It doesn't distinguish from siblings like 'ai__commodity_types' or 'ai__crypto_digitalassets'. The second sentence is confusing and doesn't clarify the primary purpose.

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

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

No guidance on when to use this tool versus alternatives. There are many sibling tools related to commodities, crypto, and assets, but the description provides no comparison or context for selection.

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

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

Annotations are empty, so the description carries full burden. It states this is a read operation ('returns'), which implies non-destructive behavior, but doesn't disclose any behavioral traits like authentication needs (only mentions api_key as a parameter without context), rate limits, error handling, or what 'authorised' means. The description adds minimal value beyond the 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.