Fuse Network

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

With no annotations, the description discloses signing/submitting behavior and conditional return of deployed address, but omits details like gas costs, failure modes, or the fact that server signer requires prior setup.

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?

Single sentence, directly conveys essential action (signs/submits) and key conditional return. 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 no output schema, the description explains both return scenarios (hash only vs. hash+address). It does not explain potential errors or prerequisites, but for a straightforward deployment tool this is largely sufficient.

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 100%, so baseline is 3. The description does not add new meaning beyond the schema explanations for parameters like bytecode, abi, args, etc.

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 signs and submits a contract-deployment transaction, specifies return values (hash, conditional address), and distinguishes from sibling tools like read/write contract which operate on existing contracts.

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 such as fuse_send_native or fuse_write_contract. The description does not mention prerequisites, ideal scenarios, 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 provided, so description must disclose traits. It mentions covering POST routes and required parameters but does not discuss rate limits, auth, error handling, or response format. Adequate but not detailed.

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 concise, listing endpoint categories in one sentence. Could be improved with bullet points or clearer structure, but 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?

With no output schema, the description does not explain the return value format or behavior for different endpoints. For a generic tool, more context on response structure would improve completeness.

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

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

Schema coverage is 100% and already describes parameters well (e.g., detailing 'params' to omit module/action/apiKey). The description adds minimal new semantic value beyond restating 'module + action + additional params'.

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 is a generic dispatcher for the Fusebox Explorer API, covering 40+ etherscan-compatible endpoints. It lists specific categories (balances, logs, transactions, etc.), distinguishing it from sibling tools like fuse_get_balance which 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?

The description explains how to use the tool (pass module, action, params) but does not provide guidance on when to prefer it over dedicated sibling tools. Given many siblings, explicit when-to-use or when-not-to-use advice 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?

With no annotations provided, the description bears full responsibility for behavioral disclosure. It clearly states this is a read-only operation ('Reads'), which implies no side effects. It also honestly notes a feature gap (paymaster eligibility not evaluated). However, it does not mention error conditions or authorization requirements, but for a simple read tool, this is adequate.

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

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

Two sentences, no wasted words. The first sentence immediately states the purpose and outputs. The second sentence clarifies a limitation. 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?

Despite no output schema, the description clearly enumerates return values (deployment status, nonce, deposit balance). It also captures a limitation. With only 2 parameters and a simple read operation, the description provides all necessary context for an agent to use the tool correctly.

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 100%, and both parameters have descriptions. The description adds value by explaining what the tool returns (deployment status, nonce, deposit balance), which helps agents understand the parameter semantics in context. The nonceKey parameter's hex/decimal format is already in the schema, but the description ties it to EntryPoint nonce.

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 specifies a precise verb ('Reads'), a clear resource ('ERC-4337 state for a smart account on Fuse'), and lists the exact data returned (deployment status, nonce, deposit balance). It also distinguishes itself by noting what it does not do (paymaster eligibility not evaluated). This clarity differentiates it from sibling tools like 'fuse_smart_get_info' or 'fuse_get_user_operations'.

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

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

The description implies use cases: checking ERC-4337 account state. It provides a clear context for when to use this tool, but does not explicitly mention when not to use it or name alternative tools. The limitation about paymaster eligibility helps set expectations.

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 carry the burden of behavioral disclosure. It only states what the tool returns, without mentioning any safety traits (e.g., read-only), potential errors, rate limits, or other behavioral aspects. For a read-only query, this is minimal 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 a single, concise sentence that is front-loaded with the main purpose. It contains no unnecessary words and efficiently conveys the tool's functionality.

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 (two parameters, no output schema), the description is fairly complete. It covers the core functionality and parameter usage. It does not describe the return format or error conditions, but for a balance query, these are not critical omissions.

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 100%, so baseline is 3. The description adds meaning by explicitly stating that tokenAddress is optional and that omitting it fetches the native balance, which clarifies the parameter's role beyond the 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 it returns the native FUSE balance or an ERC-20 token balance for an address. It uses a specific verb 'returns' and identifies the resource 'balance'. It distinguishes between native and token balances via the optional tokenAddress parameter, which differentiates it from sibling tools that perform other operations.

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

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

The description implies when to use the tool (to get a balance), but it does not explicitly state when not to use it or mention alternatives among the many sibling tools. However, the purpose is clear enough that an agent can infer this is the appropriate tool for balance queries.

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 convey behavioral traits. It indicates a read operation by stating 'Returns,' but does not explicitly mention that it is non-destructive or safe to call arbitrarily.

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 a single concise sentence that front-loads the core purpose. Every word provides value without 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 no parameters and no output schema, the description fully explains what the tool returns (gas price in wei/gwei, EIP-1559 suggestions). There are no missing details needed for correct 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?

There are zero parameters (schema coverage 100%), so the baseline is 4. The description adds no parameter info but does specify the output format (wei and gwei) and EIP-1559 details, which is valuable context 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 the verb 'Returns', the resource 'Fuse network gas price', and specifies units (wei and gwei). It also highlights EIP-1559 fee suggestions, distinguishing it from other Fuse 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 explicit when-to-use or when-not-to-use guidance is provided. However, the tool has no parameters and is straightforward, so the lack of guidelines is acceptable but not ideal.

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. Lists returned fields and null behavior, but does not explicitly state read-only nature, authentication needs, or side effects. Adequate but could be more explicit about safety.

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

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

Two concise sentences with no wasted words. Front-loaded with primary purpose and includes important edge case (null return).

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 single-parameter tool with no output schema, the description covers the key behavioral aspects: what is fetched, when it returns null, and typical receipt fields. Complete for its complexity.

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 100%, and the tool description does not add additional meaning beyond what the schema already provides for the 'hash' parameter. Baseline 3 applies.

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 specifies the verb 'fetches', the resource 'receipt for a mined transaction', and lists included fields (status, gasUsed, logs). Distinguishes from sibling tools like fuse_get_transaction by focusing on receipt details.

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 when to use (after transaction is mined) and explicitly states null return for pending/unknown transactions. Provides clear context but does not explicitly exclude alternatives or mention 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?

No annotations provided; the description does not explicitly state that the tool is read-only or safe, though it is implied. Without annotations, behavioral disclosure is insufficient.

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

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

Two concise sentences that front-load the purpose and usage. Every sentence earns its place.

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, no output schema, and simple read behavior, the description fully covers what an agent needs: what it returns and when to use it.

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; schema coverage is trivially 100%. The description adds value by explaining the purpose of the return value without needing to describe params.

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 returns the EOA address controlled by the server's configured private key, and distinguishes it from sibling tools by specifying its role as a pre-write check.

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?

Explicitly advises using this tool before any write tool to confirm the gas-paying account. While it doesn't list when not to use it, the guidance is clear and context-specific.

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 present, so the description must cover behavioral aspects. It implies a read operation ('Returns') but does not explicitly state it is non-destructive, nor does it mention authorization, rate limits, or edge cases (e.g., empty wallet). The behavior is partially disclosed but lacks sufficient detail.

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 two sentences, both essential. The first sentence front-loads the purpose and output details. The second sentence adds source context. No unnecessary words, highly efficient.

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

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

Given no output schema, the description adequately explains the return structure (positions with specific fields). It covers the key elements needed for a query tool with one parameter. Minor gaps: no mention of pagination or error handling, but these are not critical for this simple 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 coverage is 100% with one parameter described. The description adds value by explaining what the tool returns (staked amount, USD value, etc.), which helps the agent understand the output even without an output schema. The description of the parameter itself matches the schema, but the additional output context elevates it above baseline.

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 'Returns' and the resource 'active staking positions for a wallet', listing specific outputs (staked amount, USD value, earned rewards, APR). It distinguishes from siblings like 'fuse_get_staking_options' (returns options) and 'fuse_smart_stake_token' (performs staking).

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. No explicit context about when it is appropriate or when to avoid it. The mention of 'Powered by the Fusebox SDK StakingModule' is generic and does not differentiate usage.

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 bears full burden. It correctly indicates this is a read-only listing operation and mentions the SDK powering it, but does not disclose any edge cases, rate limits, or authentication requirements. Adequate for a simple list tool.

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

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

The description is two compact sentences with no filler. The first sentence clearly states the action and scope; the second adds technical context without 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 no parameters and no output schema, the description adequately explains what the tool returns. It could mention if the list is paginated or sorted, but for a straightforward list, it is complete enough.

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 schema coverage is 100% by default. The description adds value by listing the output fields (token, APR, TVL, expiry, unstake token), even though no parameter details are needed. Baseline score of 4 is appropriate.

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 lists every staking option with specific attributes (token, APR, TVL, expiry, unstake token). It is distinct from sibling tools like fuse_get_staked_tokens (which lists user's staked tokens) and fuse_smart_stake_token (which performs staking).

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or conditions under which this tool is appropriate.

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?

Without annotations, the description clearly states it is a read operation, implying no side effects or destructive actions. However, it could be improved by noting behavior on missing tokens or error conditions.

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

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

The description is a single concise sentence with no superfluous words, effectively communicating the tool's 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?

No output schema is provided, but the description explicitly names the returned fields (name, symbol, decimals, totalSupply), giving a complete picture of the output. For a simple one-parameter tool, this is sufficient.

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 100% with a clear description for tokenAddress. The tool description does not add additional parameter semantics beyond the schema, but the schema itself is sufficient.

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 'Reads' and explicitly lists the fields (name, symbol, decimals, totalSupply) for an ERC-20 token on Fuse, clearly distinguishing it from sibling tools like fuse_get_balance or fuse_get_token_price.

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 is purely functional and does not mention any prerequisites, alternatives, 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?

Since no annotations are provided, the description carries full behavioral burden. It notes the tool is powered by Fusebox SDK TradeModule and implies a read-only operation with 'Returns'. However, it does not disclose potential side effects, authentication needs, rate limits, or what happens if the token is not tracked.

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 two sentences with no redundant information. The key purpose and a distinguishing detail (tracked tokens) are front-loaded. Every sentence earns its place.

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 read operation with one parameter and no output schema, the description covers the core purpose and a relevant constraint. However, it could be more complete by specifying the return value format (e.g., decimal, string) or clarifying that it returns the price in USD.

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 only parameter, tokenAddress, has a clear schema description. The description adds value by specifying that only tokens tracked by Fusebox are supported, which is extra context 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 the tool returns the current USD price for an ERC-20 token tracked by Fusebox. The verb 'Returns' and resource 'USD price for an ERC-20 token' are specific. It distinguishes from sibling tools like fuse_get_token_price_history and fuse_get_token_price_change, which deal with historical or change data.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is only for current prices, nor does it reference sibling tools for history or changes. The user must infer usage context 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?

With no annotations, the description must disclose behavioral traits. It only states the basic functionality and a powered-by note. It omits details like error handling for untracked tokens, rate limits, or that it's a read-only operation. For a simple data retrieval, this is insufficient.

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 two sentences with the key information in the first sentence. The second sentence about Fusebox SDK is slightly extraneous but not wasteful. It is efficiently structured but could be trimmed.

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 tool with one parameter and no output schema, the description covers the basic purpose and input. However, it does not specify the return format (e.g., a number or string with percentage), leaving the agent uncertain about the 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?

Schema description coverage is 100%, so the description adds no additional semantics for the tokenAddress parameter beyond what the schema already provides. The description's mention of 'ERC-20 token tracked by Fusebox' is only implicit context, not a parameter detail.

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 'Returns' and specifies the resource: '24-hour percentage price change for an ERC-20 token tracked by Fusebox'. It effectively distinguishes from sibling tools like fuse_get_token_price (current price) and fuse_trade_price_change_over_duration (custom duration).

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 over siblings. It does not mention alternatives or constraints (e.g., token must be tracked by Fusebox). The agent lacks context for tool selection.

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

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

No annotations provided. Description lacks behavioral details such as rate limits, authentication requirements, error handling (e.g., invalid token address), or response format beyond OHLC. Only states it returns stats, not how the tool behaves.

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?

Single sentence, no fluff. Could be improved by adding usage guidance without increasing length significantly. Efficient but missing some value.

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

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

No output schema, no annotations. Description does not explain return format (structure of OHLC data), data limits, or what happens if no data for token. Incomplete for a historical data 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 coverage is 100% with descriptions for both parameters. Description adds context that timeFrame values correspond to granularity/range and that data is from Fusebox SDK, but no additional syntax or constraints beyond schema. Baseline 3 is appropriate.

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 verb 'Returns', resource 'OHLC / interval price stats for an ERC-20 token', and scope 'over a week, month, or year'. Distinguishes from sibling tools like fuse_get_token_price (current price) and fuse_get_token_price_change (price change).

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?

Description does not explicitly state when to use this tool vs alternatives. It mentions 'Powered by the Fusebox SDK TradeModule' but no guidance on context or exclusions. Usage is implied through the resource name, but not explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool is read-only and powered by a SDK module, but lacks details on error handling, time sensitivity of quotes, or any required permissions. The level of transparency is adequate but not thorough.

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 at two sentences, with no fluff. Key information (read-only, what it returns) is front-loaded, making it easy to scan.

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 lack of an output schema, the description only vaguely mentions expected output, route, and price impact. It does not detail the response structure, which limits completeness for an agent that needs to parse the result.

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 100% description coverage, so the schema already explains each parameter. The description does not add new meaning beyond the schema, maintaining the baseline score of 3.

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 the verb 'quotes' to clearly state the tool's core action on a 'token swap' resource, and specifies the returned information: expected output amount, route, and price impact. It distinguishes itself as read-only, separating it from submission tools like fuse_smart_swap_tokens.

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

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

The description explicitly labels the tool as 'Read-only' and states it returns a quote without submitting a trade, which guides when to use it (for previewing a swap). However, it does not explicitly mention when not to use it or provide alternatives among the many sibling tools.

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

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

With no annotations, the description carries the full burden. It clearly discloses the null return on not found, indicating a non-destructive read operation. However, it doesn't discuss rate limits, permissions, or other behavioral traits, but the key behavior is covered.

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: one sentence stating the purpose and a second sentence clarifying the behavior. No wasted words, front-loaded with the action.

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 tool with one parameter, no output schema, and no annotations, the description covers the essential: what it does, the input, and the null return. It could mention the return structure but is sufficient for agent 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?

The schema provides 100% coverage for the single parameter 'hash' with a description. The tool description adds 'by hash' which aligns but doesn't provide additional meaning beyond the schema. Baseline score of 3 is appropriate.

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 ('Fetches a transaction by hash') and specifies the resource and method. It also explicitly states the behavior when not found ('Returns null'). This distinguishes it from siblings like fuse_get_receipt.

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

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

The description provides minimal guidance on when to use this tool. It implies usage for fetching a transaction by hash but does not mention alternatives or when not to use it. For a simple getter, this is adequate but lacks explicit context.

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

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

No annotations provided, so the description must carry behavioral disclosure. It does not mention side effects (likely none), pagination, rate limits, or authentication requirements. The mention of Fusebox GraphQL service gives tech context but lacks operational detail.

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

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

Two sentences, no filler. Front-loads the purpose. Every word earns its place.

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 read tool with one parameter and no output schema, the description is adequate but could be more complete (e.g., mention output format or pagination). It provides the essential context without being verbose.

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 100% for the single parameter 'sender', with a clear description. The tool description adds no extra info beyond the schema. Baseline 3 is appropriate.

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 returns ERC-4337 UserOperation history for a smart account on Fuse, specifying the exact resource and network. It distinguishes itself from siblings like fuse_get_transaction or fuse_get_balance by focusing on UserOperations.

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., fuse_explorer_query for broader queries). No prerequisites or exclusions mentioned. Purely declarative.

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 being 'Powered by the Fusebox SDK TradeModule' but does not disclose whether authentication is required, rate limits exist, or what side effects (none expected) occur. For a read-only tool, minimal transparency 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 is two sentences with no filler. The first sentence defines the core function and qualifiers; the second provides source context. Every word earns its place.

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 no output schema, the description is brief. It does not specify the output format (e.g., list of token addresses, symbols), pagination, or whether authentication is needed. For a simple list tool, it is minimally adequate but could provide more detail on the return 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 input schema has zero parameters and schema coverage is 100%, so baseline is 4. The description adds context by explaining that the returned catalogue includes tokens that are 'tradable, indexed, priced', which adds meaning beyond the empty 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 the catalogue of ERC-20 tokens tracked by Fusebox (tradable, indexed, priced).' It specifies the verb (returns) and resource (catalogue of ERC-20 tokens), with qualifiers that distinguish it from sibling tools like 'fuse_get_token_price' or 'fuse_list_wallet_tokens'.

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

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

The description implies usage for obtaining a list of supported tokens but provides no explicit when-to-use guidance or alternatives. It does not differentiate from similar tools such as 'fuse_list_wallet_tokens' which lists user wallet tokens rather than the full catalogue.

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 disclose behavior. It mentions 'Powered by the Fusebox SDK BalancesModule' but does not explain rate limits, authentication needs, or what happens for wallets with no NFTs. Lacks details on output format or pagination.

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

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

Two concise sentences with no wasted words. Front-loaded with action and resource. Efficiently communicates the tool's 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?

For a simple list tool with one parameter and no output schema, the description is adequate but not fully complete. It does not specify return format, field details, or any limitations beyond the purpose.

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

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

Schema coverage is 100% (one parameter well-described in schema). The description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate.

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 NFTs (ERC-721/ERC-1155) owned by a wallet on Fuse. The verb 'lists' and resource 'wallet NFTs' are specific, distinguishing it from sibling tool fuse_list_wallet_tokens which lists ERC-20 tokens.

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

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

No guidance on when to use this tool vs alternatives like fuse_get_balance or fuse_list_supported_tokens. Does not mention prerequisites, limitations, 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 are provided, so the description carries the full burden. It states the tool lists tokens with enriched metadata, implying a read-only operation. However, it does not discuss potential side effects, authentication requirements, or rate limits. The description adds context about the Fusebox metadata but could be more explicit about being read-only and safe.

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

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

Two sentences effectively convey the tool's purpose and technology. Every sentence adds value without repetition or unnecessary details. The structure is front-loaded with the core functionality.

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 low complexity (single parameter, listing operation) and no output schema, the description adequately explains what the tool returns (token list with symbol, decimals, USD value). It is complete enough for an agent to make an informed decision, though it could explicitly state the output format (e.g., array).

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 100% with a clear description for the single parameter 'walletAddress'. The description does not add additional parameter-level detail beyond what the schema already provides, so it meets the baseline without adding extra 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 that the tool lists all ERC-20 tokens held by a wallet on Fuse, enriched with metadata. This distinguishes it from siblings like 'fuse_get_balance' (single token) and 'fuse_list_supported_tokens' (all supported tokens, not held). The verb 'lists' and resource 'ERC-20 tokens held by a wallet' 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?

The description implies usage when a full portfolio of ERC-20 tokens with enriched metadata is needed, but it does not explicitly state when not to use it or compare with alternatives like 'fuse_get_balance' for a single token. No exclusions are provided, leaving the agent to infer context from sibling tool 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?

Only discloses the required API key. No information about idempotency, whether addresses are appended or overwritten, validation, rate limits, or side effects. With no annotations, the description should cover these aspects.

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, but it omits crucial details like return value and behavior. It is concise but insufficient for full understanding.

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 tool with few parameters and no output schema, the description is adequate but lacks context about prerequisites, error handling, and return value. Does not mention that the webhook must already exist.

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 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions; it merely restates that addresses are added.

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 the action: adding EVM addresses to a webhook's listening scope. Uses a specific verb and resource, and distinguishes from sibling tools like remove_addresses and create_webhook.

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. Does not mention prerequisites like having a webhook created first, nor does it explain when to use this instead of update_webhook or remove_addresses.

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

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

No annotations are provided, so the description carries full burden. Only authentication details are disclosed. The description does not mention idempotency, conflict handling (e.g., if webhook already exists), response format, or other behavioral traits. This is insufficient for a mutation tool.

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

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

Two sentences, front-loaded with purpose. Every sentence adds value (purpose and authentication). No unnecessary 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?

For a simple tool with 3 parameters and no output schema, the description provides purpose and auth but omits return value, error conditions, or validation details. 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 coverage is 100%, with each parameter already described in detail. The description adds no additional meaning beyond the schema, achieving the baseline of 3.

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 'Create', the resource 'Fusebox Notification webhook', and the context 'for a project'. This distinguishes it from sibling tools like delete, get, list, update, and others.

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

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

The description includes a prerequisite (authentication requirement) but does not provide explicit guidance on when to use this tool vs alternatives like update or delete. Usage context is implied by the verb but not explicitly 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 clearly discloses that deletion is permanent, destructive, and stops event delivery. It also specifies a required authentication context (FUSEBOX_SECRET_API_KEY), exceeding minimal requirements.

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

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

Two concise sentences: the first states the action and resource, the second adds critical warnings. No unnecessary words, 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?

For a simple tool with one parameter, no output schema, and clear warning about destructiveness, the description covers all needed context. No gaps remain.

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 single parameter 'webhookId' is fully documented in the schema (100% coverage). The description adds no additional meaning beyond the schema's description, meeting the baseline.

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 "delete" and the resource "webhook", and specifies it is permanent and destructive. It distinguishes from sibling notification tools (create, update, get, list) by focusing on removal.

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 that the action is destructive and stops events, implying when to use (when permanent removal is needed) and when not to (if webhook is still needed). However, it does not explicitly mention alternatives like disabling via update_webhook.

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 disclose behavioral traits. It states a requirement (API key) but does not explicitly confirm that the operation is read-only or side-effect-free. The name implies a read operation, but the description should reinforce that to ensure safe invocation.

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, no filler, front-loaded with the core action. Every word adds value.

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

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

The tool has no output schema, so the description should explain what is returned (e.g., the webhook configuration details). It fails to do so, leaving the agent uncertain about the response format. Combined with missing behavioral transparency, the description is incomplete for a safe and effective 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?

The input schema has 100% coverage for the single parameter 'webhookId', already describing it as 'Webhook ID to retrieve.' The description adds no further meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the action 'Retrieve details of a single Fusebox Notification webhook', specifying the verb and resource. It distinguishes this tool from siblings like 'fuse_notification_list_project_webhooks' and 'fuse_notification_create_webhook' by focusing on a single webhook retrieval.

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 over alternatives. The description mentions a required API key but omits context such as 'Use this when you have a specific webhook ID, as opposed to listing all webhooks.' This leaves the agent without decision support.

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 disclose all behavioral traits. It only states it lists addresses and requires an API key. It does not mention if the operation is read-only, pagination behavior, or error handling. Minimal disclosure for a tool that could have rate limits or authorization constraints.

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 two sentences long, front-loaded with the core purpose, and contains no filler. Every sentence adds value.

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

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

Given the low complexity (one parameter, no output schema) and lack of annotations, the description provides the essential information. However, it could be more complete by hinting at the return format (list of EVM addresses) or mentioning potential errors (e.g., invalid webhook ID).

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 sole parameter, `webhookId`, is well-described in the schema (100% coverage). The description does not add extra meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action ('List'), the specific resource ('every EVM address monitored by a given webhook'), and the scope (per webhook). This distinguishes it from sibling tools like `get_webhook` and `add_addresses`.

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 required API key, setting a prerequisite, but it does not explicitly guide when to use this tool versus alternatives (e.g., when to list vs. get webhook details). Given the large set of sibling tools, more contextual guidance would be beneficial.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists webhooks (a read operation) and requires an API key, but does not disclose error handling, pagination behavior, or what happens if the project does not 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?

Two sentences: first states the purpose, second states a requirement. No unnecessary words. Information is front-loaded and every sentence earns its place.

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 is simple (1 required param, no output schema, no annotations). The description covers the basic purpose and a key prerequisite. However, it does not describe what the response contains (e.g., list of webhook objects) or any constraints like rate limits, which would help the agent interpret results.

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 covers 100% of parameters with descriptions (projectId: 'Project ID whose webhooks should be listed.'). The description adds minimal extra context ('for a given project'), so it does not significantly enhance understanding 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 'List every Fusebox Notification webhook configured for a given project.' It uses a specific verb ('List') and resource ('webhooks') and distinguishes from sibling tools like fuse_notification_create_webhook and fuse_notification_get_webhook by specifying 'list' and 'for a given project'.

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 prerequisite ('Requires FUSEBOX_SECRET_API_KEY') but provides no guidance on when to use this tool vs alternatives (e.g., fuse_notification_list_addresses) or when not to use it. The usage context is implied but not explicitly 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?

No annotations are provided, and the description only mentions an API key requirement. It does not disclose side effects, error cases, idempotency, or what happens if addresses are not monitored. This is insufficient for a modification operation.

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

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

The description is a single short sentence plus a requirement, no wasted words. It is concise and front-loaded with the main action.

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 tool with two required parameters and no output schema, the description is adequate. It states what it does and a key requirement, though some behavioral details (e.g., preconditions) are missing.

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 100%, so the schema already describes both parameters. The description adds no additional meaning beyond what is in the schema, so baseline 3 is appropriate.

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 'Remove EVM addresses' from the resource 'webhook's listening scope'. It uses a specific verb and resource, and distinguishes from sibling 'fuse_notification_add_addresses' by 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 includes a prerequisite (requires API key) and implies usage for removing addresses, contrasting with add_addresses. However, it does not explicitly state when not to use this tool or provide direct comparison.

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

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

No annotations are provided, so the description must convey behavioral traits. It indicates a mutation operation and a required API key, but does not disclose error handling, idempotency, or consequences of updates. With no annotations, this minimal disclosure is adequate but not thorough.

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 a single concise sentence that immediately states the action and subject, followed by a critical requirement. No unnecessary words; highly efficient.

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

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

Given no output schema, the description does not mention return values or confirmation of the update. It also does not specify prerequisites like webhook existence. For a simple update tool, some context is missing, but the sibling tools provide related context.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds the external requirement of an API key but no parameter-specific details beyond what the schema already provides. The schema's descriptions are clear, so the description does not significantly enhance parameter semantics.

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 'Update' and the resource 'webhook', specifying that it updates URL or event type. This distinguishes it from sibling tools like create, delete, and get webhook.

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

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

The description implies usage for updating webhook settings and mentions a required API key, providing clear context. However, it lacks explicit guidance on when not to use or alternatives for related actions like creating or listing webhooks.

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

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

With no annotations, the description carries full burden. It discloses the auto-fetching of ABI from the explorer, a useful behavioral trait. But it omits other behaviors like error handling, return value format, or permissions. Adequate but not comprehensive.

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

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

The description is a single, well-placed sentence. It front-loads the primary action and adds the key detail about ABI auto-fetch without any 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 4 parameters and no output schema, the description covers the core action and a notable feature but lacks essential context like return value, error scenarios, or prerequisites. It is sufficient for basic use but not fully 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 coverage is 100%, so baseline is 3. The description does not add new meaning beyond the schema; it repeats the ABI auto-fetch that is already documented in the 'abi' parameter schema. No additional parameter insights.

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 'calls a view/pure function on a Fuse contract', specifying the exact verb and resource. It distinguishes itself from sibling 'fuse_write_contract' by emphasizing the 'view/pure' nature, indicating read-only behavior.

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

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

The description provides clear context that the tool is for read-only contract calls (view/pure functions), telling when to use it. However, it does not explicitly exclude write operations or mention alternatives, missing the 'when-not-to-use' 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?

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: ENS is not deployed on Fuse, resolution requires an external RPC URL, and plain addresses are passed through unchanged. This provides sufficient transparency for safe usage.

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

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

Two sentences, front-loaded with the core purpose. Every sentence adds essential information (purpose, configuration requirement, pass-through behavior). No unnecessary words. Highly efficient.

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

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

For a simple resolver with one parameter and no output schema, the description is complete. It covers the tool's action, its operational context (ENS not on Fuse, requires config), and edge-case handling (pass-through). No gaps remain.

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 with a description, and the tool description adds context about the name parameter (e.g., plain addresses are returned unchanged). Schema coverage is 100%, so the description adds value beyond the schema by clarifying edge-case behavior.

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 resolves an ENS name to an EVM address, with a specific verb ('resolves') and resource ('ENS name'). It distinguishes itself from sibling tools (e.g., fuse_get_balance, fuse_send_native) by focusing on name resolution, not blockchain transactions.

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 explains when to use the tool (resolve ENS name) and that plain hex addresses are passed through unchanged. It mentions a prerequisite (ENS_RPC_URL configuration) but doesn't explicitly state when not to use it or provide alternatives. This is adequate for a straightforward resolver.

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

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

With no annotations provided, the description bears full burden for behavioral disclosure. It mentions it is a signed transaction from the server's signer, indicating a write operation, but lacks details on gas costs, error handling, or transaction finality. While adequate, it could be more explicit.

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 two concise sentences, front-loaded with the core action, and contains no superfluous information. Every word earns its place.

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 output schema, the description fails to mention what the tool returns (e.g., transaction hash), leaving the agent uninformed about the result of the submission. Completeness is lacking for a write operation.

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

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

The description adds value beyond the schema by explaining that decimals are auto-fetched and how to skip scaling via 'unit: base'. For the 'amount' parameter, it reinforces the default unit behavior. This clarifies usage beyond the schema's enum and defaults.

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 submits a signed ERC20.transfer(to, amount) from the server's signer, specifying the verb 'sends' and resource 'ERC-20', which distinctly differentiates it from sibling tools like fuse_send_native or fuse_smart_transfer_token.

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 (e.g., for native tokens use fuse_send_native). It only provides guidance on the 'unit' parameter, missing 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?

The description discloses that the tool submits a signed transaction (implying irreversible transfer) and returns a transaction hash. No annotations exist, so the description carries the transparency burden. It does not mention auth requirements, rate limits, or the need for the server signer to have sufficient balance.

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 one clear sentence plus a helpful follow-up instruction. It is concise, front-loaded with the action, and contains no filler.

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 transaction tool with fully documented parameters, the description covers the main purpose, return value, and next steps. Could briefly note that the server signer must have sufficient funds, but overall it's sufficiently 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?

Input schema has 100% coverage, so parameters are already well-documented. The description adds minimal extra value by restating default unit behavior. Baseline 3 is appropriate.

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 (submits a signed transaction), resource (native FUSE), and action (transferring to a recipient). It distinguishes from siblings like fuse_send_erc20 and fuse_get_receipt, which handle different operations.

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

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

The description specifies when to use the tool (to send native FUSE) and provides a post-action recommendation (use fuse_get_receipt to confirm inclusion). However, it does not explicitly mention when NOT to use it or suggest alternative tools for different scenarios.

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 server-side signing, EIP-191 format, output as 65-byte hex, and that no transaction occurs. It does not discuss idempotency, rate limits, or authentication, but these are reasonable for a signing tool. The transparency is strong but not exhaustive.

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?

Three sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value: action, output format, and key behavioral note.

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 two parameters with full schema coverage, no output schema, and no annotations, the description is complete. It explains input encoding, output format, and side-effect (no transaction), which is all the agent needs to select and invoke correctly.

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 100%, but the description adds meaningful context: it clarifies that message is UTF-8 by default and provides the hex encoding option for raw bytes with the expected format ('0x-prefixed'), going beyond the schema's brief descriptions.

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

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

The description clearly states the verb 'sign', the resource 'message', and the standard 'EIP-191 (personal_sign)', distinguishing it from sibling tools like fuse_sign_typed_data and fuse_send_native (which submit transactions). It also specifies the output format (65-byte hex signature).

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

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

The description explicitly states 'No on-chain transaction is submitted', implying it is for off-chain signing. It does not explicitly mention when not to use it or suggest alternatives like fuse_sign_typed_data for typed data signing, leaving the agent to infer from 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 provided, so description carries burden. It discloses the output format (65-byte hex signature) and that no transaction is submitted, implying off-chain signing. Could mention authentication or key management, but adequate.

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

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

Two sentences covering purpose and key behavior. No unnecessary words. Front-loaded with key 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 no output schema and no annotations, description covers core functionality: signing, output format, off-chain nature. Could detail error scenarios or prerequisites, but sufficient for typical use.

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

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

Schema coverage is 100%, and description adds value by noting that EIP712Domain should be excluded from the types map (derived from domain). This helps avoid common errors. Other parameters are adequately described in 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 signs a structured EIP-712 payload and returns a 65-byte hex signature. It explicitly distinguishes from on-chain transactions, and the sibling list includes fuse_sign_message, implying this is for typed data.

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 explicit when-to-use or when-not-to-use guidance compared to sibling tools like fuse_sign_message. It only mentions no on-chain transaction, but no direct comparison 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?

No annotations provided, so description carries full burden. It mentions atomicity but does not disclose failure modes, error conditions, authorization requirements, or expected side effects beyond the basic operation.

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

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

Single 15-word sentence, front-loaded with verb and resource. Every word contributes 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?

No output schema exists, yet description does not hint at return value (likely a transaction hash or user operation hash). Also missing expected gas or revert behavior, though operation is well-known.

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 high (80%), so baseline is 3. The description does not add parameter-level detail beyond the schema; it only reiterates the composite action.

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 the tool atomically approves a token and calls the spender, which is a distinct composite operation. It differentiates from siblings like fuse_smart_approve_token and fuse_smart_call_contract by combining both steps.

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 context ('Common DeFi pattern') implying use cases like swaps or staking. However, it does not explicitly mention when to avoid this tool (e.g., if atomicity is not required) or alternatives like using separate approve and call 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 provided, and description only states it submits a UserOperation. Missing critical behavioral details: this is an on-chain transaction costing gas, requires smart wallet authentication, and side effect is granting approval.

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?

Single sentence, efficient and to the point. Could be improved by adding key behavioral information without becoming verbose.

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

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

No output schema, and description does not state return value (e.g., UserOperation hash). Also missing prerequisites like smart wallet authentication and gas implications for an ERC-4337 operation.

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

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

Schema coverage is 100%, and description adds no extra meaning beyond schema. Baseline 3 per instructions for high 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 verb (submits) and resource (UserOperation calling approve on NFT contract). Distinguishes from sibling tools like fuse_smart_approve_token (ERC20) by specifying NFT and ERC-4337 context.

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

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

Implies usage for NFT approval on smart wallets, but does not explicitly state when to use or avoid this tool compared to siblings like fuse_smart_approve_token or fuse_smart_approve_and_call.

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 reveals that it submits a UserOperation, implying a transaction that requires gas and is submitted to the blockchain. However, it does not disclose that authentication via the smart wallet is needed or that this is a write operation. Without annotations, more detail would be helpful.

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?

A single sentence that efficiently conveys the core action and mechanism. No unnecessary words, front-loaded with the 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?

For a 4-parameter tool with no output schema, the description is mostly complete. It lacks details about the return value (likely a UserOp hash) and prerequisites (wallet authentication), but the core function is well covered.

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 75% schema description coverage, the schema already explains amount, spender, and tokenAddress. The description adds context about the smart wallet, but the value 'above schema' is minimal. The 'unit' parameter is not described in the schema, and the description does not clarify it.

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: submitting a UserOperation to call ERC20.approve on a smart wallet. It distinguishes from siblings like fuse_smart_approve_nft and fuse_smart_approve_and_call.

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., fuse_smart_approve_and_call, fuse_smart_approve_nft). The description does not mention prerequisites or typical usage scenarios.

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 only states 'submits a UserOperation' and mentions the smart wallet, but lacks details on side effects, return values, prerequisites, or gas implications. This is insufficient for an agent to fully anticipate behavior.

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

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

Two sentences, no fluff. The action is stated first, then the usage guidance. Every word earns its place.

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 submits a complex UserOperation but omits key context: what is returned (e.g., UserOp hash), prerequisites (smart wallet configuration status), and failure behavior. Given the lack of output schema and annotations, the description should provide more context.

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

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

Schema coverage is 100% with each parameter already described (to, data, valueWei). The description adds no additional meaning beyond 'arbitrary calldata' and 'full control', so the baseline of 3 is appropriate.

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

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

The description clearly states the tool submits an ERC-4337 UserOperation to call a contract with arbitrary calldata. It distinguishes itself from siblings like fuse_read_contract and fuse_smart_execute_batch by emphasizing full control over the encoded call and the use of the smart wallet.

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 using this tool when full control over the encoded call is needed, which implies it's suitable for raw calldata scenarios. However, it does not explicitly mention when to avoid it or compare to alternatives like fuse_smart_approve_and_call.

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 atomicity and revert-on-failure behavior, which is valuable. However, it omits important behavioral traits such as authentication requirements, gas costs, and failure modes beyond revert.

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

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

Two sentences, front-loaded with key purpose, no wasted words. Highly efficient.

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

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

Despite having one parameter and no output schema, the description fails to mention return value (e.g., UserOp hash) or error conditions. Given the complexity of ERC-4337 operations, this is a significant gap.

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 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it just restates the atomic batch context. No additional clarification on parameter usage or constraints.

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

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

The description clearly states the tool submits a single ERC-4337 UserOperation to execute a sequence of contract calls atomically. It distinguishes from siblings like fuse_smart_call_contract by emphasizing batch execution and atomicity.

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

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

The description implies use for atomic batch execution but does not explicitly state when to use versus alternatives (e.g., single call). No mention of preconditions or when not to use, providing minimal 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?

No annotations are provided. The description discloses the return values but does not explicitly state that the tool is read-only, nor does it mention prerequisites like needing a configured signer or any other behavioral constraints.

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 a single, concise sentence that is front-loaded and contains no unnecessary words. Every part adds value.

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

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

Given zero parameters and no output schema, the description covers the essential purpose. However, it could be slightly more complete by hinting at the return format (e.g., boolean for paymaster).

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 zero parameters and schema coverage is 100%, so the description does not need to add parameter meaning. Baseline 4 is appropriate.

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 the ERC-4337 smart-wallet address and paymaster status, using specific verb 'Returns' and distinct resource. It differentiates from sibling tools like fuse_smart_wallet_get_actions and fuse_smart_wallet_authenticate.

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

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

The description implies usage when the smart-wallet address or paymaster status is needed, but does not explicitly state when to use this tool versus alternatives like fuse_get_signer_address or fuse_smart_wallet_get_actions.

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 should disclose behavioral traits. It states it submits a UserOperation (write operation) but omits gas costs, need for token approval, reversibility, or error conditions. This is insufficient for safe usage.

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

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

Two concise sentences, front-loaded with action and resource, then a clear guidance. No unnecessary 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?

For a staking operation with no output schema, the description lacks return value hints, gas estimation notes, or ties to related tools like fuse_get_staked_tokens. Adequate but incomplete.

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 100% and already explains both parameters (base units for tokenAmount, match options for tokenAddress). The description adds no new semantic meaning beyond reinforcing the tokenAddress constraint.

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 submits an ERC-4337 UserOperation to stake a token using Fuse's staking module, distinguishing it from unstake and other tools. The verb 'stakes' and resource 'Fuse's staking module' 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?

The description explicitly recommends listing options first with `fuse_get_staking_options`, providing a clear prerequisite. However, it does not mention when not to use this tool or alternatives for similar actions.

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 present, so the description carries the full burden. It states it submits a UserOperation, implying an on-chain write, but does not disclose that it is a state-changing mutation, requires authentication (e.g., smart wallet), has gas costs, or may fail. Critical behavioral details are missing for a transaction tool.

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

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

The description is extremely concise, consisting of two sentences that efficiently convey the tool's action and a prerequisite. Every sentence earns its place with 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 tool's complexity (swap via UserOperation, no output schema), the description lacks details about prerequisites (e.g., approved tokens, smart wallet existence), what the response contains, and potential failure modes. It is minimally adequate but leaves 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 coverage is 100%, so the input schema already describes each parameter adequately. The description adds no additional parameter meaning beyond what the schema provides. Baseline score of 3 is appropriate.

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 submits an ERC-4337 UserOperation to execute a swap via the Fusebox engine. It distinguishes itself from the quoting tool and other swap-related tools by specifying the execution action.

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

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

The description explicitly instructs users to first quote a swap with 'fuse_get_trade_quote' before using this tool, providing clear guidance on when to use it. However, it does not exclude alternative tools or mention conditions 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 are provided, so the description bears full responsibility for behavioral disclosure. It notes the tool submits a UserOperation, but fails to mention important traits like required approvals, gas costs, reversibility, or success conditions. The minimal detail leaves significant gaps for an agent.

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

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

The description is a single, front-loaded sentence that states the action, mechanism, and target. Every word serves a purpose with no redundancy. Efficient and clear.

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 tool with moderate complexity (smart account, user ops) and simple schema without output schema, the description is adequate but misses details about prerequisites (e.g., approval), return value (likely userOp hash), and smart wallet configuration. It provides the core function but lacks 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 covers 100% of parameters, each with descriptions. The tool description does not add additional meaning beyond what the schema already provides. Per rubric, baseline is 3 when coverage is high, and the description does not enhance parameter understanding.

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 specific verb 'submits' and resource 'NFT', clearly indicating it transfers NFTs (ERC-721/ERC-1155) via ERC-4337 UserOperation from the smart wallet to a recipient. It distinguishes well from sibling tools like fuse_smart_transfer_token (ERC20) and fuse_send_native.

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

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

The description provides clear context for transferring an NFT from a smart wallet, but does not explicitly state when to use this tool versus alternatives like fuse_smart_approve_nft or fuse_smart_call_contract. No exclusions or prerequisites 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.

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

With no annotations, the description discloses the ERC-4337 mechanism and gasless condition, but does not cover side effects, errors, permissions, or return values (e.g., userOp hash). Some useful context 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?

Two sentences, no fluff, front-loaded with the action ('Submits...'). Every word adds value.

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

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

No output schema exists, so the description should explain what the tool returns (likely a userOp hash), but it does not. Also missing context on required wallet setup and potential failures.

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 high (75%) with adequate descriptions for to, amount, and tokenAddress. The description adds no new parameter-level meaning, reinforcing only that tokens can be native or ERC-20, already in 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 it submits an ERC-4337 UserOperation transferring a token (native FUSE or ERC-20) from the configured smart wallet. This distinguishes it from siblings like fuse_smart_transfer_nft (NFTs) and fuse_send_erc20/fuse_send_native (non-smart-account transfers).

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 fuse_send_native or fuse_send_erc20 for non-smart-account transfers, nor does it mention prerequisites like wallet authentication.

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 states it 'submits an ERC-4337 UserOperation', implying a state mutation, but does not disclose what happens after submission (e.g., whether it waits for confirmation, returns a hash, or any side effects). Missing permission requirements, gas costs, or potential reverts.

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 a single sentence with no unnecessary words. It is concise and front-loaded with the action. Could be slightly restructured for clarity (e.g., 'Unstakes a token by submitting an ERC-4337 UserOperation via Fuse's staking module').

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 (3 required parameters, no output schema, no annotations), the description lacks key context. It does not explain the return value (e.g., UserOperation hash), the process flow, or how the receipt token is obtained. The description is too brief to fully inform an agent.

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

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

Schema coverage is 100% with detailed parameter descriptions. The tool description adds no additional meaning to the parameters. Baseline score of 3 is appropriate as the schema already documents each parameter's purpose.

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 submits an ERC-4337 UserOperation to unstake a token via Fuse's staking module. It uses a specific verb ('unstakes') and resource ('token'), distinguishing it from the sibling stake tool. However, it could be more explicit about the outcome (e.g., returning tokens to wallet).

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 (e.g., when to unstake vs. stake). It does not mention prerequisites like needing a receipt token address from fuse_get_staking_options, though that is hinted in a parameter description. The description itself provides no 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?

The description discloses that the tool exchanges a signature for a JWT and that signing is not performed by the tool, which is a key behavioral trait. However, it does not detail error handling (e.g., invalid signature) or state whether the JWT is returned directly or stored, which would help the agent anticipate behavior. Since no annotations are provided, the description carries full burden for 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 two sentences, front-loaded with the purpose and action, followed by a clarifying statement on client-side signing. Every sentence adds value, no redundancy.

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

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

For a tool with 4 parameters, full schema coverage, no output schema, and a clear authentication procedure, the description sufficiently explains the overall process and output (JWT for Bearer auth). It also references a sibling tool to contextualize use, making it complete for the task.

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 100% with clear parameter descriptions already present. The description adds minimal context beyond the schema, mostly repeating that signing is client-side and that ownerAddress refers to the EOA owner. Baseline of 3 is appropriate given high 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's purpose: exchanging an EIP-191 signature for a JWT for Bearer authentication on Smart Wallet API calls. It explicitly mentions a use case (fuse_smart_wallet_get_actions) and distinguishes the tool from other smart wallet tools by focusing on authentication.

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 explains that signing happens client-side and this tool only submits the signed payload, implying the user must already have a signature. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites like needing a deployed smart wallet.

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 burden. Discloses authentication requirement and action types, but does not mention rate limits, data freshness, error handling, or behavior on invalid JWT. Moderately 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?

Single sentence front-loading purpose and key prerequisite. No wasted words; efficient and scannable.

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 100% schema coverage and no output schema, description covers authentication, pagination, and optional token filter. Adequate for a paginated list endpoint. Could mention that it returns action objects but schema already defines parameters.

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

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

Schema coverage is 100%, baseline 3. Description adds context for JWT (linking to auth tool) and tokenAddress (optional filter), but defaults for page/limit are already in schema. Adds marginal value beyond 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?

Clearly states verb 'list' and resource 'paginated action history' of an authenticated smart wallet. Distinguishes from siblings by mentioning authentication prerequisite and specific action types (transfers, contract calls).

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?

References prerequisite tool `fuse_smart_wallet_authenticate` and mentions pagination, but does not explicitly state when to use vs alternatives or when not to use. No exclusion criteria or alternative tool 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It mentions 'indicative' and '0x-style response', but does not explicitly state that the tool is read-only, does not simulate transactions, or require allowances. It also omits potential side effects or prerequisites.

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 that front-load the main purpose and a critical parameter constraint. No extraneous words; every sentence earns its place.

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 (15 parameters, no output schema, no annotations), the description is insufficient. It does not explain the response structure beyond '0x-style', nor does it address optional parameters, prerequisites, or common use cases.

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 adds value by clarifying the mutual exclusivity of sellAmount and buyAmount, which is partially covered in schema descriptions. However, with 40% of parameters lacking schema descriptions, the description does not elaborate on other important parameters like gasPrice, slippagePercentage, etc., leaving significant gaps.

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

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

The description clearly states the tool returns an indicative price and route for a swap on Fuse, using 0x-style response. It also notes that one of sellAmount/buyAmount is required. However, compared to sibling tools like fuse_get_trade_quote and fuse_smart_swap_tokens, it could more explicitly differentiate itself as a quotation tool versus execution.

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 a clear usage hint that one of sellAmount or buyAmount must be provided, but it lacks guidance on when to use this tool over similar tools (e.g., fuse_get_trade_quote) or under what conditions it is appropriate.

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 disclose behavioral traits. It only says 'returns' which implies a read operation, but it does not mention authentication needs, rate limits, or any side effects. The description is too minimal to convey important 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 is a single sentence that efficiently communicates the tool's purpose. It is front-loaded with the action and resource, and includes examples for clarity, with 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 that the tool has no parameters and no output schema, the description is adequate for a simple list tool. It could be improved by specifying the return format (e.g., array of strings) or clarifying that the list is for the current user/chain configuration, but it is not incomplete.

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 no parameters, and schema coverage is 100% because the schema is empty. The description does not need to add parameter details, but it could provide more context about the output format or the nature of the liquidity sources list. It adds basic value by naming example sources.

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 explicitly states it 'returns the liquidity sources currently enabled for Fuse-chain trades' and provides examples like voltage.finance and sub-pools. This clearly distinguishes it from sibling tools that deal with trading, prices, or contract deployment.

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. Among siblings, there are related trade tools (e.g., fuse_get_trade_quote, fuse_trade_indicative_price), but the description does not explain when to prefer this one 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 are provided, so the description must disclose behavioral traits. It only mentions the return format but does not state that it is a read-only operation, any side effects, or prerequisites like network requirements. The description does not compensate for missing annotations.

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

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

The description is a single sentence that front-loads the purpose and includes the return format. No unnecessary details; every word earns its place.

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 tool with two parameters and no output schema, the description is nearly complete. It could mention that days must be a positive integer (already in schema) but lacks potential error conditions. Overall adequate.

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

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

Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds the context of 'custom day-count window' but does not provide additional meaning beyond what the schema offers. Baseline score of 3 is appropriate.

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 a token's price change over a custom day-count window. The verb 'returns' and resource 'token's price change' are specific. However, it does not explicitly differentiate from similar siblings like fuse_get_token_price_change, which may have a similar purpose.

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

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

No guidance on when to use this tool versus alternatives like fuse_get_token_price_change or fuse_get_token_price_history. The description lacks any context about appropriate usage scenarios.

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 discloses that the tool signs and submits calls from the server's signer, auto-fetches ABI, and returns a transaction hash. However, it does not mention permissions required, reversibility, or error conditions, which are important for a mutation tool.

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

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

Two sentences with no wasted words. The first sentence provides the core purpose, and the second adds important details (ABI auto-fetch, return value). Efficiently 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?

For a write tool with 5 parameters and no output schema, the description covers the return value, ABI behavior, and mutation context. It could mention that the call originates from the server's signer and clarify error handling, but overall it provides sufficient information for an agent to use the tool correctly.

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 100%, so the schema already documents all parameters. The description adds minimal extra context: that ABI is auto-fetched when omitted and that valueWei is for payable functions. This is adequate but not exceptional.

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 ('signs and submits'), resource ('state-mutating contract call'), and key behaviors (auto-fetch ABI, returns transaction hash). It distinguishes from sibling tools like fuse_read_contract by specifying state-mutating nature.

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

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

The description implies usage for writing to contracts by stating 'state-mutating contract call' and mentions auto-fetching ABI. However, it does not explicitly state when not to use it or provide alternatives, though the sibling list includes read and deploy tools that naturally differentiate.

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