Netfluid

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

No annotations are provided, so the description carries the burden. It correctly describes the tool as returning information without side effects. It mentions the output schema, adding transparency about return structure.

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

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

The description is 4 sentences long, containing key information. It could be slightly more concise, but it front-loads the purpose and includes important details about the output schema.

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 zero parameters and a clear purpose, the description is complete. It mentions the output schema, which is sufficient for an informational tool. No gaps are apparent.

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?

There are no parameters, so the baseline is 4. The description adds value by specifying the types of information returned (netfluid, domains, policies, etc.), which helps the agent understand what to expect.

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 it returns general information about netfluid, including domains, policies, support, etc. It positions itself as 'Start Here', distinguishing it from sibling tools as an introductory reference.

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 says 'Start Here ! Everything Netfluid', implying it should be used first for overview information. It does not list exclusions or alternatives, but the context makes its role clear.

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 must fully disclose behavior. It states the tool temporarily blocks access but does not elaborate on side effects, reversibility, or what happens to ongoing operations.

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 short but contains redundancy with the same phrase repeated. Parameter documentation is structured but 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 simplicity (2 params) and presence of an output schema, the description covers purpose and prerequisites. However, it lacks context about post-pause behavior or integration with resume 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?

The input schema has 0% description coverage, but the description adds explicit parameter explanations for both api_key and wallet_fk, clarifying their roles beyond just 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 uses a specific verb 'blocks' and resource 'wallet', clearly indicating the action. It distinguishes from siblings like ai__access_resume which performs the opposite 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 mentions the need for an api_key with administrator privileges, which is a prerequisite. However, it does not provide explicit guidance on when to use this tool versus alternatives like ai__access_resume.

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, so description should disclose behavioral traits. It only states 'assigns' (mutation) but lacks details on side effects, permissions, error states, or return value structure.

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?

Description is short but repeats the first sentence. Parameter docs are presented as a list but could be more structured. Not overly verbose, 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?

Despite having an output schema, the description does not explain return values. Two parameters are undocumented, and the context (5 required params, 0% coverage) demands more detail for 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 coverage, description documents 3 of 5 required params (api_key, token, wallet_fk) but omits user_id and platform. This adds partial meaning but is incomplete.

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 it assigns a wallet_fk to a channel user id (discord, telegram, whatsapp), providing a specific verb and resource. However, the repetition and mismatch with input schema parameters slightly reduce 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?

Only advice is to prompt the customer for easier future session tokens. No explicit guidance on when to use vs alternatives like login, nor 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?

Discloses the single-attempt constraint and consequence of wrong PIN. However, with no annotations, it should also mention if the tool is idempotent, has side effects, or requires specific auth. The description adds some transparency but is incomplete.

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: the first two sentences are almost identical, and the @param section echoes earlier text. It could be condensed to one clear paragraph without losing 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?

With an output schema present, the description doesn't need to detail return values. It covers purpose, parameters, and the critical behavioral constraint. However, it lacks mention of error states or success outcomes beyond the single-attempt rule.

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 coverage, the description adds value by specifying PIN is 5-digit numeric, and wallet_fk is an integer (implied by schema). It clarifies the format and constraint beyond the schema's type declarations.

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 retrieves a session token using a wallet_fk and a numeric PIN, and distinguishes itself as a shortcut to the session token, implying alternative methods exist. The verb 'retrieves' and resource 'session token' are specific.

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?

Provides clear context: only one attempt allowed, misstep requires sending user back to website. Implies use when wallet_fk and PIN are available, but doesn't explicitly contrast with sibling tools like ai__session_2_token.

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 exist, so description must cover behavior. It discloses the prerequisite condition but lacks details on read-only nature, rate limits, error conditions, or response structure beyond 'a json object'.

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 first sentence is repeated word-for-word, making the description unnecessarily verbose. It could be half the length without losing 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 existence of an output schema and the prerequisite condition being explained, the description is minimally adequate. However, it lacks differentiation from sibling wallet tools and doesn't hint at the return structure, which could be improved.

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 clear parameter explanations: user_id is the chat-specific ID, platform includes allowed values (discord, telegram, whatsapp). This adds significant value over the 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 retrieves wallets for a specific channel and user. The mention of wallet_fk and session token adds context. It implicitly distinguishes from sibling tools like wallet_accounts_list, but doesn't explicitly differentiate.

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 gives a prerequisite condition ('only works if wallet_fk assigned'). No explicit guidance on when to use vs. alternatives, but the condition provides some 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?

Annotations are empty, so the description carries full burden. It states it recovers a private key and returns owner details, but does not disclose side effects, authentication requirements, rate limits, or whether the operation is irreversible.

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 repeats the first sentence and contains a truncated sentence ('It's preferable that the person trying to recover...'). The JSDoc block adds structure but redundancy reduces conciseness.

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 sensitive operation like recovering a private key, the description lacks details on output format (only says 'json object'), error handling, security considerations, or required permissions. The incomplete sentence further reduces 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 schema description coverage at 0%, the description adds significant meaning: it explains that api_key is for the application, and words are exactly 24 space-delimited recovery words. This fully compensates for the schema 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 tool recovers a private key from 24 keywords, specifying the verb and resource. However, it does not distinguish itself from siblings like ai__wallet_mnemonic, which also deals with recovery phrases.

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. The description does not mention prerequisites, context, or when not 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?

Annotations are empty, so the description bears full responsibility. It discloses a behavioral requirement (admin privileges) and the basic effect (resume access), but includes an erroneous first sentence that says 'blocks', creating internal contradiction. No details on reversibility, side effects, or state dependencies are provided.

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 short but contains a misleading first sentence that should be removed. The structure is front-loaded, but the contradictory information harms efficiency. Minor cleanup would improve it significantly.

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 simplicity (2 required parameters, no enums), the description covers the essential workflow and auth requirement. However, it lacks details about the return value (only 'a json object') and does not mention edge cases or error conditions, leaving some 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?

With schema coverage at 0%, the description fully compensates by explaining both parameters: api_key as 'The api key with administrator privileges' and wallet_fk as 'The wallet_fk to resume'. This adds meaningful context beyond the schema's type-only definitions.

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 begins with 'Temporarily blocks access to the wallet,' which directly contradicts the intended purpose of resuming access. This misleading initial statement reduces clarity, even though the second sentence correctly states the action. The verb and resource are identifiable but the confusion lowers the 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 implicitly indicates that this tool is for resuming a paused wallet, and mentions that administrator privileges are required. However, it provides no explicit guidance on when to use vs. alternatives (e.g., ai__access_pause) or any conditions or prerequisites beyond authorization.

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 only states 'Changes the wallet PIN' and the PIN length constraint. It does not disclose behavioral traits such as destructiveness, permission requirements, rate limits, or what happens on failure. For a mutation tool, this is insufficient transparency.

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: the same sentence appears twice in the description field. The parameter documentation is in a code-like format, not optimally structured. It could be more concise and front-loaded without duplication.

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?

An output schema exists, so return value explanation is not needed. The description covers prerequisites through parameter documentation (token and wallet_fk from login). However, it lacks error conditions, idempotency, or session implications. For a 4-parameter mutation tool, the description is adequate but not complete.

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 includes Javadoc-like comments explaining each parameter: api_key, token, wallet_fk, new_pin, with sources and constraints (e.g., 'provided by /access/login', '5 numeric digits'). This adds meaningful context beyond the schema's type-only definitions.

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 'Changes the wallet PIN' and specifies the constraint 'must be 5 digits'. This is a specific verb+resource combination. Among sibling tools, there is no other PIN change tool, so it distinguishes well.

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 does not explicitly state when to use this tool versus alternatives. It implies usage by listing required parameters (api_key, token from /access/login, wallet_fk), but no exclusions or alternative tools are mentioned. Given many wallet-related siblings, guidance is lacking.

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 only states it returns a JSON object with no mention of side effects, authentication needs, rate limits, or error behavior. Minimal 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 extremely concise (two sentences, ~20 words) with no redundancy. It front-loads the action and lists the returned fields 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?

For a simple lookup tool with one parameter and an output schema, the description covers the main functionality. It could be improved by clarifying when account_fk is valid or what 'public information' excludes, but it is largely complete.

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% description coverage, so the description must compensate. It adds context by stating that account_fk is used to retrieve associated public info, but does not explain the parameter's meaning beyond its name.

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 it returns public information for an account_fk, listing specific fields (address, commodity, currency, type). It distinguishes itself among siblings by specifying 'public information' but does not explicitly differentiate from similar tools like ai__account_info.

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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It simply states what it does without 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 empty annotations, the description carries the full burden of behavioral disclosure. It describes the tool as performing a validation/verification (likely read-only), but does not elaborate on side effects, idempotency, error conditions, or rate limits. The mention of returning a JSON object adds some value, but more detail would be beneficial.

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 very concise, with one sentence and a @return line. It is front-loaded and lacks unnecessary words. However, it could benefit from slightly more structure (e.g., separating purpose from return type) to improve readability.

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 simplicity, the description is incomplete. It covers the basic purpose and return type but omits usage guidance, parameter details, and behavioral specifics. Even with an existing output schema, more context is needed for an agent to use the tool effectively.

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

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 identifies the parameter as a Netfluid account address and clarifies it is not a blockchain address, but offers no format, examples, or constraints. This is insufficient for an agent to know how to properly fill the 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 it validates and verifies the existence of a Netfluid account address, explicitly distinguishing it from a blockchain address. It specifies the verb (validates/verifies) and resource (account address), effectively differentiating it from sibling tools like ai__account_info or ai__crypto_verify.

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. It does not mention when to use it, when not to, or list alternative tools such as ai__account or ai__wallet_verify. The description only states what the tool does, not the context for its use.

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 mentions that user confirmation (yes/no) is required before executing, which is a key behavioral trait, but it doesn't explain how confirmation works or other side effects. With no annotations, this partially addresses transparency.

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 with redundant opening lines and code-like param documentation. It could be much more concise and structured better.

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?

While an output schema exists, the description lacks context about the confirmation process, error scenarios, or prerequisites beyond the parameters. The confirmation requirement is left unexplained, reducing 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 coverage is 0%, so the description must provide parameter details. It does offer explanations via @param comments, but the account_fk description confusingly mentions charging for a mint fee, which seems unrelated and may mislead.

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 it sets a friendly name/alias on an account. However, it is redundant with two similar sentences and includes an unexplained confirmation requirement which slightly muddles the 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 is provided on when to use this tool vs alternatives like ai__account_info or ai__account. The description does not mention prerequisites or when not 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, the description carries the burden. It discloses a confirmation (yes/no) step before execution, which is a key behavioral trait. However, it omits details like insufficient balance handling, authorization requirements, or side effects.

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

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

The description repeats the main sentence twice, reducing conciseness. The param docs are clearly separated but could be integrated more efficiently. Overall, functional but not 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 4 required params, no annotations, and an output schema (though not shown), the description covers param docs and return type, plus the confirmation step. Missing context on error handling, success conditions, and authorization needs.

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 coverage is 0%, but the @param lines explain each parameter: api_key and token as credentials, account_fk as a database ID (not address) with a constraint (not 0), and digital_asset_fk as the asset to buy. This adds significant 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 purchases a digital asset from FIAT balance, distinguishing it from siblings like ai__account_buy_telco. However, it does not specify the type of digital asset (e.g., crypto vs other), which could cause ambiguity.

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 explicit guidance on when to use this tool vs alternatives like ai__account_buy_telco or ai__account_sell. Mentions a confirmation step but does not explain 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?

Discloses conversion to minutes/seconds and a confirmation step, but omits details like idempotency, side effects, or failure states. With no annotations, the description partially compensates but lacks full behavioral context.

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

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

Description is redundant (repeats first sentence) and uses verbose Javadoc-style param list. Could be more compact without losing meaning.

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?

Covers purpose and parameters adequately, but lacks prerequisites (e.g., account_fk validity, balance), rate limits, or error behavior. Output schema exists but description doesn't leverage it to reduce burden.

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?

All 5 parameters are explicitly described with purpose, constraints (e.g., account_fk is database ID not address, amount with 2 decimals), and examples (currency_code). Schema description coverage is 0%, so description fully compensates.

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?

Clearly states 'Purchases airtime by converting currency to minutes and seconds', which is a specific verb+resource+scope. Differentiated from sibling 'ai__account_buy' by specifying airtime and time conversion.

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 explicit guidance on when to use this tool vs alternatives (e.g., ai__account_buy). The confirmation mention implies a non-immediate process, but no scenarios or exclusions 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?

Annotations are empty, so the description carries full burden. It discloses that a PIN is required and a confirmation step exists, but omits details on idempotency, error scenarios, or what happens on success/failure. The return is vaguely described as 'a json object'.

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 (first sentence repeated) and the JSDoc block is verbose with line breaks. It could be more compact while retaining 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?

With 7 parameters and no annotations, the description lacks details on error handling, return value structure (output schema exists but is not explained), and behavior for optional note. The requirement for confirmation is mentioned but not how it is triggered. Overall incomplete for a financial transaction 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?

Despite 0% schema coverage, the JSDoc-style comment in the description explains each parameter's purpose, including clarifying that account_fk is a database ID (not address) and that amount is the charge amount. This adds significant meaning beyond the schema's type definitions.

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 the account') and specifies the method (QR-code or NFC card). It distinguishes itself from sibling tools like ai__account_pay or ai__account_send by mentioning PIN requirement and confirmation step.

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 mentions prerequisites (PIN, confirmation) but does not explicitly guide when to use this tool versus alternatives like ai__account_pay or ai__account_send. Usage is implied but lacks comparative 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 empty annotations, the description carries the full burden. It only states it returns data and repeats 'Returns detailed account information.' It does not disclose read-only nature, authentication requirements (though parameters imply it), error handling, or any side effects. Minimal behavioral insight.

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 front-loads the purpose but is slightly repetitive ('Returns detailed account information' appears twice). The param documentation is included inline, which adds length but is necessary given zero schema descriptions. Could be more concise 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?

The tool has 3 required parameters and an output schema (not shown), yet the description only vaguely mentions 'a json object'. It fails to describe what fields are in the output or how the account info is structured. Given the complexity and sibling tools, more contextual detail is expected.

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 description provides detailed, meaningful explanations for all three parameters, clarifying that account_fk is an integer database ID (not zero) and where to obtain token and account_fk. This adds value beyond the schema, which had no descriptions (0% 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 'Returns detailed account information and balances,' providing a specific verb and resource. However, it does not differentiate itself from sibling tools like 'ai__account' or 'ai__accounts', which likely also return account 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?

No guidance is provided on when to use this tool vs alternatives. It does not mention prerequisites, exclusions, or complementary tools, leaving the agent to infer usage from the description alone.

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 description must disclose behavior. Only states it issues a voucher as a withdraw. Missing details on mutability, reversibility, balance deduction, or required permissions. Minimal disclosure for a financial 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?

Concise description with two lines plus param docs. Efficient but could be better structured with proper sections. No wasted words.

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 context of financial operations and sibling tools, the description lacks completeness. No mention of return format, error scenarios, or relation to other voucher tools. Output schema exists but not used to reduce burden. Missing critical context for safe usage.

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 coverage is 0%, and description adds inline parameter docs, explaining api_key, token, account_fk (with constraint 'not 0'), and amount. However, amount lacks unit, and account_fk explanation is helpful but brief. Adds value but incomplete.

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?

Clearly states it issues a Netfluid voucher and performs a FIAT withdraw. The verb 'issues' and resource 'Netfluid voucher' are specific. Sibling tools 'quote' and 'redeem' differentiate the action. However, it could be more explicit that this is the execution step after quoting.

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?

Implies usage for FIAT balances only, but does not provide explicit guidance on when to use this tool vs 'quote' or 'redeem'. No prerequisites or post-conditions mentioned.

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?

Discloses it's a quote step (non-issuing) and returns commission and charged amount, but doesn't clarify side effects, permissions, or idempotency; annotations are empty so description carries burden.

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?

Structured with step, param list, and return, but first sentence is awkward ('Performs a quote to before issuing') and some redundancy; 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 presence of an output schema, the description adequately covers the tool's purpose, input parameters, and return type; minor gap on error conditions.

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 coverage is 0%, but description provides detailed, useful meaning for all 4 parameters, including type clarifications (e.g., account_fk is an int, not string) and constraints (amount max 2 decimals).

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 it performs a quote before issuing a Netfluid voucher as a merchant, and distinguishes from sibling tools like issue and redeem by specifying it's the quote step.

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 (e.g., issue or redeem); lacks context for prerequisites or decision criteria.

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 description carries full burden. Only states 'Redeems' with no details on side effects, authentication, rate limits, or outcome of redemption. Score 2.

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?

Description mixes natural language with Javadoc param listing, which is somewhat verbose. Could be more concise by separating param details. Score 3.

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 but not shown. With 4 params and no behavioral notes, description covers params adequately but lacks outcome details. Score 3.

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 coverage is 0%, but description adds meaning: account_fk typed as DB ID int not address, voucher_code format example. Adds value beyond schema. Score 4.

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?

Description clearly states 'Redeems a Netfluid voucher.' Verb+resource is specific. Among sibling tools (issue, quote, check), 'redeem' is distinct. Score 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?

No guidance on when to use this tool vs related tools like issue, quote, or netfluid_voucher_check. No prerequisites or context for use. Score 2.

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 confirmation requirement, cost, and asynchronous nature. It does not disclose error handling, idempotency, or permissions, but the given details are useful for basic 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 somewhat repetitive ('Mints a new account...' appears twice) and includes @param lines that could be integrated more concisely. It is structured with line breaks but could be tightened 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?

The tool has an output schema but the description only states '@return: a json object' without specifying its structure. The confirmation mechanism is mentioned but not explained (e.g., how to provide yes/no), leaving significant ambiguity 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%, so the description compensates by explaining each parameter's source or purpose (e.g., api_key from app, token from /access/login, defaults for account_type_fk and currency_fk). It adds meaning beyond the raw schema, though some parameters (wallet_fk) have minimal elaboration.

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 it 'Mints a new account of an account type into the wallet.' The verb 'mint' and resource 'account' are specific. However, it does not explicitly differentiate from sibling tools like ai__account, which may perform a similar or different action, so a perfect score is not warranted.

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 contextual notes: 'Confirm (yes/no) before executing,' 'costs associated,' and 'asynchronous.' However, it does not specify when to use this tool versus alternatives, nor does it list exclusions or prerequisites beyond authentication 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?

Annotations are empty, so the description carries full burden. It discloses the need for confirmation, but lacks information on authorization requirements, potential destructive effects, rate limits, or error handling. The behavioral context is partially provided but incomplete.

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 repeats the main sentence twice and includes a param list. While front-loaded with the purpose, it could be more concise by removing the duplicate. The structure is acceptable 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 the output schema exists, return values need not be explained. However, the description does not cover potential errors, constraints (e.g., PIN uniqueness), or the process beyond confirmation. It is adequate for basic understanding but lacks depth for complex scenarios.

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 description provides detailed semantic meaning for all 5 parameters: api_key, token, address, pin (including format example '01234'), and expire_date (with format and timezone). This adds significant value beyond the empty input schema, which only specifies 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 tool assigns a PIN to an account for use with QR codes or NFC cards, using a specific verb and resource. However, it does not differentiate from sibling tools like ai__access_wallet_pin_change, which might have overlapping functionality.

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 mentions a confirmation step ('Confirm (yes/no) before executing') but provides no guidance on when to use this tool versus alternatives. The usage context is implied but not explicit, and no exclusions or alternatives are given.

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 empty annotations, the description provides some behavioral context: the restriction is temporary, requires admin to undo, and warns. However, it lacks details on side effects (e.g., impact on ongoing transactions, session termination) and error responses.

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 (first line duplicated) and mixes parameter docs with the main text. While informative, it could be more concise by eliminating the duplication and structuring the parameter section separately.

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 sensitivity and 4 parameters, the description covers basic usage and warnings but lacks output schema details (just '@return: a json object'). With an output schema existing, this is acceptable but not comprehensive.

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 coverage is 0%, but the description explains parameters beyond the schema: for account_fk, it clarifies it's a database ID and provides a source; for lock, it describes the effect. This compensates well, though api_key and token lack additional meaning.

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 uses a specific verb-resource pair and distinguishes from siblings like ai__account_resume (undo) and ai__access_pause (different scope).

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 warns about undoability ('Can only be undone by an administrator') and recommends confirmation ('Confirm (yes/no) before executing'). It implies use for sensitive account restrictions but does not explicitly state when not to use or list alternative 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, the description carries full burden. It mentions confirmation but fails to disclose destructive nature, error handling, or return format. Minimal behavioral context.

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

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

Description includes parameter docstrings making it longer than necessary. Structured but not concise; some redundancy with schema.

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 payment tool with 5 parameters and no annotations, the description lacks details on confirmation mechanics, output, and error handling. Incomplete 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 coverage is 0%, and the description adds parameter docstrings. It clarifies account_fk as a database ID not address, and notes amount and note. Adds some value but could be more precise.

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 it charges a transaction fee to an account, with a clear verb and resource. However, it does not differentiate from similar sibling tools like ai__account_charge.

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?

Indicates a confirmation step ('Confirm (yes/no) before executing') but provides no guidance on when to use this tool versus alternatives, or prerequisites.

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 exist, so the description carries the full burden. It discloses the need for admin undo and confirmation, but does not describe side effects, auth requirements, or behavior if account is already active. Provides basic but not comprehensive transparency.

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 first sentence is repeated verbatim, creating unnecessary redundancy. The description is otherwise clear and front-loaded, but 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?

While the tool is simple, the description does not explain the output format beyond 'a json object' or describe error conditions (e.g., if the account is already active). Adequate but lacks some 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 coverage, the description adds critical context: clarifies that account_fk is an integer database ID not a string, cannot be 0, and provides sources for token and account_fk. This significantly aids correct parameter 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 verb 'Resumes' and the resource 'full trading capability for an account', distinguishing it from siblings like pause tools. It is specific and unambiguous.

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

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

The description provides context (requires admin undo, requires confirmation) but does not explicitly state when to use this tool versus alternatives like ai__access_resume. No exclusions or comparisons are given.

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 empty annotations, the description must fully disclose behavior. It only states it 'provides tools' and 'reference information,' without explaining side effects, authentication requirements, rate limits, or what happens when called. The return value is vaguely described as 'a json object' with no specifics.

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 only two sentences, but the first sentence is misleading (it implies the tool provides multiple tools, which is odd given the tool's definition). The second sentence adds little clarity. While short, it fails to be effectively concise due to confusion.

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 apparent complexity (handling accounts, referencing tools), the description is grossly insufficient. It does not explain what the tool returns beyond 'a json object', nor does it cover prerequisites, error handling, or integration with sibling tools. The existence of an output schema does not compensate for the lack of explanation.

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 one parameter (api_key) with 0% schema description coverage. The tool description does not explain what api_key is used for, nor does it add any meaning beyond the schema. The parameter's purpose and format are completely ambiguous.

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 says 'Provides tools to create and manage wallet accounts,' but the tool itself has only one parameter (api_key) and no indication of creating or managing. It mentions 'referenced_tools' schema, suggesting it returns metadata about other tools rather than performing account operations. This vagueness makes the purpose unclear and potentially misleading.

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 the many sibling tools like ai__account, ai__account_info, etc. The description does not differentiate its use case or provide context for appropriate invocation.

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 the burden. It indicates a mutation (sell) and a confirmation requirement, but lacks details on reversibility, authentication needs beyond parameters, or rate limits. Moderate transparency.

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 repeats the same sentence and includes redundant phrasing. It could be more concise while retaining 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 5 parameters and no annotations, the description is incomplete. It only says '@return: a json object' without specifying structure or error cases, and lacks behavioral details expected for a selling 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%, but the description provides meaningful parameter docs (e.g., account_fk clarifies it's a database ID, not an address). This adds value beyond the schema, though 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 sells a digital asset and returns proceeds to FIAT balance, using a specific verb and resource that distinguishes it from siblings like ai__account_buy 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 mentions a confirmation step ('Confirm (yes/no) before executing'), which provides clear usage context. However, it does not explicitly compare to alternatives or state when not to use this tool.

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

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

Annotations are empty, so the description must disclose behavioral traits. It mentions that the tool converts FIAT to destination currency, can save beneficiaries, and requires confirmation. However, it omits important details such as whether the operation is destructive, idempotent, or has side effects like balance deduction. No information about error states or rate limits is provided.

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 has redundancy (two similar opening sentences) and is lengthy. However, the parameter documentation is well-structured with @param blocks, making it easy to parse. The first part could be more concise, but the overall structure is functional.

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 params, financial transaction, no annotations), the description covers parameters well but lacks details on the output (just 'json object'), error handling, and prerequisites beyond params. The confirmation mechanism is mentioned but not fully specified. Adequate but with 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%, but the description compensates fully by documenting every parameter with @param tags. It clarifies the distinction between account_fk (database ID) and destination (user-readable address), explains the boolean semantics of save (0/1), and notes that name only applies if save=1. 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 that the tool sends FIAT to another Netfluid account or account address, with optional beneficiary saving. It specifies the resource (FIAT) and action (send). However, it does not explicitly differentiate from similar siblings like ai__account_pay or ai__account_wire, though the context suggests these have different purposes.

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 (e.g., ai__account_wire, ai__crypto_spend). It mentions a confirmation step but does not explain when confirmation is required or how to handle it. No exclusion criteria or prerequisites beyond the parameters are stated.

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 sending charges the account, requires admin privileges, and delivery is not guaranteed. However, it omits details on error handling or idempotency.

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 well-structured with a summary, details, and parameter list, but repeats the first sentence twice. It is mostly efficient and 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?

Given the output schema exists and the description covers purpose, parameters, and behavioral traits (charging, limited destinations), it is fairly complete. Minor gaps exist regarding side effects or concurrency.

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 description provides extensive meaning beyond the schema, such as requiring admin privileges for api_key, specifying account_fk as a database ID and not zero, mobile format (e164 without +), and message charging per 160 characters. This compensates for the 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 tool sends a mobile SMS and charges the account, distinguishing it from other messaging tools like ai__email or ai__text_message. It also specifies the action verb and resource.

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 mentions the need for confirmation and limited destinations, but lacks explicit when-to-use or when-not-to-use guidance compared to sibling tools. No alternatives are suggested.

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 default values for max_rows (1000) and start_date (60 days) and notes timezone (GMT). However, it does not state whether the tool is read-only or destructive, nor mention rate limits or result ordering.

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 structured with clear parameter documentation, but including inline @param tags makes it slightly verbose. It could be more concise by separating the parameter details, but it's well-organized and front-loaded with purpose.

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, an output schema exists, and the description covers all inputs and basic behavior, it is mostly complete. Minor gaps include lack of information about result ordering, pagination (beyond max_rows), and explicit mention of the output schema.

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 coverage is 0%, but the description provides thorough documentation for all 5 parameters, including types, defaults, format (start_date), and important notes (account_fk is int, not string). This adds significant 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 'Returns detailed account FIAT statement', specifying the verb and resource. It distinguishes from siblings like 'ai__account_info' by focusing on 'statement' for FIAT transactions, but could be more explicit about what the statement contains.

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 (e.g., ai__account_info, ai__account). The description only explains what it does, not when it should be preferred or avoided. Implicit usage context is missing.

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?

Lacks annotations, so description must provide behavioral details. It mentions confirmation requirement and special FK=0 for FIAT, but omits side effects, reversal possibility, required permissions, and response structure beyond a generic JSON object.

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?

Repetitive opening sentence. Structured param docs are helpful but could be more concise. Front-loaded with purpose.

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 complexity and no annotations, description covers basic inputs but misses usage context, return details, and prerequisites for safe 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?

With 0% schema coverage, description adds meaning: explains account_fk is DB ID not address, digital_asset_fk=0 indicates FIAT, and lists all params. Lacks amount format and note clarity, but covers most.

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 it swaps digital assets on an account level, distinguishes from sibling tools like ai__crypto_swap by specifying 'account level', and notes special FIAT handling.

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 (e.g., ai__crypto_swap, ai__crypto_dex_swap). Only mentions a confirmation step but no exclusions or prerequisites.

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 'static information' but does not disclose whether the tool is read-only, any authentication requirements, or other behavioral traits beyond listing.

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 short but contains redundant lines ('Lists all account types' appears twice). It is front-loaded with the core purpose, but the repetition is unnecessary.

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 simple nature of the tool (one param, output schema exists), the description adequately covers the purpose and parameter but lacks details about the return value structure beyond '@return: a json object'.

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 description documents the api_key parameter with '@param api_key: The api key allocated to your application', adding meaning beyond the schema which only defines it as a string. Schema description coverage is 0%, so this adds value.

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 'Lists all account types' with 'typically static information', which is a specific verb+resource. However, it does not explicitly differentiate from sibling tools like 'ai__account' or 'ai__commodity_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 on when to use this tool vs alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

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 provided, so description carries full burden. It discloses status change and privilege requirement, but omits side effects, idempotency, or behavior if account is already unlocked.

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?

Contains redundant phrase 'Unlocks a locked account' repeated; could be more concise while maintaining 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?

With output schema present, return values are covered. Description explains status change and params, but lacks context on error handling or prerequisites beyond param docs.

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 coverage is 0%, but description provides detailed semantics for all 3 params: api_key requires admin, token source, account_fk is int DB ID not address and cannot be 0.

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 it unlocks a locked account with specific status change (10 to 1), distinguishing it from siblings like pause/resume. However, the duplicate sentence reduces clarity slightly.

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?

Provides confirmation instruction and admin privilege requirement via param docs, but lacks explicit when-to-use or when-not-to-use compared to sibling tools like ai__account_resume.

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 empty annotations, the description must cover behavior. It discloses that the tool initiates transfers (likely destructive) and requires confirmation. However, it lacks details on side effects, authentication requirements (though parameters hint at them), rate limits, or what happens post-execution beyond a JSON return.

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 contains redundancy (the first sentence is repeated) and mixes narrative with parameter documentation in a comment block. While all necessary information is present, it could be more concise and 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 7 parameters, 0% schema coverage, and empty annotations, the description covers parameter semantics and some constraints (account association, conversion). However, it lacks details on return value interpretation, error handling, and parameter ordering. The existence of an output schema mitigates the need for return format details.

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 coverage is 0%, so the description must explain parameters. It does so via JSDoc-like comments, clarifying account_fk is a database ID not an address, digital_asset_fk is 0 for FIAT, and note is optional. This adds meaningful context beyond the schema's empty 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 sends FIAT or Digital Assets from an account to a blockchain address, with FIAT conversion by the system. It distinguishes this wire action from sibling tools like ai__account_send or ai__account_pay by specifying the destination is a blockchain address and that there is a confirmation step.

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 conditions for use: FIAT account must be associated with the same blockchain as the destination address. It also mentions a confirmation step before execution. While it does not explicitly name alternatives, the context differentiates it from other send-like tools among siblings.

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 convey behavioral traits. It implies a read-only operation by stating it returns a list, but does not explicitly disclose side effects, auth requirements, or rate limits. The basic behavior is clear but incomplete.

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 short but contains a grammatical error ('This tools provides'). It is front-loaded with the main purpose, but the error and awkward phrasing reduce clarity. Each sentence serves a purpose, but the structure could be cleaner.

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 simple nature (no parameters, output schema exists, annotations empty), the description adequately explains the tool's function and references the output schema. It is sufficiently complete for an agent to understand its 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?

The tool has 0 parameters, so the baseline is 4 per instructions. The schema coverage is 100%, and no parameter descriptions are needed. The description adds no param info, which is acceptable.

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 a list of tools related to bridges, off-ramps, on-ramps, cross-blockchain transfers, virtual accounts. This clearly defines the verb and resource, and distinguishes it from sibling tools that perform actions rather than list 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 like ai__bridges, ai__off_ramps, etc. The description lacks explicit context on usage scenarios or exclusion criteria.

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 must disclose all behavioral traits. It only states that the tool performs a prompt, omitting whether it is read-only, has side effects, or requires specific auth levels. No mention of error handling, rate limits, or response structure, which is insufficient for a tool with authentication 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 brief and front-loaded with the main purpose. It uses a structured JSDoc format for parameters, which is efficient and easy to parse. No extraneous text, earning a high score for conciseness.

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 four required parameters and no annotations, the description should provide more context about the response (output schema exists but is not described) and interaction flow. The tool is incomplete without explaining how to use the prompts or handle token-based auth, resulting in low 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?

Parameter descriptions in the JSDoc add some meaning beyond the schema (e.g., 'The api key allocated to your application'), but they are minimal and do not explain formats, sources, or constraints. With 0% schema coverage, the description partially compensates but remains incomplete.

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 identifies the tool as an interface to Gemini AI. However, it does not clarify the scope of prompts (e.g., chat, generation) or distinguish it from sibling tools like ai__about or ai__skill, resulting in vague overall 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 is given on when to use this tool versus alternatives, nor are prerequisites or context provided. The description lacks instructions on how to obtain the required authentication parameters (api_key, token, wallet_fk), leaving the agent without actionable 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, description discloses creation of wallet, Solana minting, requirement for sponsor, and need to save credentials. Missing potential rate limits or error scenarios, but overall transparent.

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?

Description is verbose, contains duplicate text, and lacks clear structure. Parameter docs are embedded in narrative, making it hard to scan. Could be more concise 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 (7 params, no annotations, output schema exists), description covers purpose, prerequisites, parameter details, and return type. Lacks error handling info but overall complete.

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?

Since schema coverage is 0%, description compensates with detailed parameter documentation: secret (min 8 chars, unique), pin (5-digit), email (blank default), mobile (e164 format), currency_fk (default 7/3), sponsor_wallet_fk (KYCed required), sponsor_wallet_pin (5-digit). Adds constraints and suggestions.

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?

Description clearly states it is for automated signup of autonomous agents for payments. It distinguishes from human signup but does not explicitly differentiate from sibling 'ai__automated_signup'.

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?

Provides prerequisites (needs human KYCed wallet), outcomes (full wallet capabilities), timing (up to 30 seconds), and legal responsibility. Lacks explicit when-not or alternative tool recommendations.

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

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

With no annotations, the description carries the full burden. It discloses that the process takes up to 30 seconds, returns a JSON object, and involves creating a customer record. However, it does not explicitly state the mutation nature or potential side effects like repeated calls might create duplicates.

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 structured with clear sections for purpose, process, and parameter details. It frontloads the main purpose. While somewhat lengthy, the parameter descriptions are justified and the flow is clearly explained. A minor redundancy exists in the first two sentences.

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, no enums, and an output schema present, the description is complete. It covers all parameters with usage guidance, the process flow, and what to do after completion. It also references the output format as a JSON object, sufficient given the output schema.

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 coverage is 0%, so the description must compensate. It provides detailed explanations for all 5 parameters: secret (unique, min 8 chars, natural language suggestion), pin (5-digit), email, mobile (e164 format), currency_fk (with example values based on location). This adds substantial meaning beyond the 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 'Automated signup for new customers' and distinguishes from sibling tools by specifying it's the preferred method for signing up human customers, differentiating from 'ai__automated_agent_signup' and 'ai__signup'.

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 says to use this as the preferred method for signup, notes the process can take up to 30 seconds, instructs to direct to KYC URL afterwards, and names an alternative tool ('wallet_kyc_session_create') for additional identity verification attempts.

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 mentions it provides reference information and references a 'referenced_tools' schema, but lacks detail on behavior such as being read-only or side effects, though no annotations exist.

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 short but unnecessarily repeats the same sentence twice, reducing conciseness.

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 no parameters and an existing output schema, the description is adequate but could provide more context about what the reference information contains.

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?

No parameters exist, so the description does not need to add parameter information; baseline score for 0 parameters is 4.

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 provides reference information on the term 'beneficiary', distinguishing it from sibling tools like ai__beneficiaries_list, ai__beneficiary_add, etc., which perform actions.

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 explicit guidance on when to use this tool versus alternatives, but the reference nature is implied by the description and sibling names.

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 exist, so the description must fully disclose behavior. It provides parameter constraints (e.g., account_fk can be 0) and hints at read-only nature, but lacks details on authentication requirements, rate limits, or side effects. Return is only described as 'a json object'.

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 verbose with duplication (first line repeated) and mixed prose with parameter documentation. While informative, it could be more tightly structured and 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?

For a list operation with output schema available, the description covers purpose and parameters adequately. It does not discuss pagination or ordering, but overall is complete enough for an agent to understand the tool's 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?

With 0% schema coverage, the description provides comprehensive explanations for all 4 parameters, including source, constraints, and behavior (e.g., account_fk can be 0 for wallet-wide listing). This adds significant value beyond the 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 it lists all beneficiaries on a wallet or account, using a specific verb and resource. It distinguishes from siblings like 'beneficiary_add' and 'beneficiary_remove' by indicating it is a list operation.

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 explicit guidance on when to use this tool versus alternatives, such as 'ai__beneficiaries' or other list tools. The description does not 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?

No annotations exist, so the description should disclose behavioral traits. It mentions 'creates' (write) but lacks details on side effects, permissions, rate limits, or return structure beyond 'a json object'. Minimal behavioral context.

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

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

The description front-loads the purpose but then repeats the exact same sentence. The parameter list is structured but verbose. Could be more concise by removing the duplicate 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?

Despite having 8 parameters and an output schema, the description only says '@return: a json object' without explaining the return structure, errors, or idempotency. Incomplete for a complex creation 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?

Although schema description coverage is 0%, the description includes @param annotations for all 8 parameters, adding meaning (e.g., 'api_key: The api key allocated to your application'). This compensates well, though some descriptions (e.g., 'name', 'note') could be more detailed.

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 'Creates a beneficiary on this wallet or on this account', which is a specific verb and resource. It distinguishes from siblings like ai__beneficiary_remove (remove) and ai__beneficiaries_list (list).

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 other beneficiary tools, nor any prerequisites or context. The description simply states the action without usage 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?

No annotations exist, so description must disclose behavior. It only states contradictory actions (delete vs create) and lists parameters but does not explain what happens on invocation (e.g., irreversible, permissions needed, success/failure conditions). Self-contradiction reduces transparency.

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: contradictory first lines, then a parameter list. Not front-loaded with key purpose. Redundant and confusing.

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?

Despite having an output schema, the description only says '@return: a json object'. No mention of what the output contains (e.g., confirmation, error codes). For a deletion tool with essential parameters, it lacks completeness. Also fails to clarify destructive nature.

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?

Despite schema coverage at 0%, the description adds some meaning: it clarifies that account_fk is a database ID not an address and that beneficiary_id comes from /beneficiary/list. However, the confusing note about 'may be 0' and the overall contradictory context detracts. Score 3 for partial added value.

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 contradicts itself: first line says 'Deletes a beneficiary' but next line says 'Creates a beneficiary'. This is misleading and fails to clearly state the tool's purpose. The name suggests removal, but the description confuses.

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 like ai__beneficiary_add or ai__beneficiaries_list. No context about prerequisites or when not to use.

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 creation action and confirmation requirement, and warns about token loss, but does not detail other behavioral traits like reversibility, cost, or idempotency.

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 has a duplicate line ('Creates a blockchain to blockchain bridge.') and includes a parameter list with pseudo-tags. While front-loaded, it could be more concise by removing 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?

Given the tool's complexity (8 parameters, 6 required) and presence of an output schema, the description covers purpose, usage, and parameters well. It could benefit from more context on obtaining authentication tokens, but overall it is adequately complete.

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%, yet the description provides detailed explanations for each parameter (e.g., account_fk is a database ID, blockchain values, alias default). This fully compensates for the lack of schema 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 'Creates a blockchain to blockchain bridge' with a specific verb and resource. It also specifies that only USDC transfers are supported, distinguishing it from sibling tools like ai__bridge_delete or ai__bridge_list.

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 advises to 'Confirm (yes/no) before executing' and warns 'Only supports USDC transfers. Do not send any other tokens as these may be lost.' This provides context for when to use the tool, though it does not explicitly compare with other bridge-related 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 exist, so the description must fully disclose behavior. It states the tool 'deactivates' the bridge but does not clarify if this is reversible, what side effects occur, or any authentication requirements beyond the listed parameters. The word 'deactivates' may differ from 'delete' as per the tool name.

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 contains a repetition of 'Deactivates the Bridge' in the first two lines, which is unnecessary. The parameter list is well-structured with @param tags.

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?

The description covers the core action and parameter sources, and an output schema exists to define return values. However, it lacks operational context such as error handling, reversibility, or impact on related entities, making it minimally complete for a destructive 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%, but the description provides clear, source-aware descriptions for all four required parameters (e.g., 'The api key allocated to your application', 'The bridge's unique reference, found on /bridge/list'), adding significant value beyond the input 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 'Deactivates the Bridge' which indicates the verb and resource. It is distinct from sibling tools like ai__bridge_list and ai__bridge_rename, but the repetition of the same phrase is redundant.

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 mentions 'Confirm (yes/no) before executing' which provides a usage guideline for requiring confirmation, but it does not specify when to use this tool versus alternatives or any prerequisites beyond the parameter sources.

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 description must fully disclose behavior. It mentions bridge availability only on blockchain accounts and defines transfer types, but no side effects, error scenarios, or rate limits. Return is described only as 'a json object'.

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?

Contains redundant explanations (bridge definitions repeated twice). Parameter descriptions integrated into a single block make it slightly less scannable. 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?

Parameter details are thorough, but missing context on usage in a workflow, empty results, error handling, or prerequisite checks. Output schema exists so return values not needed, but overall completeness moderate.

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?

Adds extensive meaning beyond bare JSON schema: explains source of api_key/token, identifies wallet_fk and account_fk as database IDs, detailed allowed values for transfer_type. Compensates fully for 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?

Clearly states it returns bridges filtered by transfer_type, and defines what bridges are. Distinguishes from sibling tools like ai__bridges and specific bridge tools by emphasizing the filtering parameter.

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?

Implies usage via transfer_type filter but does not explicitly tell when to use this tool vs alternatives like ai__bridge_on_ramp. No when-not or contextual guidance 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?

No annotations provided, so description must fully disclose behavior. It states the tool creates (write) and mentions a confirmation step, but does not explain what happens after creation (e.g., return structure, reversibility, required permissions). Missing details on side effects or error handling.

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?

Description contains duplicated sentence ('Creates a blockchain... support both ACH/WIRE') and grammar errors. The @param block is lengthy but necessary. Could be restructured with clearer separation of summary 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?

With 16 parameters and no annotations, the description covers param meanings but lacks broader context: no explanation of return JSON, confirmation process, error scenarios, or usage constraints. Incomplete for a complex financial 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 @param documentation adds significant meaning. It explains each parameter's purpose, type, defaults, and possible values (e.g., destination_rail values, account_fk is int not address). Some minor inconsistencies (typo in destination_rail example) but largely effective.

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?

Clearly states it creates a blockchain to FIAT off-ramp in the USA supporting ACH/WIRE, distinguishing it from sibling tools like bridge_off_ramp_sepa (Europe) and bridge_on_ramp. The verb 'creates' and specific networks make purpose unambiguous.

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?

Mentions 'Confirm (yes/no) before executing' but does not explain when to use this tool vs alternatives (e.g., when to choose ACH vs Wire, or when to use bridge_off_ramp_sepa). No prerequisites or exclusions 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 empty annotations, the description must disclose behavior. It says 'creates' (a mutation) but lacks details on side effects, required permissions, or what happens if confirmation is skipped. Returns only 'a json object'.

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 lengthy due to embedded parameter docs and contains repetition (first two lines essentially same). Could be more concise while still covering 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 19 parameters and an output schema (present but not shown in context), the description provides enough to use the tool but lacks details on return values or error handling. Adequate but not comprehensive.

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's inline @param annotations add substantial meaning beyond the schema, explaining each parameter's purpose and 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 creates a blockchain (USDC) to FIAT off-ramp in Europe for SEPA supporting bank accounts, with a specific verb and resource. It distinguishes from siblings like off_ramp_ach_wire and on_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 mention of 'Confirm (yes/no) before executing' hints at a safety step but provides no explicit guidance on when to use this tool vs alternatives like SEPA or ACH. No 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, the description carries the burden of behavioral disclosure. It notes a confirmation step ('Confirm (yes/no) before executing') and a per-rail limit, but does not disclose side effects, required permissions, rate limits, or whether the operation is reversible. The return value is described only as 'a json object'.

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 starts with a clear purpose and includes a confirmation note. However, it is slightly repetitive (the first sentence appears twice) and the param list is lengthy. It is structured but 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 that an output schema exists (though not shown), the description adequately covers creation details. It includes caveats like the per-rail limit and parameter specifics. It could be more complete by noting potential error states or idempotency, but is sufficient for 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?

Despite 0% schema coverage, the description provides extensive @param documentation for all 9 parameters, including possible values (e.g., blockchains, currencies, rails) and clarifications (e.g., account_fk is a database ID not address). This fully compensates for the schema's lack of descriptions. Minor deduction for not specifying format of some fields like address.

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 'Creates a virtual account (SEPA/ACH/WIRE) to blockchain bridge' with specific verb and resource. It distinguishes from sibling tools like ai__bridge_delete, ai__bridge_list, and off-ramp variants by focusing on creation and on-ramp direction.

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 mentions 'Limited to one virtual account per payment rail', which provides some usage context. However, it lacks explicit guidance on when to use this tool versus other bridge tools (e.g., ai__bridge_off_ramp_ach_wire) and does not state prerequisites or when not 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?

No annotations provided, so the description must cover behavior. It mentions a confirmation requirement but lacks details on effects, reversibility, or error conditions. The @return statement is vague.

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 short but contains a redundant repetition of the first sentence. The @param list is structured. Could be more concise by removing the duplicate 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?

Covers purpose and parameter origins but lacks behavioral depth (e.g., what happens on success/failure, if confirmation is simulated). With no annotations and 5 params, it's adequate but not comprehensive.

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 explains each parameter well, including sources like '/access/login' and '/bridge/list'. However, it omits constraints on the alias (e.g., length, characters).

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 'Changes the Bridge's descriptive name' with a specific verb and resource. It distinguishes itself from sibling tools like ai__bridge_delete (delete) and ai__bridge_list (list).

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 vs. alternatives. The mention of 'Confirm (yes/no) before executing' hints at a required step but doesn't specify when it's appropriate or provide 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, the description must fully disclose behavioral traits. It says the tool returns a list of tools and references a schema, but does not explicitly state that it is a read-only, non-destructive operation. There is no mention of side effects, permissions, or limitations. The agent lacks clear safety context.

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 short and front-loaded with the main purpose. However, it contains a typo ('tools' should be 'tool') and a redundant mention of the return value. It is mostly efficient but could be more polished.

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 presence of an output schema, the description does not need to fully detail the return format, but it should be consistent. The mix of 'list of tools' and 'schema' creates slight ambiguity. For a simple, parameterless tool, the description is adequate but lacks clarity on the exact output structure.

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 zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it correctly omits any. The schema coverage is 100% due to absence of 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 that the tool returns a list of tools related to bridges, off-ramps, on-ramps, etc. However, it introduces ambiguity by also mentioning a schema and a return value, which could confuse the agent about the actual output format. It distinguishes from sibling bridge tools by being a meta-listing tool, but this is not explicitly stated.

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 like ai__bridge_list (which likely lists bridge entities) or other bridge-related tools. No when/when-not or alternative tools are mentioned, leaving the agent to infer usage.

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