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

Annotations already provide idempotentHint and destructiveHint, but description adds behavioral context: the approval is a write operation, and 'max' grants unlimited spending until revoked, which is critical safety 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?

Four sentences, each essential. Front-loaded with action and necessity, followed by parameter guidance. No redundant or vague language.

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 needed; effect is clear. Covers prerequisite, parameter choices, and safety considerations. Complete for this 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?

Schema already covers parameters with descriptions (100% coverage). Description adds value by explaining the rationale for exact vs max amount and the risk of max, which goes beyond schema syntax.

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?

Describes the specific action (approve JST for WJST voting contract), states the prerequisite role, and distinguishes from sibling approval tools by naming the target contract and use case.

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

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

Explicitly states when to use (before depositing JST for voting), provides clear recommendation for amount parameter (exact amount recommended, 'max' only with user opt-in), and warns about consequences of unlimited approval.

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

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

Annotations indicate idempotentHint=true and not destructive. The description adds context about the implications of 'max' (unlimited spending until revoked) and the recommended exact amount. It does not contradict 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?

Three sentences: purpose, prerequisite, and detailed instruction. Front-loaded with key action. No redundancy or 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 the tool's simple nature (approval with a key parameter), the description covers purpose, usage context, and parameter nuance. It also mentions the follow-up tool (moolah_liquidate) and revocation, making it complete for agent use.

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

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

Schema covers all parameters (100%), baseline 3. The description significantly enriches the 'amount' parameter with actionable guidance beyond the schema, explaining the trade-offs of 'exact' vs 'max' and how to revoke.

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 'approve' and the specific resource 'loan token spending for the Moolah public liquidator contract'. It distinguishes this tool from sibling approval tools by naming the specific contract and linking to moolah_liquidate.

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 when to use: 'Required before calling moolah_liquidate.' Provides guidance on amount usage and warns about 'max' only with user opt-in, and mentions revoking with amount='0'.

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 clearly explains the behavior beyond annotations: it details the two approval modes (exact vs. max) and their consequences, including the risk of unlimited spending. It also specifies that the tool writes transaction data (implied by 'approve' and not read-only). No contradiction with 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 concise (few sentences), front-loaded with the core purpose, and each sentence adds unique guidance. It does not waste 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 covers the purpose and usage well but does not mention the output (e.g., transaction hash) or prerequisites (e.g., wallet must be connected). Given the tool's complexity (blockchain approval), the description could be more complete by explaining the expected result and any necessary prior actions. However, the high schema coverage and annotations partially compensate.

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 covers all parameters with descriptions (100% coverage). The tool description adds extra context for the 'amount' parameter, specifying when to use exact vs. max and the associated risks, which enhances semantic understanding beyond the schema's pattern and description. For other parameters, the description doesn't add new info, but the schema is sufficient.

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

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

The description clearly states the action (approve TRC20 token spending), the target (Moolah core contract), and the context (before supplying collateral or repaying). It also explicitly notes it's not needed for TRX operations, distinguishing it from other operations. Given sibling tools have different approval targets, this description effectively differentiates.

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

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

The description explicitly states when to use the tool (before supplying collateral or repaying), what amount to pass (exact recommended, 'max' only with explicit user opt-in), and what not to use it for (TRX operations). This provides clear decision guidance for the AI agent.

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

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

Annotations indicate idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful context: it's a prerequisite for deposit, not needed for TRX vaults, and explains the risk of 'max' approval and revocation ('amount=0'). No contradiction with 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 three concise sentences with no wasted words. It front-loads the purpose and key guidance, 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?

For a simple approval tool with no output schema, the description covers all necessary context: what it does, when required, parameter tips, and safety warnings. It is complete for the task.

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

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

Schema has 100% coverage with parameter descriptions. The description adds significant nuance for the 'amount' parameter (exact vs. max, revocation nuance), improving the agent's understanding beyond the schema. The other parameters ('vaultSymbol', 'network') are not elaborated, but the added value for 'amount' raises the score.

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

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

The description clearly states the tool approves TRC20 token spending for a Moolah vault before depositing, distinguishing it from TRX vaults and other approval tools. It specifies the action, resource ('Moolah vault'), and scope, setting it apart from siblings like 'approve_moolah_proxy'.

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 tells when to use (before depositing, not for TRX vaults) and gives recommendations (exact amount preferred, 'max' only with user opt-in). It lacks explicit mention of alternatives among sibling approve tools, but the 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?

Discloses important behavioral traits: cost (~23k energy + 265 bandwidth), idempotent (safe to call repeatedly), and risk of unlimited approval. Annotations (idempotent=true, destructive=false) are consistent, and description adds significant context beyond them.

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

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

Very concise: four sentences covering purpose, prerequisite, amount recommendation with caveat, and cost. No filler; each sentence earns its place. Front-loaded with core action.

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

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

Given no output schema, the description fully covers what an agent needs: prerequisites (TRC20 markets), parameter usage (amount, market, network), edge cases (max approval), and cost. Complete for a transaction tool.

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

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

Schema coverage is 100%, but description adds value by explaining the amount parameter's practical meaning (exact vs. max with security warning) and the context of market parameter (jToken symbol). Does not merely repeat 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 approves jToken contract to spend underlying TRC20 tokens. Specifies when required (before supply/repay for TRC20 markets, not for jTRX), distinguishing it from sibling approve tools like approve_jst_for_voting.

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 when to use (required before supply/repay for TRC20 markets) and when not (jTRX). Provides clear guidance on amount: recommend exact, 'max' only with explicit user opt-in. No ambiguity.

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

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

Annotations already show readOnlyHint=true, so the description's behavioral context about auto-detection and incremental cost calculation adds value beyond annotations. It discloses that for renewals it subtracts existing security deposit, which is a key behavioral detail.

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

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

The description is about 100 words, front-loaded with the core purpose, and well-structured with separate sections for new and renewals. It could be slightly more concise but no unnecessary 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?

The description lists return values (important since there's no output schema), explains auto-detection for renewals, and gives parameter context. It could specify units or output format, but overall it's sufficient for an agent to use correctly.

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

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

Schema coverage is 100% but the description adds meaning by clarifying the different minimums for new (300,000) vs renewal (50,000) and the conditional requirement of durationHours. This goes beyond the schema's generic 'minimum 50,000' and 'required for new' context.

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 calculates the cost to rent energy for a given duration, and distinguishes between new rentals and renewals. It lists the specific return values, and the contrast with siblings like 'get_energy_rental_rate' (rate only) and 'rent_energy' (executes) is implicit.

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 tells when to use each parameter combination (new vs renewal) and mentions auto-detection of existing rentals. It does not explicitly list when not to use this tool, but the context of siblings and the detailed parameter guidance make it 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?

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds value by explaining the support parameter's boolean semantics and the ability to stack votes on a previously voted proposal, which goes beyond the schema.

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 three sentences with no filler. Each sentence serves a purpose: prerequisite, parameter explanation, and notable capability. Front-loaded with the core action.

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

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

The description covers prerequisites and parameter behavior but omits details about the return format, error scenarios (e.g., insufficient votes, invalid proposal), and any side effects. For a mutation tool with destructiveHint=true and no output schema, this leaves uncertainty for 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 coverage is 100% and descriptions already exist. The description adds nuance by clarifying that the 'support' true/false corresponds to FOR/AGAINST (redundant but helpful) and that 'votes' can be used to add to an existing vote on the same proposal, which is not in 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 ('Cast a vote') and resource ('governance proposal'), and distinguishes from sibling tools like deposit_jst_for_votes or withdraw_votes by focusing on the actual voting action, including semantics for support and the ability to add votes.

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

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

The description provides a clear prerequisite ('must have available votes, deposit JST first if needed') and notes that repeated use is allowed for adding more votes. However, it does not explicitly contrast with alternatives like checking vote status or withdrawing votes.

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?

Description reinforces annotations (readOnlyHint=true, destructiveHint=false) by stating it's a check. Adds context about prerequisite step, no contradictions. High 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, front-loaded with action, no unnecessary words. Efficient and clear.

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

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

For a simple read-only check, description is complete. No output schema needed; binary result is implied. Provides full context for agent to select and invoke correctly.

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

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

Schema coverage is 100% and parameters are well-described with defaults and patterns. Description adds no extra meaning beyond schema. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'check' and the resource 'JST allowance for WJST voting contract'. It distinguishes from siblings like 'check_allowance' by specifying the context and from 'approve_jst_for_voting' which is the write counterpart.

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 'Must be approved before depositing JST to get votes', indicating when to use and implying the need for 'approve_jst_for_voting' if not approved. Provides clear context and alternatives.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds specific behavioral details: it shows staked amount, claimable rewards, rounds, and withdrawal status, which clarifies what data the tool returns. No contradictions with 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 concise sentence that efficiently communicates purpose and output. It is front-loaded with the main action and resource. A slight improvement could be listing outputs more explicitly, but it is still 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's low complexity (2 optional params, no output schema), the description adequately covers what it does and what it returns. However, it does not elaborate on conditions for withdrawal eligibility (e.g., whether unbonding period has passed) or reinforce read-only nature, but it is sufficient for a simple check tool.

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

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

Schema coverage is 100%, with both address and network parameters documented. The description does not add per-parameter details beyond the schema, but it indirectly provides context by explaining the tool's purpose. Baseline 3 is appropriate as the description does not enhance parameter understanding.

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

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

The description clearly states the verb 'Check' and the specific resource 'TRX available to withdraw after sTRX unstaking unbonding period'. It also lists key data shown: staked amount, claimable rewards, pending/completed unstake rounds, withdrawal status. This distinguishes it from sibling tools like get_strx_balance or get_strx_account, which are more general.

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 the context of checking after unbonding period but fails to mention exclusions or alternative tools (e.g., get_strx_records) that might be more appropriate for other queries.

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

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

Discloses on-chain pre-checks (isClaimed, merkleRoots) to avoid gas waste on reverting transactions. Annotations already mark destructiveHint=true, but the description adds valuable context about gas-saving behavior and current network restrictions.

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

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

Three sentences efficiently convey purpose, usage options, pre-checks, and network status. Front-loaded with core action, 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?

Thoroughly covers all aspects needed for an agent to use the tool: method, input options, pre-checks, and current deployment status. No output schema needed since it's a mutation.

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 provides full parameter descriptions (100% coverage). The description adds value by highlighting periodKey as preferred and explaining how override params work. Slight deduction because the schema already does 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?

Clearly states it claims a single V2 mining airdrop round via multiClaim(). Distinguishes from sibling claim_v1_mining_period by specifying V2 and referencing get_moolah_pending_mining_periods for periodKey.

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 recommends using periodKey from get_moolah_pending_mining_periods or supplying override params directly. Warns about mainnet error and suggests nile testnet as alternative. Provides clear when-to-use and current limitations.

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

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

Annotations already indicate a write operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds cost information not in annotations, but does not disclose edge cases like no rewards, network-specific behavior, or transaction confirmation.

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

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

Two sentences: first states purpose, second adds cost detail. No redundant information, front-loaded, and efficient. Every sentence earns its place.

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

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

The description covers the main action and cost but lacks details on return value, transaction behavior, or error handling. For a simple write operation with no output schema, it is minimally adequate but could provide more context.

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

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

There is one optional parameter (network) with 100% schema coverage. The description does not add any additional meaning beyond what the schema provides, 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 the action ('Claim'), resource ('accrued JustLend mining rewards'), and scope ('for the configured wallet'). It distinguishes from siblings like 'claim_strx_rewards' and 'claim_moolah_mining_period' by specifying the reward type and protocol.

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 typical cost but does not provide explicit guidance on when to use this tool versus alternatives. It implies usage when claiming JustLend rewards, but lacks prerequisites or exclusions.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds the pre-check behavior, but does not elaborate on other side effects or state changes beyond what annotations imply.

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 front-loaded sentences, no unnecessary words, and clearly communicates the purpose and a key behavioral aspect.

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 optional parameter and no output schema, the description covers the purpose and pre-check behavior. Schema covers the parameter, so it is sufficiently complete.

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

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

Schema coverage is 100% for the single 'network' parameter. The description does not add any additional meaning beyond the schema, 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 states the tool 'Claim all available sTRX staking rewards' using a specific verb and resource. It distinguishes from sibling tools like 'claim_rewards' by specifying sTRX staking.

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

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

The description mentions a pre-check for claimable rewards, implying safe usage, but does not explicitly state when to use this tool versus alternatives like 'get_claimable_rewards' or when not to use it.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the tool modifies state. The description adds behavioral context by detailing the routing logic (multi-merkle vs USDDNEW vs main distributor), which goes beyond annotations. It also specifies mainnet-only, a key constraint. The description does not mention gas costs or failure modes, but with annotations present, 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 three sentences, each serving a purpose: action, parameter options, and routing logic. It is front-loaded with the core purpose and contains no fluff. Every sentence earns its place, making it highly efficient.

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

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

Given the tool's complexity (11 parameters, no output schema), the description covers the main use case, parameter approaches, routing, and network restriction. It does not mention prerequisites (e.g., eligibility) or output details, but annotations cover the destructive nature. Overall, it provides sufficient context for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so each parameter already has a description. The tool description adds value by explaining the preferred usage of key and the routing logic that depends on amount, selector, and distributor. This helps the agent understand parameter interactions beyond the schema, earning a score above the baseline of 3.

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

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

The description clearly states the tool claims a single V1 mining airdrop round via multiClaim() on the appropriate merkle distributor. The verb 'claim' paired with the specific resource 'V1 mining airdrop round' and mechanism 'multiClaim()' makes the purpose unambiguous. It also distinguishes from the sibling 'claim_moolah_mining_period' by explicitly mentioning V1 and routing logic.

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 guidance on using the key from get_claimable_rewards (preferred) or directly supplying merkleIndex/index/amount/proof, and specifies mainnet-only. However, it does not compare this tool to other claim tools like claim_moolah_mining_period or explain when not to use it, so the guidance is partial.

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?

Disclosures match annotations (destructiveHint=true) and add value by stating that deposited JST can be withdrawn after voting. No contradiction.

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

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

Three concise sentences covering action, prerequisite, conversion, and reversibility. No 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?

Complete for its complexity: explains workflow, prerequisites, conversion, and withdrawal. Aligns well with sibling tools.

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

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

Schema has 100% coverage for parameters. Description adds meaning with '1 JST = 1 Vote', clarifying the impact of the 'amount' parameter beyond 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 the action (deposit), resource (JST into WJST contract), and purpose (get voting power). It distinguishes from sibling tools like 'approve_jst_for_voting' and 'withdraw_votes_to_jst'.

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 prerequisite (use approve_jst_for_voting first), guiding the agent on the correct sequence. Lacks explicit 'when not to use' but provides clear 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?

Annotations indicate idempotentHint=true and readOnlyHint=false, so the tool is a safe-to-repeat mutation. The description adds valuable behavioral context: the effect on borrowing capacity and the typical cost (~80,000 energy + ~300 bandwidth). It does not cover potential errors or prerequisites beyond 'supplied assets', but overall adds transparency beyond 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 four short sentences, front-loaded with the primary action. Every sentence adds value: purpose, prerequisite, effect, and cost. No unnecessary words 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?

Given no output schema, the description explains the key behavioral outcome (supply counts toward borrowing capacity) and cost. It could mention that supplying must occur before entering, but that is implied by 'Required before borrowing against supplied assets.' It is sufficiently complete for a tool with two simple parameters.

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

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

Schema description coverage is 100%, and the description adds no new information about the parameters beyond what the schema already provides (e.g., 'market' is a jToken symbol). The example in the schema ('jUSDT', 'jTRX') is sufficient, so the description does not improve 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 action: 'Enable a jToken market as collateral.' It specifies the verb 'enable' and the resource 'jToken market', and distinguishes from sibling tools like exit_market and borrow by noting it is required before borrowing.

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

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

The description explicitly states when to use: 'Required before borrowing against supplied assets.' It also explains the effect: 'Once entered, your supply in this market counts towards your borrowing capacity.' However, it does not explicitly state when not to use or mention alternatives like exit_market.

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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds crucial behavior: 'Tries on-chain simulation first; falls back to historical typical values if simulation fails.', 'Returns per-step breakdown...', and 'For supply/repay: automatically checks current allowance — if sufficient, the approve step is skipped.' This provides transparency about reliability and edge cases.

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

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

The description is front-loaded with purpose and well-structured. It lists operations in a sentence and explains fallback, breakdown, and special cases. It is slightly long but each sentence adds value; a minor trim could improve conciseness without losing information.

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

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

Despite no output schema, the description explains the return value: per-step breakdown, total energy, total bandwidth, estimated TRX cost. It covers all operations, fallback behavior, and handle edge cases (allowance check, custom spender). This is complete for an estimation 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?

All 6 parameters have schema descriptions (100% coverage). The description adds significant meaning: explains default amount ('1'), clarifies spender usage for approve, and notes which operations omit amount (enter_market, withdraw_all, etc.). This enriches understanding 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?

The description clearly states the tool estimates energy, bandwidth, and TRX cost for any JustLend operation before execution. It lists all covered operations (supply, withdraw, etc.) and implies it is for estimation, not execution. This is specific and distinguishes from siblings like estimate_moolah_energy.

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 tells when to use: 'whenever the user asks about gas/energy/cost for any lending operation'. It also says 'BEFORE executing' which implies it is not for after the fact. While it does not explicitly state when not to use, the context and fallback behavior are clear. Could be more explicit about alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by disclosing that results are 'historical typical values' and that on-chain simulation is not wired, which are important limitations not present in 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 compact and front-loaded with the main purpose. It efficiently conveys key information without unnecessary words, though it could be slightly more streamlined.

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

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

With no output schema, the description does not detail return values but acknowledges they are historical typical values. For 4 parameters and no nested objects, the description provides sufficient context for a typical estimation tool, though more precision on output format would help.

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 context for isTRX (explaining when to set true) and enumerates all valid operation values. This additional guidance goes beyond the schema descriptions.

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

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

The description clearly states the tool estimates energy, bandwidth, and TRX cost for Moolah write operations. It specifies the domain (JustLend V2/Moolah) and distinguishes from sibling execution tools like moolah_borrow or other estimation tools like estimate_lending_energy.

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 instructs when to set isTRX=true and notes that estimation should happen before executing. It lists all covered operations. However, it does not explicitly exclude other protocols or provide guidance on when not to use this tool vs. estimate_lending_energy.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds value by detailing pre-checks and cost (~50,000 energy + ~280 bandwidth). No contradiction with 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 concise (one sentence plus bullet list) and front-loaded with the core action. Every sentence provides necessary information without waste.

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

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

Given the tool's two parameters and no output schema, the description covers pre-conditions and cost sufficiently. It could mention reversibility or outcome, but is adequate for selecting and invoking the 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 parameters are well-described in the schema. The description does not add new semantic details beyond the schema, meeting the baseline of 3.

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

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

The description clearly states the action (disable as collateral) and resource (jToken market). It distinguishes from the sibling 'enter_market' (the opposite operation). The pre-checks further clarify the purpose.

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

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

The pre-checks provide explicit conditions when the tool can be used (no borrows, sufficient remaining collateral). However, it does not explicitly state when not to use or mention alternatives like 'withdraw' or 'enter_market'. The conditions are clear but not exhaustive.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by detailing the return structure (map keyed by round with merkleIndex, amount, token info) and the intended follow-up action, which goes beyond what annotations provide.

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

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

Three sentences that are front-loaded with the main action and result. Each sentence adds essential information: what it does, what it returns, and how to use it. 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?

Despite no output schema, the description explains the return format sufficiently. It also mentions mainnet-only and the follow-up tool. For a read-only query tool with annotations, this is 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 covers both parameters (address and network) with descriptions. The description reinforces network must be mainnet but adds no new parameter meaning. Schema description coverage is 100%, 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 scans all JustLend V1 merkle airdrop distributors for unclaimed rewards, and distinguishes itself from sibling tools like claim_v1_mining_period and other 'get_' tools by specifying the action and the follow-up tool. The verb 'scan' and resource 'JustLend V1 merkle airdrop distributors' are specific.

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

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

The description explains this tool is used before claim_v1_mining_period to obtain claimable rewards data. It also notes mainnet-only, providing clear context. It does not explicitly state when not to use it, but the context is sufficient.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by listing returned data fields, but no further behavioral traits (e.g., performance, rate limiting) are disclosed.

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-loaded with purpose, lists examples efficiently. No redundancy or filler.

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

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

Given low complexity (1 optional param, no output schema, rich annotations), the description is fairly complete, naming key outputs. Could mention network parameter effect or output format for full 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?

Input schema has 100% coverage with one parameter (network) described. The description does not enhance parameter meaning beyond the schema's 'Network. Default: mainnet'.

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 retrieves dashboard data for JustLend energy rental market, listing specific metrics. It distinguishes from siblings like get_energy_rental_params and get_energy_rental_rate by the 'dashboard' scope, but does not explicitly contrast with them.

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?

Usage context is implied by the 'dashboard' scope versus more specific sibling tools, but no explicit when-to-use 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?

Annotations (readOnlyHint, idempotentHint, etc.) already indicate safe read. Description adds specific list of returned fields, providing behavioral context beyond annotations. No contradictions.

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 listing parameters. Slightly verbose but no unnecessary words. Front-loaded with purpose.

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

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

Tool is simple (1 optional param, no output schema). Description fully covers what it returns. No gaps.

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

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

Schema covers 100% with one optional parameter. Description adds default value 'mainnet' not in schema, clarifying optionality and default behavior.

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

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

Clear verb 'Get' and resource 'on-chain energy rental parameters'. Lists specific parameters returned. Distinguishes from siblings like get_energy_rental_rate by focusing on overall parameters vs. rate.

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 alternatives. Context suggests it's for retrieving static parameters, but no guidance on when to use this versus other energy rental getter tools (e.g., get_energy_rental_dashboard).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing it as a safe read. The description adds the behavioral detail that the effective rate is the max of both rates. However, it does not disclose the default network (mainnet) or that trxAmount=0 gives base rate, which are present in the schema but not the description.

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

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

Two sentences with no wasted words. The first sentence states purpose, the second describes output. Concise and front-loaded.

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

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

Given no output schema, the description explains the return values (rental rate, stable rate, effective rate). It covers the primary input and basic output. Missing a mention of the network parameter, but it has a default. Adequate 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?

Schema description coverage is 100%, so the schema already documents both parameters. The description merely restates 'for a given TRX amount' without adding new semantics or format details. 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 ('Get'), the resource ('energy rental rate'), and the input ('given TRX amount'). It also lists the returned values (rental rate, stable rate, effective rate), which distinguishes it from sibling tools like get_energy_rental_params or get_energy_rental_records.

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 querying rates, but provides no explicit guidance on when to use this tool versus alternatives such as get_energy_rental_dashboard or get_energy_rental_params. No when-not or alternative tool mentions.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that it is paginated and mainnet-only, and lists specific action types included. This provides additional behavioral context beyond the 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 two sentences long, front-loaded with the main verb 'Get', and contains no redundant or unnecessary information. Every sentence contributes 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?

Without an output schema, the description does not detail return format, but it clearly defines the content as a historical action log and contrasts it with active orders. It mentions pagination and mainnet-only. This is sufficient 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?

Schema coverage is 100%, so the schema already describes all parameters. The description does not add extra semantics beyond the schema, except implicitly confirming network must be mainnet. Thus, baseline score of 3 is appropriate.

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

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

The description clearly states it retrieves the user's JustLend energy-rental history, listing specific actions (rent, extend, rent_more, end, recycle). It explicitly distinguishes from the sibling tool get_user_energy_rental_orders which returns current active orders, making the purpose specific and unambiguous.

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

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

The description explicitly contrasts with the sibling tool: 'Distinct from get_user_energy_rental_orders which returns current active on-chain orders — this one returns the full historical action log.' It also notes pagination and mainnet-only usage, providing clear guidance on when and how to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so description's main value is listing return fields. However, it does not disclose error handling (e.g., if pair does not exist) or additional behavioral traits beyond 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?

Description is a single sentence with 22 words, front-loaded with action, no redundant information. Every word 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 read tool with 3 parameters and no output schema, the description lists three key return fields (security deposit, rent balance, active rental). This is sufficient for agent to 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?

Schema coverage is 100% with descriptions for all three parameters. Description adds no extra meaning beyond schema, so baseline 3 is appropriate.

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

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

Description uses specific verb 'Get' and clearly identifies resource: on-chain energy rental info for a specific renter-receiver pair. It distinguishes from siblings like get_energy_rental_dashboard (overall view) and get_energy_rental_records (list all).

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 a specific pair but does not explicitly state when to use this tool versus alternatives like get_energy_rental_dashboard. No exclusions or alternative tool names are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds context about pagination, mainnet constraint, and the structure of returned records (actionType range, fields), enhancing transparency beyond 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?

Two concise sentences with no unnecessary words. The first sentence immediately conveys the core purpose, and the second provides essential details about pagination and response fields.

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 return fields (actionType, actionName, token, amount, USD value, txId) and mentions pagination. However, it omits details on pagination behavior (e.g., default page size, max pages) and error conditions, but overall sufficient for a 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%, so the baseline is 3. The description does not add new parameter semantics beyond what the schema already provides; it only lists record fields in the response, not 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 retrieves a user's V1 JustLend transaction history, enumerates specific action types (supply, withdraw, borrow, repay, collateral enable/disable), and distinguishes itself from sibling tools like get_moolah_records by specifying the protocol and version.

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?

While it indicates the tool is Mainnet-only, it does not provide explicit guidance on when to use this tool versus alternatives such as get_moolah_records or get_liquidation_records. The description lacks when-not and alternative recommendations.

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

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

Annotations already mark it as read-only, idempotent, and non-destructive. The description adds that it is paginated and mainnet-only, which are behavioral constraints beyond what annotations provide. No contradictions with 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 two sentences, front-loaded with the core purpose. Every part is informative: what it does, coverage (both directions), distinction from sibling, pagination, and mainnet constraint. 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 explains the return type (liquidation history), covers key constraints (paginated, mainnet-only), and distinguishes from a sibling. It is fairly complete for a read-only tool, though it does not detail the exact fields in the output.

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 baseline is 3. The description adds context that the records include both directions of liquidation, but this is more about the output than parameter semantics. It does not add significant detail about parameter usage 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 it retrieves V1 JustLend liquidation history for a user, covering both liquidations initiated by the user and liquidations where the user was the target. It explicitly distinguishes from the sibling tool get_moolah_liquidation_records, which covers V2 Moolah liquidations.

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 guidance on when to use this tool by differentiating it from get_moolah_liquidation_records and noting it is mainnet-only. However, it does not specify when not to use it or mention other alternatives beyond the sibling.

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

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

Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond these annotations, but does not contradict them.

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

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

The description is a single sentence that is clear and efficient. It could be slightly more structured (e.g., mention return value) but remains 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?

No output schema is provided, and the description does not specify the return type or format. For a simple query tool, this is a moderate gap; the description implies a numeric value but could be more explicit.

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 parameter descriptions. The description does not add additional meaning beyond what is in the schema (e.g., defaults 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 explicitly states the tool retrieves the number of locked votes for a user and a proposal, using a specific verb and resource. It clearly distinguishes from sibling tools like cast_vote and withdraw_votes_from_proposal.

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

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

No guidance on when to use this tool versus alternatives (e.g., get_vote_info, get_vote_records). The description does not specify prerequisites or context for invocation.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds specific return fields (APY, TVL, utilization, etc.) and confirms it's for a specific market, providing useful behavioral context without contradiction.

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

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

Two sentences: first states purpose and output, second provides usage hint. No unnecessary words, front-loaded with key information.

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

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

No output schema, but description lists all returned fields. For a simple read-only data retrieval tool, the description provides enough context for an agent to understand inputs and outputs.

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 parameter descriptions. Description adds meaning by explaining jToken symbol and giving examples, adding value beyond schema definitions.

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

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

Description clearly states the tool retrieves detailed market data for a specific JustLend market, listing specific fields (supply/borrow APY, TVL, etc.) and giving a usage example (jToken symbol). This distinguishes it from siblings like get_all_markets.

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 jToken symbol like 'jUSDT' or 'jTRX'' and implies it's for a single market detail, but does not explicitly state when not to use or mention alternatives.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds scope details ('top' vaults/markets, optional user position) but does not provide significant additional behavioral context beyond what annotations convey.

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

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

Two sentences, front-loaded with the core purpose, no unnecessary words. Every sentence adds critical 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?

Without an output schema, the description does a good job listing the key fields returned (APY, TVL, borrow/supply rates, position details). However, it does not clarify what 'top' means (e.g., by TVL or APY), leaving a minor gap for 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 coverage is 100% with each parameter described. The description adds value by explaining that the user address triggers inclusion of an aggregated V2 position with specific fields (total supply, borrow, health factor), which is not fully captured in the schema descriptions.

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

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

The description clearly states the tool provides a protocol overview of JustLend V2, including top vaults (APY, TVL) and top markets (borrow/supply rates), and optionally the user's aggregated position. It distinguishes itself from siblings like get_moolah_vaults and get_moolah_markets by offering a composite dashboard.

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 a quick overview but does not explicitly state when to use this tool versus calling individual endpoints. It lacks guidance on when not to use it or alternatives, leaving the agent to infer usage from 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?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not reiterate safety. It adds value by specifying return types (position history and transaction records) but omits details like pagination or performance characteristics.

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 front-loaded with the action and result. It is concise, but it could be slightly more efficient by removing redundant phrasing (e.g., 'position history' and 'transaction records' are clear).

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

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

With three optional parameters and no output schema, the description adequately explains what the tool returns but does not detail the structure of the response. Given the lack of output schema, more information on the return format would improve completeness, but the description meets minimal expectations.

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 all three optional parameters. The description does not add any additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves a user's JustLend V2 position history and recent transaction records, using a specific verb ('Get') and resource ('history'). However, it does not explicitly differentiate from siblings like 'get_moolah_records' or 'get_moolah_user_position', which may overlap.

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 it is for historical data but provides no explicit guidance on when to use this tool versus alternatives. There are many similar 'get_*' tools, and the description lacks usage context, exclusions, or prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it 'returns the exact loan token amount needed', which is helpful behavioral context. No contradiction with 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?

Three concise sentences each adding distinct value: purpose, parameter usage, and pre-execution context. No wasted words, well front-loaded.

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

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

Despite no output schema, the description states what is returned. For a simple estimation tool, this is sufficient. It could be improved by mentioning return type or precision, but overall it is adequate.

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

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

Schema description coverage is 100%, so parameters are documented. The description adds crucial mutual exclusivity guidance ('Provide either...not both'), which goes beyond schema descriptions. This significantly aids correct invocation.

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 'estimate' and the resource 'loan token cost'. It distinguishes from the sibling tool 'moolah_liquidate' by noting it should be used before liquidation. The purpose is specific and unambiguous.

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

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

The description explicitly tells when to use this tool ('Use this before calling moolah_liquidate') and provides parameter guidance (not both seizedAssets and repaidShares). While it doesn't explicitly list alternatives, the context of being a quote tool before execution 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds that it returns historical events but does not disclose pagination behavior, response format, or whether filters are cumulative. The description adds minimal value beyond 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, concise sentence with no redundant information. It is well-structured and immediately conveys the core purpose.

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

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

For a tool with six optional parameters and no output schema, the description is minimal. It does not explain pagination via page/pageSize, nor does it mention that the tool is read-only (though annotations cover that). The description could be more complete given 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?

Schema description coverage is 100%, so all parameters already have descriptions. The tool description does not add additional meaning, e.g., it does not clarify that the 'type' parameter corresponds to the two types mentioned in the description. 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 retrieves historical liquidation events on Moolah, specifying both bot-executed and public liquidations. However, it does not differentiate from sibling tool 'get_liquidation_records', which may refer to a different protocol or 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?

No guidance is provided on when to use this tool versus alternatives such as 'get_moolah_pending_liquidations' or 'get_liquidation_records'. The description lacks any when-to-use or when-not-to-use 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?

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds value by listing specific data fields (APY, LLTV, utilization, total supply/borrow, vaults) included in the output, which is not in 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?

Two concise sentences: first defines purpose and scope, second offers sibling guidance. No unnecessary words.

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

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

Tool is a single-item query with safe read operations; description lists included fields (APY, LLTV, etc.) to set expectations. No output schema needed given this clarity.

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 provides descriptions for both parameters. Description adds format example '0xabc...' for marketId and notes default network is mainnet, enhancing understanding beyond schema.

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

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

Clearly states verb 'Get', resource 'Moolah market', and identifier 'marketId'. Also distinguishes from sibling get_moolah_markets by specifying it retrieves full details for a single market.

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 recommends using get_moolah_markets to find marketIds before calling this tool, providing clear guidance for use. No explicit when-not, but the sibling reference is sufficient.

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

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

Annotations already declare safe read-only behavior (readOnlyHint, idempotentHint, destructiveHint=false). The description adds value by specifying that it returns both current values (totalBorrow, totalCollateral, apy) and a list of historical points, offering behavioral detail beyond 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 two sentences long, front-loading the main function and then detailing return structure and usage hint. Every sentence contributes meaning without redundancy.

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

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

Given the tool's complexity (current data plus time series) and no output schema, the description explains the return structure adequately. However, it omits details about the fields within the historical points list, which might be needed for full 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 covers both parameters (network, marketId) with descriptions, achieving 100% coverage. The description adds context by noting that marketId should come from get_moolah_markets, enhancing the schema's meaning.

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

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

The description explicitly states it returns a 'Time series of a V2 Moolah market's borrow/supply APY, utilization, and totals', clearly identifying the verb (get), resource (V2 Moolah market history), and distinguishing it from sibling tools like get_moolah_market (current snapshot) or get_moolah_markets (list of markets).

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

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

The description advises to 'Use marketId (bytes32 hex) from get_moolah_markets', guiding the user to first retrieve the marketId from a sibling tool. While it does not explicitly state when not to use this tool, it provides sufficient context for appropriate usage.

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

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

Annotations already indicate safe, read-only behavior. The description adds valuable context about the returned metrics (APY, LLTV, etc.) and the isolated nature of markets, going beyond what annotations provide. No contradictions.

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. First sentence states purpose and key data, second explains isolation. 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?

The description covers the data returned and the unique isolation feature. It omits explicit mention of defaults (e.g., network defaults to mainnet, page size defaults to 20) but the schema descriptions cover those. For a simple list tool with good annotations, this is sufficiently complete.

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

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

Schema description coverage is 100%; each parameter already has a description. The tool description does not add additional parameter-level details 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?

The description clearly states the verb 'list', the resource 'JustLend V2 (Moolah) markets', and the specific data fields (borrow/supply APY, LLTV, utilization, liquidity). It also notes the distinctive isolation property, helping differentiate from siblings like get_moolah_market.

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 listing markets with optional filters (network, pageSize, depositToken, collateralToken) but does not explicitly state when to use this tool versus alternatives or provide exclusionary 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?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds significant context: explains the meaning of 'accruingUsd' and 'settlingUsd', the settlement window conditions, the 'globalSettlementStatus' flag, and warns that per-token amounts are provisional. No contradictions with 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 dense yet concise, with no wasted words. It front-loads the core purpose and uses structured clauses to explain edge cases. Every sentence earns its place.

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

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

Given the lack of output schema, the description fully explains the return values (accruingUsd, settlingUsd, globalSettlementStatus) and their provisional nature. Combined with strong annotations, the tool is well-documented for 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% and both parameters are described in the schema. The description adds value by noting the defaults (address defaults to configured wallet, network defaults to mainnet) and the optional nature, which aids agent decision-making.

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

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

The description clearly states the tool retrieves accruing and settling V2 mining rewards across vaults, specifying the two types with precise definitions. It distinguishes itself from sibling tools like 'get_mining_rewards' by focusing on the V2 mining context and the settlement window logic.

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 (to get accruing/settling rewards) and provides detailed accounting logic to avoid double-counting. However, it does not explicitly mention alternatives or state when not to use it, which would improve 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?

Annotations already indicate readOnlyHint, idempotentHint, and non-destructive. Description adds key behavioral detail: vaults with zero mining APY are excluded, and it returns APY splits. No contradictions.

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

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

Three sentences, each earning its place: purpose, usage, exclusion. Front-loaded with main action. No redundant 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?

No output schema, and description only vaguely states 'APY split' without detailing return format. For a data-retrieval tool, more explicit return structure would improve completeness.

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

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

Schema covers 100% of one parameter with clear description. Description adds no additional meaning beyond 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?

Description clearly states it maps every Moolah vault with active mining to USDD/TRX APY split. It distinguishes from siblings by specifying usage for dashboard fire-icon prefetch and explicitly mentions exclusion of zero APY vaults.

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?

States it is used by dashboard for prefetching fire-icon eligibility in one round-trip, providing clear context. Does not explicitly mention when not to use or alternatives, but the context is sufficient.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context by defining riskLevel > 1.0 as liquidatable and suggesting minRiskLevel=0.9 for near-threshold positions, which aids agent understanding of output semantics.

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 consists of two concise sentences without extraneous information. The purpose is front-loaded, and each sentence contributes essential meaning, achieving high efficiency.

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

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

Given the tool has 7 optional parameters, no output schema, and annotations cover safety, the description adequately explains the core concept and usage. It lacks explicit mention of return format or pagination behavior, but this is not critical for a read-only 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?

Schema coverage is 100% with parameter descriptions. The description adds meaning beyond schema by explaining the riskLevel concept and how minRiskLevel relates to liquidation threshold, providing an example value. Other parameters like page and network are already documented in schema.

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

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

The description clearly states the tool lists Moolah positions eligible or approaching liquidation, using specific verb 'list' and resource 'positions'. It distinguishes from siblings like liquidation records or quotes by focusing on pending positions, and explains the riskLevel threshold.

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 to find liquidatable or near-liquidatable positions and provides an example (minRiskLevel=0.9). However, it does not explicitly state when not to use this tool or compare it with alternatives like get_moolah_liquidation_records or moolah_liquidate.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds behavioral details such as returning merkleIndex, index, amounts, proof, and USD total, and explains the includeClaimed parameter behavior. No contradictions.

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 three sentences, each earning its place: first sentence states purpose, second lists return fields, third explains usage and parameter. No superfluous text, and key information is front-loaded.

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

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

Despite no output schema, the description compensates by listing return fields (merkleIndex, index, amounts, proof, total). It adequately covers the tool's behavior and parameter usage, though it doesn't mention pagination or error handling. Still sufficient for a read-only 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?

Schema coverage is 100% with descriptions for all 3 parameters. The description adds extra meaning for includeClaimed (default false matches rewards card behaviour) and implies that address and network are optional. Baseline 3, plus 1 for additional context.

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 (Get), resource (claimable V2 mining airdrop rounds), and scope (already settled and merkle-published). It distinguishes itself from siblings like claim_moolah_mining_period and get_moolah_mining_accruing by specifying the state of the rounds.

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 tells the agent to feed periodKey into claim_moolah_mining_period for the next step, and explains when to use includeClaimed=true. While it doesn't explicitly list alternatives, the context from sibling tools and the focus on settled rounds provides clear usage context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, clearly indicating safe, non-destructive behavior. The description adds that the tool works on both mainnet and nile, and implies paginated behavior. This adds some context beyond annotations but does not discuss rate limits, result ordering, or empty result behavior, so a score of 3 is appropriate.

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 consists of two concise sentences. The first sentence clearly states the core purpose and event types. The second sentence provides a critical sibling distinction. No unnecessary words, front-loaded with essential information.

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

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

Given the lack of an output schema, the description does not describe the return format or fields of the transaction records. The parameter list is fully covered by the schema, but the agent receives no information about what data is returned per record. This gap reduces completeness. A score of 3 is appropriate for a simple list tool with good annotations.

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

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

Schema coverage is 100% with detailed parameter descriptions in the JSON schema. The description mentions 'paginated' which aligns with pageNo and pageSize, but adds no new semantic detail beyond what the schema already provides. Baseline 3 is correct as the 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's purpose: retrieving a user's paginated V2 Moolah transaction history for specific event types. It explicitly distinguishes from the sibling tool get_moolah_history by contrasting its full record list vs. position curves with a preview, which helps the agent select the correct 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?

The description provides direct usage guidance by comparing to get_moolah_history, stating when to use this tool (full paginated records) and when to use the alternative (position curves + preview). It also mentions compatibility with mainnet and nile. However, it does not address other potentially related tools like get_lending_records or get_liquidation_records, slightly limiting completeness.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, confirming safe read. The description adds the behavioral insight that a risk ratio close to 1.0 indicates near liquidation, which goes beyond annotations. However, it does not disclose other traits like default parameter behavior or response structure.

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

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

The description is a single sentence followed by a short actionable note. It is front-loaded with the purpose, no redundant words, and 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?

For a read-only tool with 3 parameters fully documented in the schema and clear annotations, the description completes the context by listing output fields and risk interpretation. It could mention default values for address and network, but those are present in the schema, so overall it is nearly complete.

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

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

Schema description coverage is 100%, so the schema fully documents the three parameters (address, network, marketId). The description does not add parameter-specific details beyond what the schema provides, resulting in a baseline score of 3.

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

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

The description specifies the verb 'Get', the resource 'user's position in a specific Moolah market', and lists the fields (collateral, borrow amount, lltv, risk ratio). It distinguishes from sibling tools like 'get_moolah_market' by focusing on a single user's position and risk status.

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: to check a position's risk ratio and consider repaying or adding collateral if near liquidation. It implicitly tells when not to use (e.g., for market-wide data), but lacks explicit exclusion or alternative tool references.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds minor behavioral context (address defaults to configured wallet), but does not disclose error handling or additional constraints. With strong annotations, this is adequate.

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

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

The description is two sentences, front-loaded with the main purpose, and includes all essential details without waste. Every part 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 lists the key return fields (APY, TVL, allocation, share balance). It is mostly complete for a single-vault detail tool, though it could mention additional fields like vault address or underlying asset. Annotations provide safety context.

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

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

Schema coverage is 100% with detailed descriptions for all three parameters. The description reinforces vaultSymbol values and the address's purpose, but adds minimal new information beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool gets detailed info for a single Moolah vault, specifies the fields (APY, TVL, allocation, share balance), and lists allowed vaultSymbol values. It distinguishes this from sibling tools like get_moolah_vaults (plural) and get_moolah_vault_history.

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 vault details, but does not explicitly state when to use this tool versus alternatives (e.g., get_moolah_vaults for all vaults). It mentions the optional address for share balance, but no exclusion or context for when not to use.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description's burden is reduced. The description adds the return fields (currentSupplyUsd, supplyBaseApy, supplyMiningApy, historyRecords) but does not disclose behavioral traits like pagination, time range, or rate limits. It adds minimal value beyond 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 two sentences long with no wasted words. It efficiently states the purpose, lists return fields, and provides input sourcing guidance. It is front-loaded and every sentence serves a distinct 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?

The tool has no output schema and returns a structured historyRecords array, yet the description does not explain the array's contents (e.g., fields, time format). The optional network parameter is mentioned in the schema but not in the description. While safety is annotated, return structure details are incomplete 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?

The input schema covers both parameters with descriptions (100% coverage). The description adds further meaning by specifying that vaultAddress should come from get_moolah_vaults or chains.ts, which is valuable context beyond the schema. This extra guidance justifies a score above baseline.

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

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

The description explicitly states the tool returns a 'time series of a V2 Moolah vault's APY, TVL, and supply mining data,' listing specific fields. It clearly distinguishes from sibling tools like get_moolah_history (likely for markets) and get_moolah_vault (single snapshot) by specifying 'time series' and the exact return data.

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

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

The description provides clear guidance on where to obtain the vaultAddress (from get_moolah_vaults or chains.ts), which is a key input. However, it does not explicitly state when not to use this tool versus alternatives, such as get_moolah_vault_mining_apy for only APY data. The guidance is helpful but lacks 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?

Annotations already indicate readOnly, idempotent, and non-destructive. The description adds value by explaining the return format (fraction encoding) and the meaning of the `enabled` flag for the UI hint. This enriches the understanding without contradicting 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 two sentences, front-loaded with the purpose, and every part adds value. No unnecessary words.

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

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

For a simple read tool with one required param and no output schema, the description covers return values and the enabled flag. It lacks mention of network default behavior or update frequency, but these are minor gaps given the tool's simplicity.

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 baseline is 3. The description does not add additional parameter context beyond the schema, such as explaining the `network` default or providing examples.

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 gets V2 mining APY for a single Moolah vault, and specifies the return values (USDD/TRX split and total). It distinguishes from sibling tools like `get_moolah_vault` by targeting a specific metric.

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 mining APY of a single vault, but does not explicitly mention when to use this vs. alternatives like `get_moolah_vault` or `get_mining_rewards`. No 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?

Annotations already declare readOnlyHint, idempotentHint, etc., so the description adds context about vault type (ERC4626) and yield mechanism but does not contradict annotations. Additional behavioral details (e.g., response shape, rate limits) are absent but not critical given 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?

Two sentences, front-loaded with core functionality and data fields. No redundant text or padding.

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 list operation with optional parameters and no output schema, the description is largely complete. It explains the vault type and yield purpose. Minor omissions: no mention of pagination or response structure, but acceptable for this tool.

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

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

Schema descriptions cover 100% of parameters (network, depositToken). The tool description adds no extra detail beyond what the schema provides, such as default values or filter behavior. Baseline 3 is appropriate.

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

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

The description clearly states the tool lists all JustLend V2 (Moolah) vaults with specific data fields (APY, TVL, underlying token). It also distinguishes from sibling tools like 'get_moolah_vault' by indicating 'list all' and providing context about ERC4626 vaults.

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 (e.g., 'get_moolah_vault', 'get_moolah_vault_history'). The description implies it's for a broad overview, but no exclusions or when-not-to-use advice.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns proposals sorted by newest first, but does not mention any additional behavioral traits beyond what annotations provide. No contradiction.

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 three concise sentences, front-loaded with the main purpose, and contains no redundant or irrelevant 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?

While the description outlines the kind of data returned (status, vote counts, details), it lacks specifics such as field names, structure, or pagination behavior. Given no output schema exists, more detail would improve completeness. Annotations cover safety aspects.

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 coverage is 100% with descriptions for both parameters (limit and network). The tool description does not add any additional meaning beyond the schema's parameter descriptions, 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 states the verb 'Get' and the resource 'list of JustLend DAO governance proposals', and specifies what is returned (status, vote counts, details) and ordering (newest first). It distinguishes from sibling tools with different purposes.

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

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

The description does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. However, the purpose is straightforward and there are no close sibling tools competing for the same task, so the usage is implicitly 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?

Annotations already provide readOnlyHint=true and destructiveHint=false, indicating safe read operation. The description adds value by listing returned fields (estimatedRefundTrx, remaining rent, etc.), providing behavioral context beyond annotations. However, it does not disclose prerequisites or side effects, but these are not needed for a read-only 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 a single, well-structured sentence that front-loads the purpose and lists key output fields. Every word contributes value; no wasted text.

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 (3 parameters, no output schema, read-only), the description sufficiently explains what the tool returns. It covers all necessary information for an agent to understand and invoke the tool correctly.

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

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

Schema coverage is 100%, so the description does not need to detail parameters. It adds no new meaning beyond the schema, which already describes the three parameters. The baseline of 3 is appropriate given 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 'Get estimated refund info for returning/canceling an energy rental,' identifying the resource (energy rental) and the specific information provided. It distinguishes from siblings like 'return_energy_rental' (which performs the return) and other 'get_*' tools.

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

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

The description implies usage when considering returning or canceling a rental but does not explicitly specify when not to use or mention alternatives among siblings. It lacks explicit context on exclusion or comparison with similar tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the agent knows this is a safe read operation. Description adds no behavioral context beyond listing output fields; it doesn't disclose rate limits, auth needs, or other traits. No contradiction with 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?

Single sentence with clear verb and list of included fields. No fluff or redundant 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?

Despite no output schema, the description fully enumerates the key fields returned (staked amount, income, claimable rewards, withdrawn amount, rental energy amount). For a read-only tool with good annotations, this is sufficient for an AI agent to understand what it will receive.

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%: both parameters (address, network) have descriptions covering pattern, default, and optionality. The description adds no extra parameter meaning beyond listing output fields, so it meets baseline but does not exceed.

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 retrieves sTRX staking account info and enumerates specific fields (staked amount, income, claimable rewards, withdrawn amount, rental energy amount). This distinguishes it from siblings like get_strx_balance (balance only) and get_strx_dashboard (likely dashboard summary).

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The description implies use for detailed staking account info, but with many related sibling tools, some differentiation would help agents choose correctly.

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

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

Annotations already indicate readOnlyHint=true and no destructive effects. The description adds no new behavioral context beyond what annotations provide, e.g., no mention of default address behavior or network fallback.

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

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

The description is a single concise sentence with no extraneous 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?

For a simple read-only tool with good annotations, the description is adequate but could mention return value format. Overall, it sufficiently covers the essential context.

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

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

Schema coverage is 100%, and the description does not add meaningful information beyond the schema. The phrase 'for an address' aligns with the address parameter but offers no additional detail.

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

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

The description clearly states the action ('Get'), the resource ('sTRX token balance'), and the scope ('for an address'), distinguishing it from sibling tools like get_trx_balance and get_token_balance.

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

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

No guidance on when to use this tool versus alternatives (e.g., get_trx_balance, get_wallet_balances). The usage context is implied but not explicit, lacking exclusions or recommendations.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds transparency about pagination and network restriction, going beyond the structured 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 front-loads the core action and lists record types. It is efficient, though adding line breaks could improve readability.

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

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

Given the lack of output schema, the description provides partial context by mentioning opType and opName, but it does not fully describe the paginated response structure or complete list of return fields, leaving room for ambiguity.

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

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

Schema coverage is 100% with detailed parameter descriptions. The description mentions pagination but does not add new parameter semantics beyond what the schema provides, 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?

Clearly states the tool retrieves a user's sTRX staking history, enumerating specific record types (stake, unstake, withdraw, transfers) and distinguishing itself from sibling tools like get_strx_balance or get_strx_account by focusing on historical records.

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 notes the tool is Mainnet-only, providing a clear usage constraint. However, it does not explicitly contrast with alternative tools for similar tasks, though the sibling context makes the distinction reasonably 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?

Annotations declare readOnly, openWorld, idempotent. The description adds valuable behavioral details: automatic resolution of symbols to contract addresses via JustLend markets, and that the balance is pre-formatted (decimals applied) so agents must not re-divide. This exceeds annotation-only 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?

Four short sentences that front-load the purpose and quickly deliver key usage warnings. Every sentence adds value; no 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?

Despite no output schema, the description explains return format (formatted balance) and critical usage nuances. It covers the main edge case (deprecated addresses) and defaults. Slightly incomplete on error handling for invalid symbols, but adequate for the tool's simplicity.

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 descriptions. The description adds extra semantics: the preference for symbol over address, the auto-resolution mechanism, and the formatting behavior. This provides context beyond the raw schema.

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