Fuse Network

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

With no annotations, the description carries the burden. It discloses that the server's signer is used and that the contract address is returned only when waitForReceipt is true. However, it does not mention potential consequences like gas costs, authentication requirements, or the destructive nature of deployment.

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 efficiently convey the core action and key return behavior. However, the structure could be improved by separating the return information more clearly.

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 covers major aspects (signing, submitting, return fields) but lacks details on error conditions, required gas balance, or the impact of the server's signer. Adequate but not comprehensive.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning beyond confirming the purpose of waitForReceipt. 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 ('Signs and submits a contract-deployment transaction'), identifies the resource (contract deployment), and distinguishes from related tools like fuse_write_contract by specifying deployment vs. writing to 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?

The description implies usage for deploying contracts but does not provide explicit guidance on when to use this tool vs. alternatives, nor does it mention prerequisites or when not to use it.

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

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

With no annotations, the description must disclose behavioral traits. It mentions POST for verify actions and automatic parameter injection, but lacks details on rate limits, errors, or return format.

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 core purpose, and succinctly covers scope and examples. 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?

Given 5 parameters and no output schema, the description lacks details on response format or error handling. It mentions 'etherscan-compatible endpoints' but does not clarify what the output looks like.

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 meaning by explaining the API pattern, automatic injection, and differentiation between GET/POST. It enhances understanding beyond raw 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's a generic dispatcher for the Fusebox Explorer API, covering 40+ endpoints. It distinguishes from sibling tools like fuse_get_balance by being a universal wrapper.

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 generic use for many endpoints but does not explicitly state when to prefer this tool over dedicated siblings or provide 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?

With no annotations, the description must fully disclose behavior. It correctly indicates a read operation, lists returned data, and notes a limitation (Paymaster eligibility not evaluated). However, it could explicitly state read-only nature or mention idempotency.

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

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

The description is extremely concise: two sentences covering purpose, output, and a limitation. No verbosity, 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 the tool's purpose, the description adequately explains what data is returned and notes a limitation. Without an output schema, it provides good context. It could mention that this is a read-only query, but the verb 'Reads' strongly implies 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?

Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema for the two parameters. It does not clarify nonceKey format or the counterfactual nature of the address 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 reads ERC-4337 state for a smart account on Fuse, listing specific data fields (deployment status, nonce, deposit balance). The verb 'Reads' and resource identification are precise, and the tool is distinct from all sibling tools.

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

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

The description lacks explicit guidance on when to use this tool versus alternatives. It only mentions a limitation (Paymaster not evaluated) but does not provide context for when to prefer it or avoid it. Usage is implied by the functionality.

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 behavioral traits. It only states the return value (balance). Missing details on required authentication, rate limits, error conditions (e.g., invalid address), or output format. For a simple query tool, minimal disclosure 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?

Single sentence conveying all essential information. No wasted words. Front-loaded with purpose and key conditional behavior.

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?

Tool is simple with 2 parameters and no output schema. Description covers the primary logic but lacks details on return format (e.g., string vs hex), error handling, or address validity requirements. Could be more complete for full transparency.

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% (both parameters documented). Description adds meaning beyond schema by explaining the optional nature of tokenAddress and the distinction between native and token balance. This helps agent understand parameter usage.

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

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

Description clearly states it returns native FUSE or ERC-20 token balance for an address. Verb 'Returns' and resource 'balance' are specific. Distinguishes between native and token balance via tokenAddress parameter. Differentiates from sibling tools like fuse_get_staked_tokens or fuse_get_token_price by focusing on balance queries.

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 implies usage: use without tokenAddress for native balance, with tokenAddress for ERC-20 balance. No explicit when-not or alternatives mentioned. Sibling tools like fuse_list_wallet_tokens or fuse_get_token_metadata could be alternatives for similar queries, but not 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 provided, so the description carries full burden. It discloses it returns current data and conditional EIP-1559 suggestions, which is transparent. However, it could note that it is a read-only network query with no side effects.

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

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

Single sentence is concise and front-loaded with the return information. No wasted words, though it could be slightly more compact.

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 sufficiently covers what the tool does. It fully explains the return value format and conditional EIP-1559 data, making it complete for a simple query 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?

Input schema has no parameters and schema coverage is 100%, so no parameter description needed. Baseline of 4 applies due to zero parameters; description adds no extra param info, which 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 specifies the tool returns the current Fuse network gas price in wei and gwei, including EIP-1559 fee suggestions when available. The verb 'Returns' and resource 'gas price' are unambiguous, and it distinguishes itself from all siblings which focus on 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?

No explicit when-not or alternative tools mentioned, but as a read-only, parameterless tool, the context is clear. The sibling list includes many other tools, but no exclusion guidance is needed; the tool's simplicity makes its usage obvious.

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 important behavior: returns null if pending/unknown. This is transparent for a read-only operation. Could mention that hash must be valid, but current detail is sufficient.

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-loaded with verb and resource. Every word earns its place. Excellent conciseness.

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

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

Given no output schema, description explains receipt content (status, gasUsed, logs) and handles edge case (null for pending/unknown). Complete for a simple read-only 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% and already describes 'hash' as 'Transaction hash (0x-prefixed, 32 bytes).' Description adds no extra parameter detail, 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?

Description clearly states 'Fetches the receipt for a mined transaction' and lists key fields (status, gasUsed, logs). This is specific and distinguishes it from sibling tools like fuse_get_transaction which fetches the full transaction.

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 indicates this is for mined transactions and returns null for pending/unknown, giving clear context. It doesn't explicitly state alternatives but the null return implies when not to use it. Good for a simple tool.

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

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

With no annotations, the description carries full burden. It indicates a read-only operation returning an address, no side effects mentioned, transparent enough for a simple getter.

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 word earns its place, 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?

No parameters, no output schema; description explains return value and use case comprehensively. Complete for a 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?

No parameters, schema coverage is 100% trivially. Description adds no param info, but baseline for 0 params is 4.

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

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

The description clearly states the tool returns the EOA address controlled by the server's configured FUSE_PRIVATE_KEY. It distinguishes itself as a pre-write check tool among siblings.

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 says 'Use this before any write tool to confirm which account will pay gas and send transactions.' Provides clear context for usage, though no 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 are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns data (a read operation), but does not disclose whether the call is idempotent, any authentication requirements, or potential side effects. The description lacks details on rate limits, caching, or whether the data is real-time. For a read operation with zero annotation coverage, more transparency is needed.

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 totaling 20 words, front-loading the key outputs (staked amount, USD value, etc.) immediately. Every word earns its place; there is no fluff or repetition. The structure is efficient and easy to parse.

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 (one required parameter, no output schema, no annotations), the description adequately explains what it returns. It lists the specific data fields (staked amount, USD value, earned rewards, APR) which is sufficient for a read operation querying wallet positions. It does not mention pagination or limits, but for a wallet-specific query this is likely unnecessary. The description is nearly complete for the tool's 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?

The input schema covers 100% of the single parameter (walletAddress) with a clear description. The tool description does not add any additional information beyond what the schema already provides. With full schema coverage, a score of 3 is appropriate—the description adds no extra semantic 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 the tool returns active staking positions for a wallet, listing specific data points (staked amount, USD value, earned rewards, APR per position). This distinguishes it from sibling tools like fuse_get_staking_options (which likely lists available options) and fuse_smart_stake_token (which performs staking). The verb 'returns' and specific resource make the purpose unambiguous.

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

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

The description provides minimal guidance on when to use this tool. It does not explicitly state when to use it over alternatives like fuse_get_staking_options or fuse_smart_stake_token, nor does it mention any exclusions (e.g., only for active positions, not historical). The only contextual hint is 'Powered by the Fusebox SDK StakingModule,' which is insufficient for differentiating among closely related siblings.

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

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

No annotations provided, so the description discloses the core behavior: it lists staking options with specific fields (token, APR, TVL, expiry, unstake token). It also mentions the source (Fusebox SDK StakingModule). It doesn't explicitly state read-only, but that is implied by 'Lists'.

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 concise (two sentences) and front-loaded with the purpose and details, with 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?

Given no parameters and no output schema, the description is complete: it specifies exactly what is listed (token, APR, TVL, expiry, unstake token) and the source. No additional information is needed.

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

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

The tool has zero parameters and 100% schema coverage, so no parameter info is needed. The description does not need to add 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 'Lists' and the resource 'every staking option supported by Fuse', and distinguishes from sibling tools like fuse_get_staked_tokens by specifying it returns options, not staked 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 (when you need a list of staking options) but does not explicitly state when not to use it or mention alternatives. Given the tool has no parameters, the usage is straightforward.

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 indicates a read-only operation but lacks details on rate limits, authentication, or error behavior. Adequate for a simple read 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?

Single sentence front-loading the action and resource, with 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?

Complete for a simple one-parameter read tool with no output schema; clearly specifies the chain (Fuse) and what metadata is read.

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 the description adds no extra meaning beyond the schema's parameter description, resulting in baseline 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 it reads name, symbol, decimals, and totalSupply for an ERC-20 token on Fuse, distinguishing it from siblings 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 explicit when to use or when not to use. The description implies usage for reading token metadata but does not mention alternatives 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 are provided, so the description carries full burden. It states the tool returns a current USD price but does not disclose side effects (none expected), authentication needs, error behavior (e.g., token not tracked), or rate limits. The read-only nature is implied by 'get' but not confirmed.

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 first sentence containing the core information. The second sentence ('Powered by...') adds little value and could be removed. Overall concise but with slight 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 simple read-only tool with one parameter and no output schema, the description is moderately complete. It lacks details on error cases, price freshness, or what 'tracked by Fusebox' means. Given the complexity, it is adequate but not thorough.

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 'tokenAddress', which is well-described in the schema. The description adds no additional meaning beyond noting the token is an ERC-20, which matches 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 verb ('Returns'), the resource ('current USD price for an ERC-20 token'), and the context ('tracked by Fusebox'). It distinguishes from siblings like fuse_get_token_price_change and fuse_get_token_price_history by focusing on the current 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?

The description implies usage for current price but does not explicitly state when to use this tool versus alternatives. Siblings like fuse_get_token_price_change and fuse_get_token_price_history are present, but no guidance on choosing between them.

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 cover behavioral traits. It states the token must be ERC-20 and tracked by Fusebox, and that it's powered by the TradeModule. However, it does not disclose error behavior (e.g., invalid address, untracked token), rate limits, or whether this is a read-only operation (implied but not 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?

Two concise sentences that front-load the core functionality. Every word adds value, with no repetition or fluff.

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 with one parameter and no output schema. The description explains what it returns (24h percentage change) and the prerequisite (tracked by Fusebox). Could be more complete by noting the return format (e.g., a percentage string or number), but 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 coverage is 100% with a clear description for tokenAddress. The description adds value by specifying it applies to ERC-20 tokens tracked by Fusebox, which is not in the schema. This helps the agent understand domain 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 it returns the 24-hour percentage price change for an ERC-20 token. It distinguishes from siblings like fuse_get_token_price (current price) and fuse_get_token_price_history (historical data) by specifying the exact metric and time frame.

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

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

The description implicitly suggests use for checking short-term price movement but lacks explicit when-to-use or when-not-to-use guidance relative to sibling tools like fuse_trade_indicative_price or fuse_get_token_price. No alternatives or exclusions are mentioned.

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

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

With no annotations provided, the description carries the full burden. It mentions the tool is 'Powered by the Fusebox SDK TradeModule' but does not disclose limitations, data freshness, rate limits, or output format. For a historical data tool, more transparency on what exactly is returned (e.g., OHLC fields) is needed.

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 key action ('Returns OHLC / interval price stats'), no fluff. 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?

Given no output schema, the description lacks detail on return values (e.g., what fields of OHLC are included, and in what format). An agent cannot fully anticipate the tool's output for downstream use. The description is too sparse for a data retrieval 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%, so baseline is 3. The description adds minimal meaning beyond the schema: it restates 'over a week, month, or year' which matches the enum, but does not elaborate on token address format or that timeFrame selects both range and granularity.

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

No explicit guidance on when to use this tool versus alternatives. Sibling tools like fuse_get_token_price and fuse_trade_indicative_price exist, but the description does not state when to choose this one or provide 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?

Explicitly states read-only behavior and that it returns a quote without submitting a trade. Mentions the SDK backing (Fusebox TradeModule). No annotations provided, so description carries the burden; it adequately covers the key behavioral traits for a read 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?

Two sentences, front-loaded with core purpose and read-only hint. No wasted 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?

For a simple read-only quote tool with no output schema, the description explains what is returned (output amount, route, price impact). Parameter count and coverage are adequate. Minor gap: could mention response format or that it does not modify state (though read-only implies 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?

Schema coverage is 100% with clear parameter descriptions. The description adds no additional parameter-level meaning beyond what the schema provides; baseline score 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 quotes a token swap on Fuse, specifying what is returned (expected output amount, route, price impact). Read-only nature is explicitly mentioned, distinguishing it from trade execution 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?

Implies usage for previewing trades without submission, but does not explicitly contrast with sibling tools (e.g., fuse_smart_swap_tokens for execution, fuse_trade_indicative_price for different quote type). No 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?

With no annotations, the description carries the full burden. It discloses that the tool returns null if the transaction is not found, which is helpful. However, it does not mention any behavioral traits like idempotency, rate limits, or side effects (though likely none).

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

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

Two sentences, no wasted words. The key information is front-loaded and directly actionable.

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 is nearly complete. It covers the main action and a common edge case (null return). It could mention the return object type, but that's minor.

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 'hash' is fully described in the schema with type and format. The description does not add additional context beyond what the schema provides, so it meets the baseline for high schema coverage.

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

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

The description clearly states it fetches a transaction by hash, with the specific verb 'fetches' and resource 'transaction'. It distinguishes from sibling tools like fuse_get_receipt by focusing on transaction vs 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 implies when to use: when you have a transaction hash. However, it does not provide explicit exclusions or mention alternatives, which is acceptable for a simple getter.

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

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

No annotations are provided, so the description carries full burden. It is read-only as implied by 'returns', but lacks details on pagination, data freshness, or any constraints like maximum history depth. The mention of 'indexed via Fusebox GraphQL' gives some backend context but is insufficient for full 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?

Two sentences with no wasted words. The key information is front-loaded: 'Returns the ERC-4337 UserOperation history'. Efficient and well-structured.

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

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

For a simple historical query tool with one parameter and no output schema, the description is fairly complete. It explains the source (Fusebox GraphQL service). However, it could mention response format or pagination to be 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% with one parameter 'sender' already described in the schema. The description adds minimal extra meaning beyond 'for a smart account on Fuse', which is redundant. Baseline 3 applies as schema does the heavy lifting.

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. The verb 'returns' is specific, and the resource is well-defined. It distinguishes from sibling tools like fuse_get_balance or fuse_get_account_abstraction_info.

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

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

The description provides no guidance on when to use this tool vs alternatives. It does not mention prerequisites, when not to use, or reference sibling tools for comparison.

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

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

With no annotations provided, the description carries full burden. The word 'returns' implies a read-only operation, and the tool appears idempotent and safe. However, it does not disclose authentication requirements, rate limits, or caching behavior, leaving some transparency gaps.

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

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

The description is extremely concise and front-loaded with the key action 'Returns the catalogue'. Every sentence adds value, with no wasted words. It is two sentences totaling 19 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?

While the description is sufficient for a simple list tool, it lacks details about the output format (e.g., addresses, symbols, decimals). Given no output schema, the agent must infer the structure. Additional context on what the catalogue contains would improve completeness.

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

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

The input schema has zero parameters and 100% schema coverage. The description does not need to explain parameters since there are none. Following the guideline, a baseline 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 that the tool returns the catalogue of ERC-20 tokens tracked by Fusebox, specifying they are tradable, indexed, and priced. It distinguishes itself from sibling tools like fuse_get_token_metadata which focus on individual 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 before trading or querying, but it does not explicitly state when to use this tool versus alternatives like fuse_get_token_metadata or fuse_get_token_price. No exclusions or when-not-to-use guidance is provided.

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

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

No annotations are provided, so the description carries full burden. It does not disclose that the operation is read-only, any authentication needs, rate limits, or what the output contains (e.g., array of NFT metadata). This lack of behavioral context is a significant gap.

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

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

The description is a single, informative sentence with no wasted words. It is front-loaded and to the point.

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 low complexity (1 param, no nested objects, no output schema), the description covers the main purpose and input. However, absence of output schema means the description should ideally hint at return format (e.g., list of NFT objects), which is 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% for the single parameter walletAddress. The description adds no new meaning beyond the schema's description, 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 tool lists all NFTs (ERC-721/ERC-1155 collectibles) owned by a wallet on Fuse. It uses a specific verb 'lists' and resource 'NFTs', and differentiates from sibling fuse_list_wallet_tokens which likely lists fungible 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 use for NFTs but does not explicitly state when to use this vs alternatives like fuse_list_wallet_tokens or fuse_smart_transfer_nft. No when-not-to-use or alternative tools are mentioned.

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

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

No annotations provided, so description carries full burden. It does not disclose whether the tool is read-only, requires authentication, has rate limits, or its performance implications. This is insufficient for a tool that may be used in various contexts.

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 concise: two sentences with no wasted words. It states the core function, enrichment details, and technical backend, all in a clear order.

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

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

Given the simple nature (one param, no output schema), the description covers the main functionality and enrichment. It lacks details on pagination, sorting, or whether all tokens are returned, but these are not critical for a basic list tool.

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

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

The single parameter 'walletAddress' is fully described in the schema. The description adds no additional meaning beyond what the schema provides, so 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 tool lists ERC-20 tokens for a wallet on Fuse with enriched metadata. It distinguishes from siblings like fuse_get_balance, fuse_list_supported_tokens, and fuse_list_wallet_nfts.

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 list of ERC-20 tokens with metadata is needed, but it does not explicitly mention when to use this tool versus alternatives like fuse_get_balance or fuse_list_supported_tokens.

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 carry the burden. It only mentions the API key requirement but fails to disclose other behavioral traits like idempotency, effect on existing addresses, or authorization details beyond the key.

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 extraneous information. Both sentences serve a clear purpose: stating the action and a prerequisite.

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 fully described parameters and no output schema, the description is reasonably complete. It covers the core action and a key requirement. Could benefit from mentioning typical usage after webhook creation, but not essential.

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. The description adds no additional meaning beyond the schema, so 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 the action ('Add') and the resource ('EVM addresses to a webhook's listening scope'). Distinguishes from sibling tools like remove and list 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?

Mentions the required API key, which is crucial for usage. Does not explicitly contrast with remove/list tools, but the context of sibling names makes the distinction clear.

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

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

No annotations are provided, so the description carries the full burden. It mentions authentication details, but does not disclose other behavioral traits such as idempotency, error handling, or side effects beyond creation.

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

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

The description is two sentences long, front-loading the purpose and adding a critical authentication note. 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?

Given no output schema, the description does not explain what the response will contain or error conditions. It is sufficient for simple creation but lacks completeness for an agent to fully understand the outcome.

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 having a description. The description adds minimal extra meaning beyond the schema, such as confirming the URI format for webhookUrl. 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 creates a webhook for a project, with specific verb 'Create' and resource 'webhook'. It distinguishes from sibling tools like delete, update, and list.

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

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

The description provides the authentication requirement (FUSEBOX_SECRET_API_KEY) which is essential for usage. However, it lacks explicit guidance on when to use this versus alternative tools or conditions where it should not be used.

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

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

With no annotations, the description carries full burden. It mentions 'Permanently delete' and 'stops receiving events', which is basic but adequate. It could add details about idempotency or error handling.

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

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

Two concise sentences front-loading the key information: action, resource, destructiveness, and auth requirement. 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?

For a simple delete tool, the description covers the essential behavior and requirements. It lacks mention of return value, but no output schema exists. 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?

The single parameter 'webhookId' is described in the schema. The description adds no extra meaning beyond what the schema provides. With 100% schema coverage, 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 (delete) and resource (Fusebox Notification webhook), differentiating it from sibling tools like create, update, or list.

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

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

It explicitly describes the destructive nature and the required API key, providing context for when to use. While it doesn't mention when not to use, the clarity is sufficient for a delete operation.

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 burden. It discloses the auth requirement but does not state whether it is a read-only operation, side effects, error scenarios, or rate limits. Minimal behavioral information.

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. Purpose and auth requirement are front-loaded. 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?

No output schema exists, but the description does not specify what 'details' are returned (e.g., URL, events). It leaves the agent guessing about return values. Auth prerequisite is noted, but error cases or prerequisites beyond the key 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% for the single parameter webhookId, which already has a description. The description adds 'Webhook ID to retrieve,' adding little extra meaning beyond the schema.

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

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

The description clearly states the action: 'Retrieve details of a single Fusebox Notification webhook.' It uses a specific verb and resource, distinguishes from sibling tools like create/delete/list, and adds product context.

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

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

The description mentions the required authentication key, implying when to use (only if you have the key). Sibling names like list_project_webhooks and create_webhook provide implicit guidance, but no explicit when-not or alternative instructions.

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

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

Discloses the requirement for `FUSEBOX_SECRET_API_KEY`, implying safe read-only operation, but does not detail behavior on errors, pagination, or potential side effects. With no annotations, more detail would be beneficial.

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

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

Extremely concise: one sentence plus a required key note. No extraneous information, every part is necessary.

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 or nested objects, the description is largely complete. It could mention pagination or result format, but is adequate for basic usage.

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

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

Schema description coverage is 100%, and the description adds context about the parameter being a 'webhook ID' and its purpose, providing value beyond the schema's base description.

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 every EVM address monitored by a given webhook', uses a specific verb and resource, and distinguishes from sibling notification tools by focusing on address listing.

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?

Implicitly guides when to use (to list addresses for a webhook), but lacks explicit when-not-to-use or alternatives among sibling notification tools.

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

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

No annotations exist, so description must provide behavioral context. It includes an authentication requirement but does not mention pagination, error handling, or response format.

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, efficiently front-loading the action and essential requirement with no extraneous 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 and one parameter, the description is adequate but missing details like output format or behavior for empty 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?

Parameter schema already has 100% coverage description for projectId. The tool description adds no additional meaning for the parameter.

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

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

Description clearly states the tool lists webhooks for a project, using specific verb 'List' and resource 'webhooks', distinguishing it from other notification tools like create, delete, get.

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

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

Mentions authentication requirement but does not provide guidance on when to use this tool versus alternatives like fuse_notification_get_webhook (singular) or other listing tools.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only indicates a destructive removal operation but fails to specify side effects, reversibility, or potential error states. The description 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?

The description is concise with two sentences, front-loading the key action and following with a necessary prerequisite. Every sentence adds 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?

Despite low complexity (2 parameters, no output schema), the description lacks important context such as success indicators, error behaviors, or confirmation of changes. It feels incomplete for a mutation tool.

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

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

The input schema has 100% coverage with descriptions for both parameters. The description's mention of 'Remove EVM addresses' adds marginal value beyond the schema's 'EVM addresses to stop monitoring'. No further constraints or nuances are provided.

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 a webhook's listening scope'), specifying the verb and resource. It is easily distinguishable from sibling tools like 'fuse_notification_add_addresses' and 'fuse_notification_list_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 a prerequisite ('FUSEBOX_SECRET_API_KEY') but provides no guidance on when to use this tool versus alternatives such as 'fuse_notification_add_addresses'. No explicit when-to-use or when-not-to-use context is given.

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

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

No annotations provided, so description must cover behavioral traits. It mentions the required API key but does not disclose side effects, such as whether the webhook is temporarily disabled, validation rules, or latency. The description is insufficient for 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?

Very concise: one sentence for purpose and one for requirement. No wasted words. However, it could be slightly more structured (e.g., noting that all three params are required).

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 mutation tool with high schema coverage, the description covers the basics but lacks details about response or verification of success. Without an output schema, this leaves a 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 coverage is 100% with good parameter descriptions. The description adds minimal value beyond the schema, simply hinting that URL or event type can be updated. 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 the action (update) and resource (Fusebox Notification webhook) with specifics (URL or event type). However, it implies optionality ('or') while the schema requires both fields, which could cause slight confusion.

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 sibling tools like create_webhook or delete_webhook. Only a prerequisite (API key) is mentioned, but no context on appropriate 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 provided, so description carries full burden. It discloses read-only nature and auto-fetching of ABI, but lacks details on error handling or return values.

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?

Extremely concise with two front-loaded sentences. 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?

Covers core behavior for a read tool, but output schema is absent. Could mention error scenarios or dependency on ABI verification.

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 3. Description adds no extra meaning beyond schema; ABI auto-fetching is already present in schema description.

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 calls a view/pure function on a Fuse contract, using a specific verb and resource. It distinguishes from write tools like fuse_write_contract.

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?

Implicitly suggests read-only use via 'view/pure function' but does not explicitly state when to use or alternatives. No direct comparison to siblings.

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

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

With no annotations, the description covers key behaviors: it resolves names, passes through plain addresses, and requires external configuration. It does not disclose potential side effects or rate limits, but for a read-like operation, this is sufficient.

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 every sentence adds value. No redundant or tangential 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?

For a simple resolution tool with one parameter and no output schema, the description is complete. It explains the core function, the configuration need, and the behavior with non-ENS inputs.

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

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

The schema description covers the single parameter well (100% coverage), and the tool description reinforces that plain addresses are returned unchanged. While the description adds a configuration note, it does not significantly enhance meaning beyond the schema.

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

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

The description clearly states the tool resolves an ENS name to its EVM address, which is a specific verb-resource pair. It also differentiates itself from sibling tools by mentioning ENS not deployed on Fuse, making its purpose distinct.

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

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

The description explains when to use the tool (resolving ENS names) and notes that plain hex addresses are passed through. It also mentions a prerequisite (ENS_RPC_URL configuration). However, it does not explicitly state when not to use it or provide alternatives, though none exist among siblings.

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

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

With no annotations, the description carries full burden. It discloses the action (submits signed transaction), auto-fetching decimals, and the unit parameter behavior. However, it does not mention gas costs, balance prerequisites, or return values, which are relevant for a write 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?

Two sentences with no wasted words. The core action is front-loaded, and the key detail about auto-fetching decimals and the 'unit' parameter is concisely stated.

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 is adequate but missing return value info (likely transaction hash) and prerequisites (e.g., signer must have tokens and gas). For a simple tool, it covers essential behavior but could be more complete.

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

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

The description adds meaning beyond the input schema by specifying that decimals are auto-fetched and explaining the 'unit: base' behavior. It also contextualizes the signed 'ERC20.transfer(to, amount)' call. Schema coverage is 75%, and the description fills gaps for the enum parameter and overall 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?

The description clearly states the tool submits a signed ERC20.transfer call from the server's signer. It specifies the exact contract function and distinguishes this tool from siblings 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 provide explicit guidance on when to use this tool versus alternatives. It implies usage for sending ERC20 tokens from the server signer, but no direct comparisons or exclusions with siblings like fuse_smart_transfer_token.

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

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

No annotations exist, so the description must cover behavioral traits. It states the transaction is signed by the server's signer and returns a hash, with a follow-up tool mention. However, it lacks details on prerequisites (e.g., sufficient balance), failure modes, or permission 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 sentences, no wasted words. Front-loaded with the main action and includes a useful follow-up hint. 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 native transfer tool, the description covers the main purpose and return value. Minor gap: does not mention that the signer must have sufficient balance or that the transaction might fail. Overall nearly complete for the complexity level.

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

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

Schema coverage is 100%; the description adds no new meaning beyond what the schema already provides for parameters 'to', 'amount', and 'unit'. 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 specifies the verb 'Submits a signed transaction', the resource 'native FUSE', and the action 'transferring from server's signer to recipient'. It distinguishes from siblings like fuse_send_erc20 by focusing on native FUSE.

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 sending native FUSE but does not explicitly state when to use this tool versus alternatives (e.g., fuse_send_erc20 for tokens). No 'when not to use' or comparison provided.

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

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

No annotations provided, so description carries full burden. It discloses server-side signing, hex output, and no on-chain submission. Could mention auth needs or error handling but adequate for this 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 waste. Key information front-loaded: signing method, return format, and on-chain behavior.

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 2 parameters and no output schema, description covers return format (hex signature) and encoding options. Could mention message length limits or error scenarios, but complete enough for a simple signing 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%, baseline 3. Description adds value by explaining encoding defaults and hex option for raw bytes, which clarifies beyond enum values.

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 signs a message using EIP-191 (personal_sign) and returns a 65-byte hex signature. It distinguishes from sibling fuse_sign_typed_data which handles EIP-712 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?

Explicitly states 'No on-chain transaction is submitted', clarifying this is for off-chain signing. Does not explicitly compare to fuse_sign_typed_data but context implies differentiation.

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

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

No annotations are provided, so the description must carry full behavioral burden. It discloses that the operation is a local sign (off-chain), returns a 65-byte hex signature, and does not submit a transaction. However, it omits details about idempotency, error behavior, or the nature of the server's signer (e.g., deterministic or non-deterministic).

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 extraneous words. The first sentence states the action and target, the second clarifies the return format and the off-chain nature. Information is front-loaded and 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 specifies the return (65-byte hex signature) and the off-chain property. It covers the essential behavioral and output details for a signing tool, though it could elaborate on the exact format (r,s,v) or error scenarios.

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

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

Schema coverage is 100%, with each parameter having a description. The tool description adds minimal extra meaning beyond the schema, primarily reiterating that it signs a structured payload. The description does not provide additional semantic hints like typical values 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 action ('Signs a structured EIP-712 payload'), the resource (EIP-712 data), and distinguishes from on-chain operations by noting no transaction is submitted. It differentiates from sibling tools like fuse_sign_message through explicit mention of 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 implies usage for signing EIP-712 payloads and explicitly notes no on-chain transaction, helping distinguish from transaction-related tools. However, it does not explicitly contrast with fuse_sign_message or provide when-not-to-use guidance, slightly reducing clarity.

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

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

No annotations are provided, so the description carries full burden. It discloses the atomic combine operation and mentions the smart wallet, but does not reveal any behavioral traits such as permission requirements, reversibility, side effects, or error conditions. 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 sentence that is concise and to the point. It wastes no words, though it could be slightly more structured with a separate line for usage hint. Still, it is 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 the tool has 5 parameters and no output schema, the description should hint at return values or setup requirements. It does not mention what the response contains or any prerequisites like token balance or approval state. It is minimally complete for a simple operation but lacks broader 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 high (80%+), so the description does not need to add extra parameter info. However, it also does not augment the schema's meaning. The description adds no parameter-specific details beyond what is already in the input schema.

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

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

The description clearly states it atomically approves a token and invokes a follow-up call, distinguishing it from siblings like fuse_smart_approve_token and fuse_smart_call_contract. The verb 'approves' and 'invokes' plus 'atomic' specify the resource and 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 mentions 'Common DeFi pattern', implying usage, but does not explicitly state when to use this tool over alternatives, nor provides any when-not or prerequisites. No exclusions or context for when the separate approval or call tools would be preferred.

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

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

No annotations are provided, so the description carries full burden. It discloses the action (calling approve via UserOperation) but omits side effects (state change on NFT contract), gas implications, authentication needs, error handling, or success/failure behavior. The description is truthful but insufficiently transparent for an agent to understand consequences.

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 is front-loaded with the key action ('Submits an ERC-4337 UserOperation') and concisely specifies the call and target. No superfluous words or repetition.

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?

Missing critical context: return value (e.g., userOp hash, transaction hash), prerequisites, error scenarios, and integration details for ERC-4337. Given the absence of an output schema and annotations, the description should provide more 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 clear descriptions for all three parameters. The description adds minimal value beyond the schema (e.g., mentioning UserOperation and smart wallet context). Baseline 3 is appropriate as the schema already fully documents each parameter.

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

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

The description clearly states the tool submits an ERC-4337 UserOperation calling `approve(spender, tokenId)` on an NFT contract from a smart wallet. It specifies the verb (submits), resource (UserOperation), and domain (NFT approve), and distinguishes it from sibling tools like fuse_smart_approve_token (ERC-20) and fuse_smart_transfer_nft.

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. Does not mention prerequisites (smart wallet must be configured), exclusions (e.g., not for ERC-20), or when not to use. The sibling list includes fuse_smart_approve_token and fuse_smart_approve_and_call, but the description provides no comparative context.

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

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

No annotations exist, so the description must fully disclose behavior. It mentions that it uses an ERC-4337 UserOperation from the smart wallet, which implies a meta-transaction and indicates it is not a direct call. However, it does not state side effects (e.g., gas costs, permission requirements, return value) beyond the basic action.

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

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

The description is a single, complete sentence that immediately conveys the tool's action. There is no extraneous information, and it is appropriately concise.

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

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

Given a simple ERC20 approve action, the description is minimally adequate. It does not explain the return value (e.g., user operation hash) or any required setup beyond the configured smart wallet. With no output schema, more context would help an agent understand what to expect.

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 75% description coverage, providing baseline parameter documentation. The tool description adds no additional parameter context beyond what is in the schema. The description of 'amount' and 'unit' in the schema is adequate, so this score reflects the schema's work.

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 for ERC20.approve from the smart wallet. The verb 'submits' and specific resource 'approve token' are clear. However, it does not distinguish from sibling tools like fuse_smart_approve_and_call or fuse_smart_approve_nft, which are related but have different scopes.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as requiring a configured smart wallet or funded gas, nor any comparison to sibling approve 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 must disclose behavioral traits. It mentions 'ERC-4337 UserOperation' which implies bundler submission and delayed execution, but does not explain gas costs, potential failures, need for smart wallet deployment, or how to obtain results. The description lacks sufficient 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 two sentences, front-loaded with the primary action and a usage note. No redundant information; 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 complexity of ERC-4337 and the absence of annotations or output schema, the description covers the core purpose and when to use but lacks details on execution flow, error handling, and result retrieval. It is adequate but not comprehensive.

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

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

The input schema provides 100% coverage with clear descriptions for all three parameters. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action ('submits an ERC-4337 UserOperation'), the resource ('arbitrary calldata on a contract from the configured smart wallet'), and distinguishes from siblings like 'fuse_write_contract' (which likely sends a regular transaction) and batched variants. It also provides a usage hint ('Use when you need full control over the encoded 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?

The description implies when to use ('need full control over the encoded call'), but does not explicitly state when not to use or mention alternatives such as 'fuse_send_native', 'fuse_smart_transfer_token', or 'fuse_smart_approve_and_call'. Guidance is present but minimal.

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 key behavioral traits: batch atomicity and that failed sub-calls revert the whole batch. It does not mention prerequisites or return behavior, but the core functionality is 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?

Two sentences, no redundant information, front-loaded with the main action (submit UserOp) and key details (atomic, revert on failure). Every word contributes.

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

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

The description covers the essential behavior but omits return value information (e.g., UserOp hash) and prerequisites (e.g., deployed smart account). Given no output schema and the tool's complexity, more detail would improve completeness.

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

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

The input schema has 100% description coverage, so the schema already explains the 'calls' parameter. The main description adds no additional semantic value beyond what the schema provides.

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 (single call) and fuse_smart_transfer_token (single transfer) by specifying batch atomic 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 implies usage for batch execution but does not explicitly state when to use this tool vs alternatives like fuse_smart_call_contract for a single call. No when-not or exclusion criteria are provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return values but does not mention read-only nature, side effects, error conditions, or prerequisites like authentication.

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 wasted words, efficiently conveying 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?

Given no parameters and no output schema, the description adequately states what is returned. However, it does not explain terms like 'configured signer' or possible errors, leaving some gaps.

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

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

With zero parameters and 100% schema coverage, the baseline is 4. The description does not need to add parameter details.

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

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

The description clearly states it returns the ERC-4337 smart-wallet address and paymaster status, using the verb 'Returns' and specifying the resource. It distinguishes from siblings like fuse_get_signer_address and other smart tools.

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

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

No guidance on when to use this tool vs alternatives. The description implies usage for getting smart-wallet info, but lacks explicit when/when-not or references to 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?

No annotations are provided, so the description carries full burden. It mentions ERC-4337 UserOperation but does not disclose that it is a state-changing transaction with gas costs, potential reverts, or asynchronous behavior. This lacks sufficient behavioral context for safe use.

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

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

The description is extremely concise, using a single sentence that front-loads the main action. Every word is necessary, with no filler or 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 simple state-changing tool, the description covers the core action and a prerequisite. However, it lacks details on outcomes, error handling, or post-invocation behavior. Given no output schema and 100% param coverage, it is adequate but not comprehensive.

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

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

Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; the schema already notes that tokenAddress must match a staking options entry. No additional parameter details are provided.

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 stakes a token via an ERC-4337 UserOperation using Fuse's staking module. It uses a specific verb-resource pair and distinguishes itself from siblings like fuse_smart_unstake_token and fuse_get_staking_options.

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 listing options first with fuse_get_staking_options, establishing a clear prerequisite. However, it does not explicitly mention when not to use or compare to alternatives like unstaking, but the context is implied.

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 burden. It mentions submitting a UserOperation (a write operation) but doesn't disclose details about gas costs, slippage, or failure handling. It implies a prerequisite (quote) but doesn't explain the result or return value.

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 redundancy, essential information 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?

While the description explains the tool's action and prerequisite, it lacks details on the return type (e.g., transaction hash), error conditions, or how to handle the result. Given no output schema, more context would be beneficial.

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 descriptions for all 4 parameters. The description adds no additional meaning beyond the schema, meeting the baseline for high 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 verb 'submits an ERC-4337 UserOperation executing a swap' and the resource 'on Fuse via the Fusebox trade engine'. It distinguishes from sibling tools like fuse_get_trade_quote (quote) and other fuse_smart_* tools (different actions).

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

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

The description explicitly says to 'quote a swap first with fuse_get_trade_quote to preview the route', providing clear when-to-use guidance. It implies this tool is for execution after quoting, not for quoting itself.

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 states the action without detailing side effects, asynchronous nature, gas costs, or prerequisites (e.g., previous approval). The behavioral burden is not met.

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 directly states the tool's purpose without extraneous words. It is front-loaded and 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 tool with 3 required parameters and no output schema, the description provides minimal context. It does not explain return values, expected behavior after submission (e.g., userOpHash), or required conditions like authentication or balance sufficiency. More detail 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 description coverage is 100% with detailed parameter descriptions (e.g., tokenId as decimal/hex). The tool description adds no extra meaning beyond what the schema already provides, so baseline score of 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?

The description clearly specifies the action: submitting an ERC-4337 UserOperation to transfer an NFT. It identifies the resource (NFT) and distinguishes from siblings like fuse_smart_transfer_token (for tokens) and fuse_smart_approve_nft (approval).

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 guidance on when to use this tool versus alternatives like fuse_smart_transfer_token or fuse_send_native. The context of 'smart wallet' and 'ERC-4337' implies account abstraction use, but no direct comparisons or exclusions are given.

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

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

No annotations are provided, so the description carries full burden. It discloses the operation type (ERC-4337 UserOperation) and gasless condition, but does not mention auth requirements, prerequisites (e.g., approval), or irreversible effects. Basic but missing details expected for a smart wallet token transfer.

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), front-loaded with the core action, and every sentence provides necessary context. 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?

The tool involves ERC-4337 and smart wallets, which are complex. The description does not explain what 'configured smart wallet' means, nor does it describe the return value (e.g., userOpHash) since there is no output schema. Adequate for a simple token transfer, but incomplete for the smart wallet 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 high (75%). The description does not add any parameter-specific meaning beyond what the input schema already provides. Baseline score applies as no extra value is 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?

The description clearly states the action ('Submits an ERC-4337 UserOperation transferring a token') and the resource ('from the configured smart wallet'). It distinguishes from siblings like fuse_send_erc20/fuse_send_native by specifying smart wallet context and gasless condition.

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 gasless when enabled but does not explicitly specify when to use this tool over alternatives like fuse_send_erc20 or fuse_send_native. It implies smart wallet usage via the name, but lacks clear when-to-use and 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?

With no annotations, the description carries full burden. It only states the tool submits a UserOperation, but fails to disclose that this is a write operation requiring gas fees, prior approvals, or any side effects. The behavioral implications are insufficiently communicated.

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 is concise, but it is under-specified. The structure is clear, but the description could include more useful detail without becoming verbose. It earns its place but leaves gaps.

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

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

Given the complexity of DeFi staking, the absence of output schema, and no annotations, the description is incomplete. It does not explain return values, whether the operation is simulated or submitted, success/error conditions, or operational steps like signing. More context is needed for an agent to use it 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 has 100% coverage with descriptions for all 3 parameters. The description adds only the context of ERC-4337 UserOperation, not enhancing parameter meaning beyond what the schema already provides. 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?

Description clearly states the tool submits an ERC-4337 UserOperation to unstake a token via Fuse's staking module. It specifies the action (unstake), the resource (token), and the mechanism (UserOperation), distinguishing it from the sibling stake tool.

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

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

No explicit guidance on when to use this tool versus alternatives, such as prerequisites like having staked tokens or the need for the receipt token address. The description does not mention when-not-to-use or provide context for selection from 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?

No annotations provided, so description carries full burden. Discloses the core behavior (submit signature, get JWT) but does not mention error handling, token expiration, or side effects. Adequate for a straightforward auth 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 key purpose, second sentence clarifies responsibility. 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?

The description explains the purpose and the flow, and gives an example of a dependent tool. It implies the output is a JWT but does not explicitly state the return format. Still complete enough for an agent to 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?

All 4 parameters have schema descriptions, and the description adds context about client-side signing. Schema coverage is 100%, so baseline 3 is appropriate. No additional semantics 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 the tool exchanges an EIP-191 signature for a JWT to use as Bearer auth on Smart Wallet API calls. Provides a specific example (fuse_smart_wallet_get_actions). Distinct from siblings which deal with contracts, queries, etc.

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?

Explains that signing is client-side and this tool only submits the signed payload, guiding the agent to call this after client-side signing and before smart wallet API calls. Does not explicitly state when not to use, but context is clear.

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

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

No annotations are provided, so the description carries the burden. It mentions pagination and the type of actions (transfers, contract calls) but lacks details on behavior like read-only nature, error handling, or performance. Adequate but not rich.

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 verb 'List', no redundant information. Every sentence provides essential context.

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

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

The description covers purpose, authentication requirement, and pagination, but without an output schema, it lacks details on return fields or structure. Sibling tools are diverse, but the description adequately orients the agent.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning beyond context (e.g., paginated history, JWT source), but does not significantly 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 clearly states the tool lists paginated action history (transfers, contract calls) for an authenticated smart wallet. It distinguishes from siblings like fuse_smart_wallet_authenticate (authentication) and fuse_smart_get_info (wallet info), providing a specific verb and resource.

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

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

The description explicitly mentions the JWT comes from fuse_smart_wallet_authenticate, guiding the agent to first call authentication. It implies usage context for authenticated wallets but does not specify when not to use it or alternatives for other data.

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 does not disclose whether the tool is read-only, any authorization needs, rate limits, or potential side effects. It only states the return type but lacks behavioral context beyond that.

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 concise with two sentences, front-loading the main purpose. No unnecessary information is included, making it easy to parse quickly.

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 15 parameters, the description only addresses one constraint. There is no explanation of the response format beyond '0x-style', and no output schema is provided. For a tool of this complexity, more context is necessary.

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 60% parameter description coverage in the schema, the description adds value by clarifying the mutual exclusivity of sellAmount and buyAmount. However, it does not elaborate on other parameters such as slippage, fee settings, or excludedSources.

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, specifying the response style (0x-style). It also notes that exactly one of sellAmount or buyAmount must be provided. However, it does not differentiate from sibling tools like fuse_get_trade_quote.

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 only usage guidance is that one of sellAmount or buyAmount must be provided. There is no indication of when to use this tool versus other trade-related tools (e.g., fuse_get_trade_quote or fuse_smart_swap_tokens), nor any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries full burden. It indicates a read operation ('Returns') but does not disclose any behavioral traits such as caching, cost, or authentication requirements. For a simple zero-parameter read, this 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, clear sentence with no fluff. It is properly front-loaded with the verb 'Returns' and includes examples. 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 the tool has no parameters, no output schema, and is a simple query, the one-sentence description with examples is complete. It fully explains what the tool returns and provides concrete 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?

The tool has no parameters, so the description does not need to explain parameters. The description adds value by describing the return (liquidity sources), which compensates for the lack of parameters. Baseline for 0 params is 4.

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

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

The description clearly states 'Returns the liquidity sources currently enabled for Fuse-chain trades' and gives concrete examples ('voltage.finance, sub-pools'), specifying verb and resource. This distinguishes it from sibling tools like fuse_trade_indicative_price which deal with pricing rather than liquidity sources.

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 retrieving available liquidity sources before trading, but does not explicitly state when to use this tool versus alternatives like fuse_trade_indicative_price. It lacks explicit guidance on prerequisites or when-not-to-use, though the purpose is clear.

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

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

The description discloses the return shape ({ priceChange, currentPrice, previousPrice }), which is helpful. However, without annotations, there is no mention of potential errors, data freshness, or any side effects. The description is adequate but lacks depth for a tool with no annotations.

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

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

The description is a single, well-structured sentence that immediately conveys the tool's purpose and result. No extraneous words or information.

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

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

Given the tool's simplicity (2 parameters, no output schema), the description covers the core functionality and return format. It could be improved by mentioning what 'price change' means (e.g., absolute or percentage) or any constraints, but it is largely complete.

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

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

The input schema has 100% coverage, so the schema already explains both parameters. The description adds only the phrase 'custom day-count window' which aligns with the 'days' parameter but does not provide additional meaning beyond the schema.

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

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

The description clearly states the verb 'Returns', the resource 'token's price change', and the scope 'over a custom day-count window'. It distinguishes from similar tools like fuse_get_token_price (which returns a single price) and fuse_get_token_price_history (which returns a series).

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 computing price changes over a custom number of days, but it does not explicitly state when to prefer this tool over alternatives like fuse_get_token_price or fuse_get_token_price_history. No exclusion criteria or context is provided.

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

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

With no annotations, the description must fully disclose behavioral traits. It states the tool mutates state and returns a transaction hash, but does not mention prerequisites (e.g., sufficient gas balance), potential reversions, or nonce handling. This is adequate but lacks critical context for 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?

Two concise, front-loaded sentences: first states the primary action, second adds key context (ABI auto-fetch and return value). No fluff, 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 write operation with no output schema, the description covers the action, ABI handling, and return type. It lacks mention of error scenarios or gas requirements, but is reasonably complete given the tool's complexity and sibling differentiation.

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 value by explaining that ABI is auto-fetched when not supplied, which clarifies the optional 'abi' parameter behavior beyond the schema. This extra context improves 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 clearly states it signs and submits a state-mutating contract call, distinguishing it from read-only tools like fuse_read_contract. It specifies the verb 'signs and submits', the resource 'contract call', and the context 'from the server's signer', making the purpose unambiguous.

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

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

The phrase 'state-mutating' explicitly indicates this tool is for write operations, differentiating it from read tools. However, it does not provide explicit when-not-to-use scenarios or alternatives beyond this implicit distinction. The auto-fetching behavior is mentioned, which guides usage when ABI is not supplied.

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