gmx-mcp

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

With no annotations provided, the description carries full behavioral disclosure burden and succeeds in key areas: explicitly marks it as a write function, warns about onlyOwner-style restrictions, and clarifies 'No return value'. This safety-critical context for smart contract interactions adds significant value beyond structured fields.

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 efficiently structured: function signature, write classification with access warning, prerequisite instruction, and return value declaration. Each sentence earns its place without redundancy, though the opening signature restatement is somewhat unnecessary given the tool name.

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 complex blockchain mutation tool with no annotations and no output schema, the description covers critical safety aspects (access control, write nature) but omits domain semantics—what a router is, what protocol state changes occur, or side effects. Adequate but incomplete for the complexity level.

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

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

Schema coverage is 100% with _router already documented as an Ethereum address. The description mentions '_router: string' in the function signature but adds no additional semantic meaning, validation rules, or format guidance beyond what the schema already provides. Baseline score appropriate for complete schema coverage.

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

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

The description identifies this as a 'Write function' but opens with tautological 'Calls addRouter(_router: string)' that merely restates the tool name. While it signals state mutation, it fails to explain what a 'router' represents in this DeFi protocol context or distinguish its purpose from sibling removeRouter.

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

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

Provides prerequisite guidance regarding access control ('may have access control restrictions', 'Check contract source for modifier requirements'), which is useful for blockchain interactions. However, it lacks explicit comparison to alternatives like removeRouter or approvedRouters to help determine when to use this specific tool.

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

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

With no annotations provided, the description carries full burden and effectively discloses key behavioral traits: explicitly states 'Read-only — does not modify contract state' and 'Unrestricted — any address can call this read function.' It also documents the return type ('Returns uint256') which is crucial since no output schema exists. However, it omits the calculation formula or precision behavior.

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

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

Four efficient sentences with no fluff. Front-loaded with the function signature, followed by safety properties (read-only, unrestricted), and return type. Each sentence earns its place, though the read-only and unrestricted declarations could potentially be combined for even tighter prose.

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?

Adequate for a simple 3-parameter view function. Compensates for missing output schema by specifying return type (uint256). However, given the complexity of the surrounding contract ecosystem (evident from 100+ sibling functions), the description should explain the business logic—specifically how this decimal adjustment fits into token swaps, margin trading, or liquidity provision workflows.

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% description coverage, establishing baseline expectations. The description repeats the parameter signature with types ('_amount: string, _tokenDiv: string, _tokenMul: string') but adds no semantic context about what tokenDiv and tokenMul represent conceptually (divisor/multiplier tokens) or the relationship between them. Merely confirms the schema without enriching 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 states it calls the adjustForDecimals function and identifies it as read-only, but fails to explain what mathematical operation 'adjusting for decimals' actually performs (e.g., normalizing amounts between different token decimal precisions). It does not distinguish this utility from similar conversion functions among the 100+ sibling tools like tokenToUsdMin or getRedemptionAmount.

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 provided on when to use this tool versus alternatives. Given the extensive sibling list includes multiple price conversion and calculation functions (getFeeBasisPoints, getDelta, usdToToken, etc.), the description should specify scenarios where decimal adjustment is specifically required before trading or liquidity operations.

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

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

With no annotations provided, the description carries the full burden and successfully discloses critical behavioral traits: read-only nature, lack of state modification, unrestricted access (no auth requirements), and the return type (address). It omits potential revert conditions (e.g., index out of bounds) but covers the essential safety profile.

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 efficiently structured in four sentences covering function signature, mutability, permissions, and return value. The '[DISCOVERY]' tag and 'param0' notation are slightly mechanical but do not waste space. Every sentence conveys distinct information.

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

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

For a single-parameter getter without an output schema, the description adequately covers the return type ('Returns address') and access pattern. Given the presence of sibling tools like 'allWhitelistedTokensLength', it could explicitly mention this is an indexed array access, but the core information is present for invocation.

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

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

The input schema has 100% description coverage explaining the uint256 format. The description mirrors this ('param0: string') but fails to add semantic meaning—specifically that param0 represents an array index into the whitelist. With complete schema coverage, this meets the baseline but adds no additional parameter 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 identifies this as a read-only call returning an address, and the '[DISCOVERY]' prefix suggests auto-generated contract inspection. However, it leans on the function name rather than explaining the business logic (retrieving a whitelisted token address by index), and does not differentiate from sibling 'whitelistedTokens' which may access the same data differently.

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 notes the function is 'Unrestricted' regarding access control, which is useful. However, it fails to provide guidance on when to use this versus 'whitelistedTokens' or how to iterate using 'allWhitelistedTokensLength', leaving the agent to infer the array-index access pattern.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively communicates that the operation is read-only ('does not modify contract state') and permissionless ('any address can call'), while specifying the return type (uint256).

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 three tight, information-dense sentences with no filler. Each sentence earns its place by declaring the function call, read-only nature, unrestricted access, and return type.

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 provided, the description mentions the return type (uint256) but omits the semantic meaning of the value (i.e., the count/number of whitelisted tokens). Given the lack of annotations and output schema, this semantic gap is notable.

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

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

The tool has zero parameters, establishing a baseline score of 4. The input schema requires no additional semantic explanation from the 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 identifies this as a read operation that returns a uint256 length value, providing specific verb (calls/gets) and resource (whitelisted tokens). However, it fails to distinguish from the sibling tool 'whitelistedTokenCount' which appears to serve an identical purpose.

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

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

No guidance is provided on when to use this tool versus alternatives like 'whitelistedTokenCount' or 'allWhitelistedTokens'. The 'unrestricted' statement indicates permissionless access but does not constitute usage guidance for tool selection.

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

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

Without annotations, the description carries the full burden and successfully discloses that the operation is read-only and unrestricted. However, it fails to explain what the boolean return value signifies (true=approved, false=not?), what error conditions might occur, or the semantic roles of the two address inputs.

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 at one sentence, but the opening clause 'Calls approvedRouters(...)' wastes space by restating the tool name and parameter signatures. The remaining content ('Read-only...', 'Unrestricted...', 'Returns bool') is efficiently structured and front-loaded with important safety information.

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

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

For a simple boolean getter with no output schema, the description provides the essential return type and safety characteristics. However, given the presence of related mutation siblings (addRouter/removeRouter), it should clarify the approval checking logic and address parameter roles to be fully complete.

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

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

With 100% schema description coverage, the baseline is 3. The description redundantly lists parameter types ('param0: string, param1: string') which offers no value beyond the schema, and fails to explain what the two Ethereum addresses represent semantically (e.g., router address and user address).

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

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

The description identifies this as a read-only function returning a boolean, but opens with tautological noise ('Calls approvedRouters'). It fails to explain what 'approved' means in this contract context or what relationship the two addresses have (router vs user?), leaving the core business purpose vague despite the technical return type disclosure.

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 notes the function is 'Unrestricted' regarding caller permissions, it provides no guidance on when to use this versus sibling mutation tools like 'addRouter' or 'removeRouter'. No prerequisites or comparison to alternatives are offered to help an agent decide if this is the right tool for their task.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only — does not modify contract state' and 'Unrestricted — any address can call this read function,' which clearly communicates safety and access traits. It also discloses the return type (uint256) since no output schema exists.

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 four efficient sentences with zero waste: (1) function call identification, (2) mutability characteristics, (3) access control, and (4) return type. Information is front-loaded and every sentence earns its place.

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

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

For a simple parameter-less getter, the description covers operational essentials (read-only, unrestricted, return type). However, it lacks semantic context about what the divisor value represents (e.g., 'typically 10000 for basis point math'), which would help the agent understand when to invoke this versus hardcoding constants.

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 contains zero parameters. According to the scoring rubric, zero parameters warrants a baseline score of 4. The description appropriately does not invent parameter semantics where none exist.

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

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

The description states it 'Calls BASIS_POINTS_DIVISOR()' and returns uint256, which identifies the action and resource. However, it fails to explain what the basis points divisor represents (e.g., the constant 10000 used for percentage calculations) or how it differs semantically from similar constant getters like FUNDING_RATE_PRECISION or PRICE_PRECISION among the siblings.

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

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

While the description notes the function is 'Unrestricted' regarding access control, it provides no guidance on when to use this tool versus alternatives, or what calculations require this specific divisor value. No prerequisites or contextual usage hints are provided.

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

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

With no annotations provided, the description carries the full burden and successfully discloses that the function is read-only, unrestricted, and returns uint256. However, it lacks context about gas costs, reversion conditions, or the semantic meaning of the returned value.

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

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

Four short sentences efficiently convey the call signature, mutability, access restrictions, and return type without redundancy. Well-structured for quick parsing, though the opening 'Calls bufferAmounts' is unnecessary given the tool name.

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 single-parameter read function without output schema, the description adequately covers the return type (uint256) and access pattern. However, it omits domain-specific context about what buffer amounts represent in this DeFi vault system and their relationship to pool liquidity.

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 (param0 documented as Ethereum address), establishing baseline adequacy. The description mentions 'param0: string' but adds no semantic meaning beyond the schema, such as which token address to query or expected address format 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 states it returns uint256 and is read-only, providing basic technical purpose, but 'Calls bufferAmounts' is tautological. It fails to explain what 'buffer amounts' represent semantically (e.g., liquidity buffers) or distinguish from similar getters like poolAmounts or reservedAmounts.

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 notes the function is 'Unrestricted' regarding access, but provides no guidance on when to query buffer amounts versus sibling state-reading functions such as poolAmounts, reservedAmounts, or guaranteedUsd.

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

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

With no annotations provided, the description carries the full burden and effectively discloses: (1) it's a write/mutating function, (2) access control risks exist, and (3) it returns uint256. This covers critical behavioral traits for a blockchain interaction, though it omits side effects like balance changes.

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 concise sentences with logical flow: function signature, mutability warning, safety instruction, return type. The first sentence is somewhat wasted on tautology, but overall no fluff and appropriately front-loaded with critical safety info.

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

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

For a 2-parameter financial smart contract function with no output schema, the description covers essential safety aspects (access control) and return type. However, it lacks business logic context (what USDG is, slippage tolerance, or error conditions) needed for safe invocation.

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

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

Schema description coverage is 100% (both parameters documented as Ethereum addresses), establishing baseline 3. The description repeats parameter names/types but adds no semantic context (e.g., that _token is the asset being sold, or that _receiver receives the minted USDG).

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

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

The description states it 'Calls buyUSDG' which is tautological, but identifies it as a 'Write function.' However, it fails to explain what 'buying USDG' actually accomplishes (e.g., minting stablecoins, swapping assets) or how it differs from siblings like 'sellUSDG' or 'swap.'

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

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

The description warns about access control restrictions ('onlyOwner') and advises checking contract source, which is safety guidance. However, it provides no functional guidance on when to use this tool versus alternatives like 'sellUSDG' or prerequisites such as token approvals.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly identifies this as an event subscription rather than a state-changing transaction, but does not clarify whether this creates a persistent subscription or one-time query, what data structure is returned, or filtering limitations.

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 two-sentence description contains no redundant words and is appropriately front-loaded with the critical distinction that this is an event. However, extreme brevity limits its utility, as no expansion on the event's business logic is provided.

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

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

Despite having 5 well-documented input parameters, the description lacks essential context for an event tool: it does not explain what triggers the event (a USDG purchase), what the output looks like (no output schema exists), or how to interpret the returned event data. Significant gaps remain for agent comprehension.

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 has 100% description coverage for all 5 parameters (account, token, amounts, feeBasisPoints). The description adds no parameter-specific context, but the schema comprehensively documents types and formats, warranting the baseline score of 3.

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

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

The description identifies this as a contract event for log filter subscriptions, distinguishing it from the 'buyUSDG' function sibling (camelCase vs PascalCase convention). However, it fails to explain what the event represents (e.g., 'Emitted when USDG is purchased/minted'), leaving the domain semantics unclear.

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

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

The phrase 'Subscribe via log filters' implies the mechanism for use but provides no explicit guidance on when to use this event subscription versus calling the 'buyUSDG' function directly. No prerequisites, alternatives, or exclusions are mentioned.

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

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

With no annotations provided, the description carries the full burden and successfully discloses: (1) state-mutating nature ('Write function'), (2) authorization requirements ('access control restrictions'), and (3) return value behavior ('No return value'). However, it omits the actual side effects of clearing (what happens to the token's state) and whether the operation is reversible.

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 with minimal redundancy. The front-loaded function signature is unnecessary, but the subsequent sentences efficiently cover write classification, access control warnings, and return value. No extraneous information is included.

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?

Adequate for a single-parameter administrative function, covering invocation safety and return behavior. However, given this appears to be a DeFi vault contract tool (evidenced by siblings like `setTokenConfig`, `addRouter`), the description should specify whether clearing removes the token from the whitelist or merely resets its configuration values.

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 for the single `_token` parameter. The description mentions '_token: string' which adds no semantic value beyond the schema, but meets the baseline expectation when schema documentation is complete. No additional context about address format or valid token addresses is provided.

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

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

The description identifies this as a 'Write function' targeting token configuration, but opens with a tautological function signature ('Calls clearTokenConfig(_token: string)') that merely restates the tool name. While it distinguishes from read-only siblings via the 'Write function' label, it fails to clarify what 'clearing' specifically entails (removing from whitelist vs. resetting parameters).

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

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

Provides explicit warning about access control restrictions ('e.g. onlyOwner') and advises checking contract source for modifiers, which functions as prerequisite guidance. However, it lacks explicit comparison to sibling tool `setTokenConfig` or guidance on when clearing is preferred over updating configuration.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states that this relates to log subscription without explaining return format, pagination for historical queries, subscription lifecycle, or whether this is idempotent. The phrase 'Subscribe via log filters' hints at read-only behavior but lacks specifics.

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

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

Extremely brief at two short sentences with no redundant text. However, for a tool with 7 parameters and complex blockchain context, this brevity results in under-specification rather than efficient communication. Every sentence earns its place, but there are too few sentences.

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

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

Inadequate for a 7-parameter blockchain event tool with no output schema. The description fails to explain the relationship to the position lifecycle (when this event fires), what data it returns, or how to interpret the parameters (e.g., that 'realisedPnl' represents profit/loss at position closure). Missing crucial context for effective use.

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

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

The input schema has 100% description coverage with detailed type information (bytes32, uint256, int256) and format instructions ('pass as decimal string'). The description adds no semantic context about what 'key' represents or how 'realisedPnl' is calculated, but with complete schema coverage, the baseline score 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?

Identifies this as an event subscription tool ('Event emitted by the contract. Subscribe via log filters') rather than an action, distinguishing it from siblings like 'decreasePosition'. However, it fails to clarify whether the tool queries historical events, creates a subscription, or decodes logs, leaving the actual function ambiguous.

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

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

Provides no explicit guidance on when to use this event tool versus calling action methods like 'decreasePosition' or 'liquidatePosition'. While the event/action distinction is implied by the description, there is no 'when-to-use' or 'when-not-to-use' guidance for an agent trying to close a position.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure but only mentions the subscription mechanism. It fails to disclose authentication requirements, expected event frequency, triggers for margin fee collection, or whether this is a read-only subscription versus a triggering action. The description lacks critical context about the event's significance in the margin trading lifecycle.

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 only two brief sentences with zero redundant wording, making it highly concise. However, this extreme brevity contributes to under-specification for a complex DeFi contract tool. While every sentence earns its place, the structure lacks necessary elaboration for proper agent comprehension.

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

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

Given the complexity of margin fee collection in what appears to be a perpetual vault contract (evidenced by sibling tools like 'liquidatePosition' and 'increasePosition'), the description is insufficient. It lacks explanation of event trigger conditions, the relationship between the token address and fee amounts, and expected return values. For a 3-parameter tool with no annotations or output schema, significantly more contextual detail is required.

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 technical type descriptions (e.g., 'uint256, pass as decimal string'), establishing a baseline understanding of data formats. The description adds no semantic context about what 'feeUsd' versus 'feeTokens' represent in margin calculations or provide examples of valid inputs. No additional constraints or relationships between parameters are documented 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 identifies the tool as subscribing to contract events via log filters, providing a basic mechanism. However, it fails to explain what 'CollectMarginFees' represents (e.g., fees collected during position closure) or how it differs from the sibling 'CollectSwapFees' tool. The phrase 'Event emitted by the contract' is generic and lacks specific business 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 no guidance on when to use this tool versus alternatives like 'CollectSwapFees' or other fee-related functions. There are no stated prerequisites for subscription or filtering criteria. While it mentions 'log filters,' it does not specify appropriate usage scenarios or conditions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It establishes the subscription pattern (log filters) but omits critical details: when the event fires (what contract actions trigger it), whether it's a one-time query or continuous stream, and what the return data structure looks like. It meets minimum viability but lacks richness.

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 zero redundancy. Front-loaded with the critical fact that this is an event (not a function call). However, given the tool's complexity (3 required params, no annotations), the extreme brevity arguably underserves the agent's information needs, preventing a 5.

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?

Insufficient for a 3-parameter event subscription tool with no annotations and no output schema. Missing: event trigger conditions, relationship to swap operations, expected frequency, and differentiation from the 90+ sibling tools (particularly 'CollectMarginFees'). The description assumes familiarity with the contract's event architecture.

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

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

Schema coverage is 100% with clear types (address, uint256), so the baseline is 3. The description adds no parameter context (e.g., that 'feeUsd' represents the USD value of collected fees, or that 'token' is the fee-bearing asset), but given comprehensive schema documentation, no additional text is strictly necessary.

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 identifies this as a contract event and mentions log filter subscription, but fails to explain what 'CollectSwapFees' specifically represents (e.g., event emitted when swap fees are accumulated) or how it differs from sibling 'CollectMarginFees'. It states what it is (an event) but not what it does functionally.

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 subscribe to this event versus querying historical data or using other fee-related tools like 'CollectMarginFees'. The only usage hint is 'Subscribe via log filters' with no context on trigger conditions 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?

Since no annotations are provided, the description carries the full burden of disclosing safety and auth characteristics, which it does ('Read-only,' 'Unrestricted'). However, it fails to explain what the returned uint256 represents (e.g., funding rate precision, what the address parameter signifies, or whether this value is used for position funding fee calculations).

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 at three sentences with no significant fluff. However, the first sentence 'Calls cumulativeFundingRates(param0: string)' is redundant given the tool name and schema, slightly reducing efficiency.

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

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

For a financial tool in a complex perpetual/DEX protocol (evidenced by 80+ siblings including positions, swaps, and funding mechanics), simply stating 'Returns uint256' is insufficient. Given the lack of output schema, the description should explain the return value's semantics (funding rate units, cumulative calculation method) and the address parameter's domain (likely token address).

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

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

With 100% schema description coverage, the baseline is 3. The description mentions 'param0: string' which merely duplicates schema information. It does not add semantic meaning beyond the schema's 'address' type hint, failing to clarify whether this address represents a token, trader, or market pool.

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 identifies this as a read-only operation returning uint256, which partially clarifies purpose. However, the opening 'Calls cumulativeFundingRates(param0: string)' is tautological, and it fails to explain what 'cumulative funding rates' represent in this DeFi context or how this differs from siblings like getNextFundingRate, fundingRateFactor, or updateCumulativeFundingRate.

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 states 'Unrestricted — any address can call this read function,' which provides basic access control context. However, there is no guidance on when to use this specific funding rate function versus the numerous sibling funding-related tools (e.g., whether this retrieves historical cumulative rates vs current rates).

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

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

With no annotations provided, the description carries the full burden. It successfully clarifies that this is an event subscription (read operation) rather than a write operation despite the imperative name 'Decrease...'. However, it lacks details on what triggers this event, the return format, or whether the parameters are indexed filters.

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

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

Extremely concise at two sentences with no filler. Information is front-loaded: first sentence identifies the nature (event emission), second provides the action (subscription method). While appropriately brief for the complexity, it borders on underspecified for agents lacking domain knowledge.

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 only 2 primitive parameters with 100% schema coverage and no output schema, the description meets minimum requirements. However, it omits domain context (DeFi vault mechanics, guaranteed USD concept) that would help agents understand when this event is relevant to their 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 description coverage is 100%, providing 'token' and 'amount' types. The description adds no additional semantic context (e.g., that token refers to a whitelisted collateral asset, or that amount is the delta of guaranteed USD). Baseline score applies since schema is self-documenting but description doesn't enrich it.

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

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

The description identifies the tool as an event subscription ('Subscribe via log filters') and names the event source ('Event emitted by the contract'). However, it fails to explain what 'DecreaseGuaranteedUsd' represents in business terms (e.g., reducing USD guarantees in a vault), leaving agents to infer from the cryptic name alone.

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

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

The description provides the mechanism ('Subscribe via log filters') but offers no contextual guidance on when to use this specific event subscription versus sibling events like 'IncreaseGuaranteedUsd' or other log filters. No filtering strategy or use-case hints are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'log filters' suggesting a read-only monitoring behavior, but fails to specify what data is returned (event logs, subscription IDs), whether this captures historical or future events, or any rate limiting concerns.

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 brief sentences that are front-loaded. While the content is somewhat ambiguous regarding the exact mechanism, there is minimal waste—every word attempts to convey the nature of the tool (event-based, filter subscription).

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 and annotations, the description should explain what the tool returns (e.g., event objects, confirmation of subscription) and clarify the operational model. It leaves critical gaps regarding the invocation result and event lifecycle.

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 (token as Ethereum address, amount as uint256), establishing clear parameter semantics on its own. The description adds no additional context about these parameters, meeting the baseline expectation when schema coverage is high.

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 identifies the tool relates to an 'Event emitted by the contract' and mentions subscription via log filters, which hints at its purpose. However, it fails to clearly articulate what the tool actually does upon invocation (e.g., query historical events, establish a subscription, or decode logs), and does not explicitly distinguish this event-watching capability from similar action-oriented siblings like 'decreasePosition'.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites for subscription. While it implies this is for monitoring the DecreasePoolAmount event, it does not clarify use cases or when to prefer querying over subscribing.

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

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

Explicitly identifies this as a 'Write function' and warns about potential onlyOwner modifiers, which is critical given no annotations exist. However, it lacks disclosure of side effects (token transfers to receiver), what the returned uint256 represents, or error conditions.

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

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

Efficiently structured with function signature first, followed by mutation warning, access control note, and return type. No filler text, though the parameter type listing is redundant with the schema.

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

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

For a complex 7-parameter DeFi mutation with no annotations, the description is insufficient. It omits critical context: the relationship between parameters (collateral vs index tokens), what decreasing a position actually does, and the meaning of the return value. The 'Returns uint256' mention is helpful but underspecified.

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

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

With 100% schema description coverage, the baseline is 3. The description lists all parameters with types in the first sentence, but this merely duplicates the schema without adding semantic context (e.g., explaining that _sizeDelta represents the position size reduction or that _receiver gets the withdrawn collateral).

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

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

The description states it 'Calls decreasePosition' with the full function signature, which provides specificity but is somewhat tautological. It fails to explain the domain meaning of 'decreasing a position' (e.g., reducing leverage, partial close) and does not differentiate from siblings like ClosePosition or LiquidatePosition.

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?

Contains a warning about access control restrictions and advises checking contract source, but provides no guidance on when to use this tool versus alternatives like ClosePosition, LiquidatePosition, or the capitalized DecreasePosition 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?

No annotations provided, so description carries full burden. It correctly identifies this as an event (not a function call) and mentions log filters, but lacks context on emission triggers, data retention, or whether this streams indefinitely.

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

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

Extremely concise at two sentences. While no words are wasted, the brevity is arguably insufficient for a 9-parameter DeFi event tool where domain context is critical.

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 9 parameters in a complex DeFi protocol (evident from siblings like 'liquidatePosition', 'vault', 'usdg'), the description inadequately explains the event's business meaning, trigger conditions, or relationship to position lifecycle events like 'ClosePosition' or 'IncreasePosition'.

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 technical type descriptions. The description adds no business semantics (e.g., explaining that 'sizeDelta' represents the change in position size), but baseline 3 is appropriate given comprehensive schema documentation.

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 identifies this as an event subscription tool ('Subscribe via log filters'), but fails to explain what 'DecreasePosition' signifies (reducing a leveraged trading position) or distinguish it from the similarly named sibling 'decreasePosition' function.

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 event subscription versus querying state directly, or prerequisites for subscription. Does not mention that this event fires when traders reduce position size.

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

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

Without annotations, the description carries the full burden. It correctly identifies this as a passive subscription ('Event emitted') rather than an action, which is crucial safety information. However, it lacks details on subscription lifecycle (real-time vs historical), return payload structure, or rate limiting that annotations would typically cover.

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

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

Extremely concise at two sentences with no filler. Information is front-loaded with the event type identification. However, given the high domain complexity and lack of annotations, this brevity results in under-specification rather than efficient communication.

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 DeFi vault tool with 85+ siblings and no annotations, the description is insufficient. It fails to explain what triggers this event (e.g., position closure, liquidation), how it relates to vault token management, or the structure of the emitted event data.

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

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

With 100% schema description coverage (token as Ethereum address, amount as uint256), the schema fully documents the parameters. The description adds no parameter context, warranting the baseline score of 3 for high-coverage schemas.

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 identifies this as an event subscription tool ('Subscribe via log filters') rather than a state-changing operation, which prevents confusion given the action-oriented name 'DecreaseReservedAmount'. However, it fails to explain what 'ReservedAmount' refers to in this DeFi context (e.g., reserved liquidity in a vault) or how it relates to sibling tools like IncreaseReservedAmount.

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 provided on when to subscribe to this event versus querying current reserved amounts via 'reservedAmounts', or when to use this versus listening to similar pool events. No mention of prerequisites like contract addresses or network selection.

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

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

With no annotations provided, the description carries the full burden. It implies read-only behavior via 'Subscribe via log filters' but does not explicitly confirm safety, rate limits, or whether the subscription persists across sessions. It also omits what event fields are returned beyond the filter parameters.

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

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

Extremely brief at two sentences with no redundancy. However, the first sentence ('Event emitted by the contract') is passive/descriptive while the second ('Subscribe via log filters') is imperative, creating a slight structural disjoint that could be unified for clarity.

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

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

For a simple 2-parameter event tool without output schema, the description is minimally adequate. However, it lacks critical context about the event's significance in the protocol (reduction of USDG supply) and does not explain the relationship between the filter parameters and the returned event data.

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%, documenting 'token' as an Ethereum address and 'amount' as uint256. The description adds no additional semantic context (e.g., that 'token' refers to the collateral token being redeemed, or that 'amount' represents the USDG quantity burned), meeting the baseline for high-coverage schemas.

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 identifies the tool as an event subscription interface ('Subscribe via log filters'), distinguishing it from transaction-based siblings like 'decreasePosition'. However, it fails to explain what 'DecreaseUsdgAmount' represents in business terms (e.g., USDG burning/redemption events) or what data the subscription returns.

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 provided on when to use this tool versus querying state directly or using sibling event tools like 'IncreaseUsdgAmount'. No mention of whether this captures historical logs or real-time subscriptions only.

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

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

With no annotations provided, the description carries the full burden. It discloses mutation ('Write function'), authorization risks ('access control restrictions'), and return value behavior ('No return value'). However, it omits critical behavioral details: whether tokens are transferred from the caller, what state changes occur in the pool, or potential revert conditions.

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

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

The four-sentence structure is efficient and front-loaded with the function signature (useful EVM context). No words are wasted, though the brevity sacrifices necessary detail about the financial operation being performed.

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

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

Given this is a DeFi value-moving operation (depositing assets into a pool), the description is inadequate. It fails to explain the financial mechanics, necessary approvals, event emissions, or side effects on pool liquidity. For a single-parameter write function with no output schema, it should provide more operational context.

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

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

The input schema has 100% coverage, documenting that `_token` is an Ethereum address. The description merely repeats the parameter name and type (`_token: string`) without adding semantic meaning—such as whether this must be a whitelisted token, the token's role in the deposit, or validation requirements.

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 identifies this as a 'Write function' which distinguishes it from view functions in the sibling list, but the opening 'Calls directPoolDeposit(_token: string)' is tautological. It fails to explain the business purpose—what 'direct pool deposit' actually accomplishes (e.g., adding liquidity to a vault pool) or what happens to the deposited tokens.

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

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

It provides a specific usage constraint by warning about access control restrictions (e.g., onlyOwner) and advises checking contract source for modifiers. However, it lacks guidance on when to use this versus sibling alternatives like `increasePosition` or `buyUSDG`, or prerequisites like token approvals.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly implies a read-only subscription pattern by mentioning 'log filters,' but lacks critical details about what data the subscription returns, whether it provides real-time updates or historical logs, or the format of the emitted event data beyond the input filter parameters.

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

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

The description is extremely concise at two sentences. Every word earns its place—establishing the event nature and subscription mechanism immediately. However, the brevity borders on under-specification for a blockchain event tool where additional context would prevent confusion with the transaction-creating function variant.

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 an event subscription tool with no output schema, the description should explain what the agent receives when this event fires and what the parameters represent in the event context (deposit token and quantity). The current description provides no return value documentation or event semantics, leaving significant gaps despite the simple parameter schema.

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

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

The input schema has 100% description coverage for both parameters ('token' and 'amount'), documenting the data types (address and uint256) and formats. The description adds no parameter-specific context, meeting the baseline score for high schema coverage but not compensating with semantic context (e.g., clarifying these are filter criteria for the event logs).

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 identifies this as an event subscription tool ('Event emitted by the contract. Subscribe via log filters'), which clarifies the mechanism. However, it fails to explain what 'DirectPoolDeposit' semantically represents (e.g., liquidity provision events) or what business logic triggers this event, leaving the agent to infer purpose from the name alone.

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 mentions 'Subscribe via log filters,' there is no guidance on when to monitor this event versus calling related state-changing functions (like potential deposit functions). No alternatives or prerequisites are mentioned despite numerous sibling tools with similar naming patterns (PascalCase vs camelCase) that likely represent the corresponding function calls.

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

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

With no annotations provided, the description carries the full burden and successfully discloses key behavioral traits: read-only nature ('does not modify contract state'), access control ('any address can call'), and return type ('Returns address'). It omits details about what the error controller address represents, but covers the critical safety and access properties.

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 four short sentences, each earning its place: identifying the function, declaring read-only status, stating access restrictions, and specifying the return value. It is appropriately sized and front-loaded with essential safety 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 simplicity (zero parameters) and lack of output schema, the description adequately covers the return type ('address') and operational constraints. It successfully compensates for the missing output schema and annotations, though it could briefly clarify what the error controller address is used for.

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 contains zero parameters. Per the baseline rules for zero-parameter tools, this earns a score of 4. There are no parameters requiring semantic clarification in the description text.

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

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

The description states it returns an address and is read-only, distinguishing it from the sibling 'setErrorController'. However, 'Calls errorController()' is somewhat tautological, and it doesn't explicitly state it 'gets' or 'retrieves' the error controller address, slightly weakening the clarity.

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

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

The description provides implicit guidance by stating it is 'Read-only' and 'Unrestricted', contrasting with state-modifying alternatives like 'setErrorController'. However, it lacks explicit guidance on when to use this versus siblings like 'errors' or 'setErrorController'.

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

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

Since no annotations exist, the description carries the full burden. It successfully discloses 'Read-only' status and 'Unrestricted' access, plus return type (string). However, it lacks depth on what the returned string contains (error message format?) or parameter 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?

Four efficient sentences with no filler. Information is front-loaded with the function signature, followed by safety/access control attributes, and return type. Could combine 'Returns string' with first sentence but generally tight.

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

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

Given the complexity of this DeFi protocol (100+ functions including margin trading, swaps, liquidations), the description is insufficient. It doesn't explain the error registry pattern, what valid param0 values are, or how this fits into error handling workflows.

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

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

Schema coverage is 100% and already documents the uint256/string typing. The description mentions 'param0: string' but adds no semantic meaning (e.g., 'error code index' or 'error identifier'), settling at the baseline for high schema coverage.

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

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

The description states it calls the 'errors' function and returns a string, but 'Calls errors' is somewhat tautological. It fails to explain what 'errors' represents in this DeFi vault context (likely an error message lookup by code) or how it differs from dozens of other read functions in the sibling list.

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

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

No guidance provided on when to use this versus other troubleshooting methods (like validateLiquidation) or what specific error codes should be queried. No mention of prerequisites or alternatives.

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

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

Without annotations, the description carries the safety disclosure burden and correctly states 'Read-only — does not modify contract state.' It also discloses the return type (uint256). However, it fails to explain what the returned value represents (e.g., fee amount in wei, USD units, or basis points) or the implications of the parameter (which token's reserves are being queried).

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 efficiently structured in three sentences totaling ~20 words. It front-loads the function signature and immediately follows with safety characteristics. However, extreme brevity comes at the cost of omitting semantic details that would aid tool selection.

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 absence of an output schema and annotations, the description inadequately explains the return value. Stating only 'Returns uint256' without units, scaling, or semantic meaning (e.g., 'returns the amount of accumulated swap fees for the specified token') leaves critical gaps for an agent attempting to interpret or display the result.

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

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

With 100% schema description coverage ('address (Ethereum address, 0x-prefixed)'), the baseline is met. The description mentions 'param0: string' which aligns with the schema but adds no semantic context about what the address represents (e.g., the token address for which to query accumulated fees).

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

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

The description states it calls the feeReserves function and returns a uint256, establishing it as a read operation. However, it fails to explain what 'fee reserves' represent in this DeFi vault context (likely accumulated protocol fees), making it indistinguishable from similar sibling getters like reservedAmounts or poolAmounts without prior domain knowledge.

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 notes the function is 'Unrestricted — any address can call,' providing basic authorization context. However, it offers no guidance on when to use this versus related state queries (e.g., tokenBalances, poolAmounts) or what business logic scenarios warrant checking fee reserves.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates safety (read-only, does not modify state) and access permissions (unrestricted). It also discloses the return type (uint256), though it omits what the uint256 represents (e.g., seconds, blocks).

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 with no filler. Information is front-loaded with the operation name, followed by safety characteristics, access restrictions, and return type. 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?

For a simple parameterless read function without an output schema, the description adequately covers the essential contract: operation identity, mutability, access control, and return type. It could be improved by specifying the semantic meaning of the returned uint256 (time interval units) to fully complete the contract.

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

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

The tool has zero parameters and 100% schema description coverage (trivially). Per the evaluation rules, zero parameters warrants a baseline score of 4. The description does not need to compensate for any parameter documentation gaps.

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

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

The description states the tool calls fundingInterval() and returns a uint256, clearly identifying it as a read operation retrieving a funding interval value. While 'Calls fundingInterval()' is slightly circular, the 'Read-only' designation and return type specification provide adequate specificity to distinguish it from state-modifying siblings.

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

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

The description notes the function is 'Unrestricted — any address can call this read function,' which provides access control guidance. However, it lacks explicit guidance on when to use this versus related siblings like getNextFundingRate, cumulativeFundingRates, or MIN_FUNDING_RATE_INTERVAL.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses that the operation is 'Read-only' and 'does not modify contract state,' covering safety. However, it omits critical context about the return value semantics (e.g., what the uint256 represents, its precision, or valid ranges) beyond the raw type.

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 efficiently structured with four short, distinct statements covering the function call, safety, permissions, and return type. It loses one point for the slightly redundant opening 'Calls fundingRateFactor()' which restates the tool name without adding semantic value.

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

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

Given no output schema exists, the description should explain the return value's meaning. While it states 'Returns uint256,' it fails to describe what this value represents (e.g., 'the current funding rate multiplier used to calculate hourly funding fees'). For a simple getter with 0 inputs, the description is minimally adequate but leaves gaps in semantic understanding.

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 contains zero parameters. As per the baseline rules for 0-parameter tools, this earns a 4. The description correctly does not invent parameter documentation where none exist.

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

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

The description states it calls the fundingRateFactor() function and returns a uint256, but 'Calls fundingRateFactor()' is tautological. It fails to explain what the funding rate factor actually represents (e.g., a multiplier for funding fee calculations) or how it differs from siblings like stableFundingRateFactor or MAX_FUNDING_RATE_FACTOR.

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 notes the function is 'Unrestricted — any address can call this read function,' providing useful permission context. However, it lacks guidance on when to use this tool versus alternatives like getNextFundingRate or stableFundingRateFactor, which are relevant given the DeFi contract context.

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

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

With no annotations provided, the description carries the full burden and successfully discloses the safety profile ('Read-only — does not modify contract state'), access permissions ('Unrestricted'), and return type ('Returns uint256'). It does not mention rate limits or the specific numerical value/scale expected.

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 with zero waste: function signature, mutability state, access control, and return type. Each sentence provides distinct, non-redundant information and is appropriately 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?

For a parameterless constant getter without output schema, the description adequately covers the return type (uint256) and operational constraints. It could be improved by explaining what the precision value represents (e.g., 'scaling factor for funding rate calculations'), but it is sufficient for safe invocation.

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

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

The tool has zero parameters, which per guidelines establishes a baseline of 4. The schema is empty and requires no additional semantic explanation.

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

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

The description clearly identifies this as a read-only getter returning uint256, but the first sentence 'Calls FUNDING_RATE_PRECISION()' is tautological. It doesn't explain what 'funding rate precision' semantically represents (e.g., the decimal scaling factor) to distinguish it from sibling precision constants like BASIS_POINTS_DIVISOR or PRICE_PRECISION.

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 access control guidance ('Unrestricted — any address can call'), which is useful. However, it lacks guidance on when to use this specific precision constant versus the many similar constants available in siblings (e.g., PRICE_PRECISION, USDG_DECIMALS, BASIS_POINTS_DIVISOR).

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

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

With no annotations provided, the description carries the full burden and effectively discloses that the function is read-only, requires no authorization, and returns a structured object { _0: boolean, _1: string }. However, it does not explain what the boolean and string represent semantically (e.g., profit flag and delta amount).

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 efficiently structured, front-loading critical safety information ('Read-only', 'Unrestricted') before detailing the signature and return type. The opening 'Calls getDelta' is slightly redundant with the tool name but serves to introduce the parameter list.

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

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

Given the complexity of the DeFi vault protocol (evident from 100+ sibling tools), the description provides minimal viable context: it specifies the return structure (compensating for lack of output schema) and safety properties. However, it omits crucial domain context like what 'delta' calculates (price difference, funding fee, etc.) and how it relates to position management.

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 (types like uint256, bool, address are documented), establishing a baseline of 3. The description lists the parameter names and types but adds no business semantics (e.g., what _lastIncreasedTime represents or that _indexToken is the position's underlying asset).

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

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

The description states it 'Calls getDelta' with specific parameters and returns a boolean and string, but does not explain what 'delta' represents (e.g., PnL, funding rate delta) or the business logic of the calculation. It mentions the function signature but fails to distinguish from siblings like getPositionDelta or getGlobalShortDelta.

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 notes the function is 'Read-only' and 'Unrestricted,' providing basic safety and permission context, but lacks explicit guidance on when to use this raw calculation function versus retrieving stored position data via getPositionDelta or other sibling tools.

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

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

With no annotations provided, the description successfully discloses critical behavioral traits: it explicitly states 'does not modify contract state' and 'any address can call this read function,' covering safety and authorization. However, it omits calculation logic details, potential revert conditions, or gas considerations.

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 with no extraneous information. The first sentence is somewhat redundant (repeating signature already defined in schema), but the subsequent sentences efficiently convey safety characteristics. Information is front-loaded with the function signature, though the opening could be more descriptive.

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 accepts five parameters for a calculation, yet lacks business logic explanation. It compensates for the missing output schema by stating 'Returns uint256,' but does not clarify what the returned value represents (basis points percentage, absolute fee, etc.) or provide calculation context. Adequate but incomplete for a complex financial calculation 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 provides 100% description coverage for all five parameters (types and formats). The description merely lists the parameter signature without adding semantic context (e.g., explaining that _usdgDelta represents supply change, or how _increment affects the calculation). Baseline score applies since schema carries full load.

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 opens with 'Calls getFeeBasisPoints...' which is tautological, merely restating the tool name. While it specifies the function signature and return type, it fails to explain what the function actually calculates (e.g., computing adjusted fee rates) or how it differs from sibling tools like swapFeeBasisPoints, taxBasisPoints, or getPositionFee.

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 notes the tool is 'Read-only' and 'Unrestricted,' but provides no guidance on when to use this specific fee calculation versus the numerous sibling fee-related tools (e.g., marginFeeBasisPoints, stableSwapFeeBasisPoints). No prerequisites, conditions, or alternative selection criteria are provided.

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

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

Since no annotations are provided, the description carries the full burden. It successfully discloses that the operation is read-only, unrestricted (any address can call), and returns uint256. However, it omits what the returned value represents (fee amount in what unit/precision) and potential revert conditions.

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

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

The description is efficiently structured across three short sentences. The first sentence contains redundant type information already present in the schema, but overall there is minimal waste and the key behavioral properties (read-only, unrestricted) are 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?

For a calculation tool with 3 parameters and no output schema, the description covers the function signature and access patterns but lacks explanation of the return value's semantic meaning (currency, precision) and the business logic of funding fee calculation. Adequate but incomplete for DeFi contract interaction.

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

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

With 100% schema description coverage, the baseline is 3. The description lists the three parameters with types but adds no semantic context beyond the schema (e.g., what _entryFundingRate represents chronologically, or that _size refers to position size). It neither improves upon nor detracts from the schema documentation.

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

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

The description states it 'Calls getFundingFee' which restates the tool name (tautology), but clarifies it returns uint256. However, it fails to explain what a funding fee actually represents (accrual calculation for perpetual positions) or how it differs from sibling fee functions like getPositionFee or getNextFundingRate.

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 notes the function is 'Read-only' and 'Unrestricted', it provides no guidance on when to use this specific calculation versus the 10+ sibling fee and funding-related tools (e.g., getNextFundingRate, getPositionFee). No prerequisites or alternative selection criteria are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and succeeds in communicating the safety profile (read-only, non-destructive) and access control (unrestricted). It also manually documents the return structure ({ _0: boolean, _1: string }) since no output schema exists, though it omits semantic meaning of those return values.

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

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

The description consists of four efficient sentences, each delivering distinct value: function signature, mutability guarantee, access control, and return type structure. There is no redundant or wasted language; information is front-loaded with the call signature followed by critical behavioral constraints.

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

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

For a simple single-parameter read function, the description is nearly complete. It compensates for the missing output schema by specifying the return type structure, documents the single required parameter through the schema, and discloses behavioral traits. It falls short of a 5 only because it does not explain the semantic meaning of the boolean and string return values (e.g., what condition the boolean represents).

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 the _token parameter fully documented as an Ethereum address. The description mentions '_token: string' which aligns with but does not extend beyond the schema's type information. At this coverage level, the baseline score of 3 is appropriate as the description does not need to compensate for missing schema documentation.

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

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

The description uses the tautological 'Calls getGlobalShortDelta' which merely restates the tool name, earning only baseline clarity. While the return type hint ({ _0: boolean, _1: string }) suggests it retrieves delta values for global short positions, it fails to explain what 'Global Short Delta' actually represents or how it differs from siblings like getDelta or getPositionDelta.

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 implied usage context by stating the function is 'Read-only' and 'Unrestricted — any address can call this read function', indicating no authentication requirements. However, it lacks explicit guidance on when to prefer this over similar delta-calculation siblings (e.g., getPositionDelta) or what business logic scenarios warrant its use.

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

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

With no annotations provided, the description carries the full burden and effectively discloses key behavioral traits: 'Read-only — does not modify contract state' and 'Unrestricted — any address can call'. This covers the safety and permission profile well, though it could add revert conditions or price precision details.

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 with zero waste. Information is front-loaded with the function signature, followed by critical behavioral properties (read-only/unrestricted) and return type. Every sentence earns its place.

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

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

For a single-parameter read function, the description is minimally adequate. It notes the return type (uint256) compensating for the lack of output schema. However, given the complexity of the sibling ecosystem (90+ functions), it should explain what 'max price' means (e.g., maximum price for swaps/collateral).

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 (the _token parameter is documented as an Ethereum address). The description mentions '_token: string' but adds no semantic meaning beyond the schema. With high schema coverage, baseline 3 is appropriate.

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

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

The description identifies the function as read-only and specifies it returns uint256, which clarifies beyond the name. However, it fails to distinguish from sibling getMinPrice or explain what 'max price' represents in this DeFi context (e.g., maximum oracle price).

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

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

No guidance is provided on when to use this versus getMinPrice or other price-related siblings. The description does not indicate use cases such as 'use this for long position pricing' or similar contract-specific logic.

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?

Excellent disclosure given no annotations: explicitly states 'Read-only — does not modify contract state' and 'Unrestricted — any address can call this read function'. Also specifies return type (uint256) which compensates for missing output 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?

Three short sentences with minimal waste. The first sentence restates the function signature (slight redundancy), but the remaining sentences efficiently convey critical behavioral properties. Front-loaded with the essential call pattern.

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?

Adequate for a single-parameter getter: mentions return type despite no output schema. However, missing crucial context like price decimals/precision (common in DeFi contracts) and the specific meaning of 'minimum' (min of multiple oracles? TWAP floor?).

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 describing _token as an Ethereum address. The description mentions '_token: string' but this merely restates the signature without adding semantic context (e.g., 'the whitelisted token address to query'). Baseline 3 is appropriate when schema carries the load.

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

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

The description states it calls getMinPrice and returns uint256, but does not explain what 'minimum price' means in this DeFi context (e.g., minimum token price from oracle, floor price, etc.). It distinguishes read-only behavior but lacks semantic clarity on the business purpose.

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

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

No guidance provided on when to use getMinPrice versus siblings like getMaxPrice, getPosition, or other price-related functions. The agent cannot determine if this returns the minimum acceptable collateral price, historical low, or current floor price without trial and error.

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

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

Without annotations, the description carries the full burden and successfully discloses that the operation is 'Read-only' and 'Unrestricted' (any address can call). However, it omits details about calculation precision, revert conditions, or the meaning of the returned value (price with what decimals?).

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 function signature. While efficient, the first sentence is partially redundant since the schema already defines the parameters. The safety properties are clearly stated in separate sentences.

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

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

Given the complexity of position calculations and 7 parameters, the description is minimally adequate. It notes the return type (uint256) compensating somewhat for the missing output schema, but lacks explanation of the calculation's business logic or what the return value represents.

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

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

With 100% schema description coverage, the baseline is 3. The description lists parameters in the signature but adds no semantic context beyond the schema (e.g., does not explain that _sizeDelta represents the increase in position size or that _lastIncreasedTime affects funding calculations).

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

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

The description states the function signature and indicates it returns a uint256, but fails to explain what 'next average price' actually calculates (e.g., the new average entry price when increasing a position size). It relies on the function name to convey meaning, which is vague without domain knowledge.

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 provided on when to use this calculation versus siblings like getPosition or getPositionDelta. No mention of prerequisites such as needing existing position data or how this fits into the trading workflow.

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

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

Without annotations, the description carries the full burden and successfully discloses critical behavioral traits: it explicitly states the operation is read-only ('does not modify contract state') and permissionless ('any address can call'). Minor gap: doesn't interpret the uint256 return value (e.g., precision, units, or what 'next' timeframe refers to).

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

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

Extremely efficient three-sentence structure with zero waste: function signature, safety constraints, and return type. Information is front-loaded and dense. No redundant or filler 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 this is a simple single-parameter getter with full schema coverage, the description is nearly complete. It mentions the return type to compensate for missing output schema. Minor deduction for not explaining funding rate semantics or return value units, which would be necessary for the agent to interpret the raw uint256 result 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% with clear type documentation ('Ethereum address, 0x-prefixed'). The description mirrors this with '_token: string' but adds no semantic context beyond the schema, such as specifying this must be a whitelisted token address or providing an example. Baseline 3 is appropriate since schema is comprehensive.

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

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

States the specific action (calls getNextFundingRate) and target resource (funding rate for a token), including the return type (uint256). However, it assumes the agent understands what a 'next funding rate' represents in this DeFi context without explaining the domain concept or time horizon (next funding interval).

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

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

Provides safety context ('Read-only', 'Unrestricted') which implies when it's safe to call, but fails to differentiate from sibling funding-related tools like getFundingFee, cumulativeFundingRates, or fundingRateFactor. No guidance on when to prefer this over other funding 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates safety (read-only, does not modify state) and access control (unrestricted), plus specifies the return type (uint256). It could improve by explaining what the returned value represents (e.g., price precision units).

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

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

Extremely efficient four-sentence structure. Front-loaded with function signature, followed by safety guarantees, access permissions, and return type. No redundant or filler 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?

Adequate for a 3-parameter read-only function with no output schema, covering mutability and return type. However, it lacks domain context about the calculation's purpose (calculating average entry prices for global short exposure) and does not clarify the units or precision of the returned uint256.

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%, establishing a baseline of 3. The description lists parameters with their types but adds no semantic context beyond the schema (e.g., explaining that _sizeDelta represents the change in position size or _nextPrice is the anticipated mark price).

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

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

The description states it calls a specific smart contract function and identifies it as read-only, but relies heavily on the function name to convey meaning. It lacks explanation of what 'next global short average price' represents conceptually (e.g., the average entry price for short positions after a size change).

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

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

No guidance on when to use this tool versus siblings like getNextAveragePrice or getGlobalShortDelta. While it notes the function is 'unrestricted,' it does not describe scenarios or prerequisites 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?

With no annotations provided, the description adequately discloses that the function is read-only and unrestricted (callable by any address). However, it fails to explain the semantics of the 8 returned tuple fields (_0 through _7), only listing their types, leaving the agent unaware of what data (size, collateral, entry price, etc.) is actually returned.

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 efficiently structured into four segments: function signature, read-only nature, access restrictions, and return type. It contains minimal redundancy, though repeating parameter types that are fully documented in the schema is slightly wasteful.

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

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

For a 4-parameter read operation with simple types, the description covers the technical signature and basic behavioral constraints. However, given the complexity of DeFi position data (8 return fields), the description is incomplete without documenting what the returned values represent.

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 lists parameters with types but adds no semantic meaning beyond the schema (e.g., it does not explain that _isLong indicates a long vs short position, or that _indexToken represents the traded asset).

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

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

The description states the tool calls getPosition with specific parameters (account, collateralToken, indexToken, isLong), indicating it retrieves a trading position. However, it does not explicitly differentiate from sibling tools like getPositionDelta, getPositionFee, or getPositionLeverage, which return specific subsets of position 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?

No guidance is provided on when to use this comprehensive getter versus the specialized sibling getters (getPositionDelta, getPositionLeverage, etc.). The description notes it is unrestricted and read-only, but lacks selection criteria 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?

With no annotations provided, the description effectively carries the full burden by disclosing 'Read-only — does not modify contract state' and 'Unrestricted — any address can call this read function'. It also specifies the exact return structure '{ _0: boolean, _1: string }' which compensates for the missing output 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 efficiently structured in four short clauses. No sentences are wasted; even the function signature repetition serves to map parameters to return values. However, the signature repetition is somewhat redundant given the schema.

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

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

Given the lack of annotations and output schema, the description provides essential safety context (read-only, unrestricted) and return type structure. However, it lacks semantic explanation of what the boolean and string return values represent (e.g., hasProfit, deltaAmount) and doesn't clarify the business logic of 'position delta' calculation.

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 with types and formats already documented. The description merely repeats the parameter list with types ('_account: string, _collateralToken: string...') without adding semantic meaning (e.g., what '_isLong' represents in trading contexts). Baseline 3 is appropriate when schema coverage is complete.

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 opens with 'Calls getPositionDelta(...)' which tautologically restates the tool name. While it mentions the return type structure, it fails to explain what 'position delta' actually calculates (e.g., profit/loss, price difference) or how it differs from sibling tools like 'getDelta' or 'getPosition'.

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 the numerous sibling position-querying tools (getPosition, getPositionFee, getPositionLeverage, getDelta). The 'Read-only' and 'Unrestricted' statements describe properties, not use cases or selection criteria.

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

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

With no annotations provided, the description carries the full burden and successfully discloses key behavioral traits: it explicitly states 'Read-only — does not modify contract state' and 'Unrestricted — any address can call this read function'. However, it fails to explain what the returned uint256 represents (e.g., fee amount in wei, basis points, etc.).

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 efficiently structured with four short sentences. Key safety information (read-only, unrestricted) is front-loaded. However, the opening sentence 'Calls getPositionFee...' wastes space restating the obvious instead of defining the concept.

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 complex DeFi domain and lack of output schema, the description should explain return value semantics (fee calculation method, token units). It mentions 'Returns uint256' but this is insufficient compared to the rich sibling ecosystem available. Missing differentiation from related fee functions leaves gaps.

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

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

The input schema has 100% description coverage, documenting _sizeDelta as a uint256 decimal string. The description merely echoes '_sizeDelta: string' without adding semantic context about what the size delta represents (e.g., position size change) or expected value format beyond the schema's explanation.

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

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

The description primarily states 'Calls getPositionFee(_sizeDelta: string)' which is tautological—it merely repeats the function name and signature without explaining what a 'position fee' represents or how it differs from sibling fee functions like getFundingFee or getFeeBasisPoints. While it adds 'Returns uint256', this lacks semantic meaning (units, currency).

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 the numerous similar position and fee-related siblings (e.g., getFundingFee, getPosition, getFeeBasisPoints). There are no prerequisites, conditions, or explicit alternatives mentioned.

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

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

With no annotations provided, the description successfully carries the full burden of behavioral disclosure. It explicitly states the function is read-only, unrestricted (any address can call), and returns bytes32. This covers the essential behavioral traits for a blockchain view function, though it omits potential revert conditions or gas considerations.

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 efficiently structured with three distinct sentences covering the function signature, state modification behavior, and access/return characteristics. While repeating the full parameter list is slightly redundant given the schema, there is no extraneous information and the critical details are 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?

For a simple view function with no output schema, the description adequately covers the return type (bytes32) and input requirements. However, it misses the opportunity to explain what the position key represents (a unique identifier hash) and how it relates to the broader position management workflow evident in sibling tools like 'increasePosition' and 'decreasePosition'.

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 with type information for all four parameters. The description lists the parameters in the function signature but adds no semantic context beyond the schema (e.g., explaining that _isLong indicates a long vs short position, or that the tokens represent the collateral and index/market pair). Baseline 3 is appropriate given the complete schema coverage.

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

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

The description clearly identifies this as a read operation returning a bytes32 position key, with specific parameters listed. It distinguishes from siblings like 'getPosition' by specifying the return type (bytes32 key vs position data), though it could more explicitly explain that this generates a unique identifier rather than retrieving position state.

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 safety information (read-only, unrestricted access) but offers no guidance on when to use this tool versus alternatives like 'getPosition', 'getPositionDelta', or 'getPositionLeverage'. It does not explain that this is typically a prerequisite step to generate the key needed for other position lookups.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully declares the read-only nature ('does not modify contract state'), access control ('Unrestricted — any address can call'), and return type ('Returns uint256'), providing essential safety and usage context.

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

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

The description is efficiently structured in three sentences: function signature, safety properties, and return type. The first sentence is slightly redundant with the tool name, but every sentence provides distinct value (params, read-only status, access, return type) without verbosity.

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 getter function with 4 parameters and no output schema, the description is reasonably complete. It compensates for the missing output schema by specifying the return type (uint256). However, it lacks clarification on the leverage format (e.g., whether 10x leverage returns 10, 10000, or 10000000).

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 (address types and bool are well-documented). The description lists the parameters but adds no semantic context beyond the schema (e.g., explaining that `_isLong` determines direction or that `_indexToken` is the traded asset). With high schema coverage, baseline 3 is appropriate.

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

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

The description clearly identifies this as a read operation that retrieves position leverage, distinguishing it from siblings like `getPosition` or `getPositionDelta`. While opening with 'Calls getPositionLeverage...' is slightly tautological, it immediately specifies the four key parameters, clarifying the scope of the query.

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. Given siblings like `getPosition` (likely returns full position data) and `getPositionDelta`, the description should clarify that this specifically retrieves leverage ratio when that single metric is needed, rather than full position state.

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

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

With no annotations provided, the description carries the full burden and successfully discloses key behavioral traits: read-only nature ('does not modify contract state'), permissionlessness ('any address can call'), and return type ('Returns uint256'). It does not, however, explain potential failure modes or revert conditions.

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

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

The description is efficiently packed into one sentence with functional details parenthetically noted. The opening clause 'Calls getRedemptionAmount' is slightly tautological given the tool name, but the remainder adds value without verbosity.

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 mentions the return type (uint256) but omits critical semantic details—such as what the value represents (token quantity in wei?), whether it accounts for fees/slippage, or the calculation methodology. For a financial calculation tool, this context is missing.

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

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

The input schema has 100% description coverage (token address and uint256 format), establishing a baseline of 3. The description mentions the parameter names and types but adds no additional semantic context (e.g., that _usdgAmount is the amount to burn, or what the token represents) beyond what the schema already provides.

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

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

The description clearly identifies this as a call to getRedemptionAmount with specific parameters and notes it returns uint256. However, it fails to distinguish from similar siblings like getRedemptionCollateral and getRedemptionCollateralUsd, or explain what 'redemption' means in this context (e.g., burning USDG for tokens).

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

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

While it notes the function is 'Unrestricted — any address can call,' it provides no guidance on when to use this tool versus the many related redemption/collateral calculation siblings (getRedemptionCollateral, getRedemptionCollateralUsd, etc.). No prerequisites or selection criteria are offered.

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

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

Without annotations, the description carries the full burden and successfully discloses read-only safety ('does not modify contract state'), permissionlessness ('any address can call'), and return type ('uint256'). However, it omits what the uint256 represents semantically (e.g., token amount in wei, collateral value).

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

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

Three sentences efficiently convey the function signature, safety profile, and return type with no redundancy. Critical safety information (read-only, unrestricted) is front-loaded effectively.

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?

Adequate for a simple getter with one parameter—covers basic invocation needs. However, given the DeFi context (evident from siblings like USDG, vault functions), the description lacks domain-specific context about collateral mechanics, redemption logic, or return value units that would aid correct usage.

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

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

The input schema has 100% coverage with clear typing ('address (Ethereum address, 0x-prefixed)'). The description merely repeats the parameter name and type without adding semantic context (e.g., which token's redemption collateral is being queried), meeting the baseline for high schema coverage.

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

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

The description states it calls the getRedemptionCollateral function and returns uint256, but offers no explanation of what 'redemption collateral' represents or how it differs from siblings like getRedemptionCollateralUsd or getRedemptionAmount. It relies on the function name to convey meaning.

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 notes the function is 'Unrestricted' regarding access permissions, but provides no guidance on when to use this tool versus the many similar getter siblings (e.g., getRedemptionAmount, getRedemptionCollateralUsd) or what query scenarios warrant this specific call.

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

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

With no annotations provided, the description effectively carries the full burden by explicitly declaring 'Read-only' and 'Unrestricted' access characteristics. It also specifies the return type (uint256). However, it lacks details on return value semantics (decimals, units) or failure modes.

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 efficient sentences with no redundancy. Information is well-structured: function signature first, followed by behavioral constraints (readonly/unrestricted), then return type. Every sentence earns its place.

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

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

For a single-parameter read function, the description covers the essential safety profile and return type. However, it lacks domain context—what redemption collateral represents, the precision of the USD value, and the relationship to similar redemption-related sibling tools. Adequate but incomplete.

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

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

Schema coverage is 100% with the _token parameter fully documented as an Ethereum address. The description mirrors this with '(_token: string)' but adds no additional semantic context (e.g., 'the token for which to query redemption collateral value'). Baseline score appropriate for high schema coverage without description enrichment.

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

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

The description states the technical action (calls the contract function) and return type (uint256), but fails to explain the semantic purpose—what 'redemption collateral USD' actually represents or how it differs from sibling functions like getRedemptionCollateral or getRedemptionAmount. It relies on the function name to convey meaning.

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 (e.g., getRedemptionCollateral vs getRedemptionCollateralUsd). There are no prerequisites, conditions, or contextual recommendations for selection.

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

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

With no annotations provided, the description effectively carries the safety burden by explicitly stating 'Read-only — does not modify contract state' and 'Unrestricted — any address can call this read function'. It also discloses the return type (uint256). This provides essential behavioral context that would typically come from 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 efficiently structured with three short sentences: function signature, safety/permissions, and return type. There is no redundant information, though the first sentence is somewhat tautological. Information is appropriately front-loaded with the function call format.

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 single-parameter read function without output schema, the description covers mechanical aspects (call signature, return type, safety). However, it lacks context on what the returned uint256 represents (units, decimals, calculation methodology) and how it relates to protocol mechanics, which would help an agent interpret the result 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?

The input schema has 100% description coverage for the single `_token` parameter. The description merely echoes that it accepts a token string, adding no additional semantic value (e.g., whether it accepts any ERC20 or only whitelisted collateral tokens). Baseline score of 3 is appropriate when schema documentation is complete.

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

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

The description states the technical action (calling a function) and return type (uint256), but fails to explain what 'target USDG amount' represents semantically (e.g., debt ceiling, optimal collateral ratio, or supply target). It relies on the function name itself without clarifying the business logic for an agent unfamiliar with this specific DeFi 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?

No guidance is provided on when to use this versus sibling tools like `maxUsdgAmounts`, `usdgAmounts`, or `getRedemptionAmount`. Given the numerous USDG-related state readers available, the description offers no criteria for selecting this specific metric over alternatives that sound conceptually similar.

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

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

With no annotations provided, the description carries the full burden and successfully discloses the read-only nature and unrestricted access. However, it lacks critical behavioral context about the return value (what the uint256 represents—basis points, percentage, raw amount?), error conditions, or units of measurement.

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 with three efficient sentences and no redundant fluff. Information is front-loaded with the function signature, followed by behavioral constraints and return type. Minor deduction for the slightly tautological opening sentence.

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

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

For a single-parameter getter without an output schema, the description adequately covers the basics (parameter, safety, return type). However, it misses the semantic meaning of the return value and lacks guidance on interpreting utilization metrics, leaving gaps for effective tool selection.

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, clearly defining _token as an Ethereum address. The description mentions the parameter in the function signature but adds no semantic meaning beyond what the schema already provides, warranting the baseline score for high-coverage schemas.

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

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

The description states it calls a specific contract function and returns a uint256, but fails to explain what 'utilisation' actually measures (e.g., pool utilization ratio, token usage percentage) or how it differs from sibling getters like getPoolAmounts or getReservedAmounts. The first sentence largely restates the tool name with the parameter signature.

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

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

While it notes the function is 'Read-only' and 'Unrestricted', there is no guidance on when to use this tool versus the numerous alternative getter functions available (getPosition, getDelta, getFeeBasisPoints, etc.). No prerequisites or contextual triggers 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?

Without annotations, the description carries the safety burden and successfully discloses 'Read-only' and 'Unrestricted' access. However, it omits critical behavioral context: what the returned uint256 represents (price precision, denominated asset) and how the average is calculated.

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 with minimal redundancy. The opening 'Calls globalShortAveragePrices(param0: string)' is somewhat tautological, but the remaining sentences efficiently convey access control and return type 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?

For a complex DeFi protocol tool (evidenced by 100+ siblings involving positions, funding rates, and liquidation), the description lacks essential context: the parameter's semantic role, the return value's units/precision, and the financial meaning of the calculation. No output schema exists to 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?

Schema coverage is 100% (param0 described as Ethereum address), establishing baseline 3. The description repeats 'param0: string' without adding semantic meaning—failing to clarify what address is expected (token address? trader address? pool address?).

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

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

The description states it calls the function and returns uint256, but relies on the function name itself to convey meaning. It does not explain what 'global short average prices' actually calculates (e.g., average entry price for short positions) or distinguish from siblings like getNextGlobalShortAveragePrice or globalShortSizes.

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 versus alternatives. Given siblings like getNextGlobalShortAveragePrice and getGlobalShortDelta exist, the description fails to clarify which short-pricing tool is appropriate for specific scenarios.

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

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

With no annotations provided, the description carries the full burden. It effectively discloses the safety profile (read-only, does not modify state) and access restrictions (unrestricted). It also specifies the return type (uint256). However, it omits what the returned value represents semantically (e.g., the unit or scale of the short size).

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, generally efficient. The first sentence ('Calls globalShortSizes...') wastes space restating the tool name, but the remaining sentences deliver valuable behavioral information 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?

Adequate for a simple single-parameter read function. It compensates for the missing output schema by stating the return type. However, it lacks explanation of the business logic (what 'short sizes' means in the context of the protocol) and appropriate sibling differentiation.

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

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

Schema coverage is 100%, documenting param0 as an Ethereum address. The description mentions 'param0: string' but adds no semantic meaning beyond the schema (e.g., it doesn't clarify whether this is a token address, trader address, or market identifier). Baseline score appropriate for high schema coverage.

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

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

The description states it 'Calls globalShortSizes' which is somewhat tautological, though it clarifies the return type (uint256). It fails to explain what 'global short sizes' actually represents (e.g., total short position size for a token) or how it differs from siblings like getGlobalShortDelta or globalShortAveragePrices.

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

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

Provides no guidance on when to use this versus similar sibling tools (getGlobalShortDelta, globalShortAveragePrices). The only usage hint is 'Unrestricted — any address can call', which describes access control rather than use cases.

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

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

With no annotations provided, the description carries the full burden and successfully discloses key behavioral traits: it explicitly states the operation is read-only ('does not modify contract state'), specifies access control ('Unrestricted — any address can call'), and reveals the return type ('Returns address'). It misses only minor details like gas considerations or revert conditions.

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

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

The description consists of three highly efficient sentences with no wasted words. It front-loads the action ('Calls gov()'), immediately follows with behavioral constraints ('Read-only', 'Unrestricted'), and concludes with the return value. 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 this is a simple getter with no parameters and no output schema, the description is complete. It explains what the function does, who can call it, its side effects (none), and what it returns. No additional context is necessary for an agent to invoke this 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?

The tool has zero parameters, which establishes a baseline of 4 per the scoring rules. The empty input schema requires no additional semantic clarification from the description, and the 100% schema coverage (vacuously true for zero params) 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 states it 'Calls gov()' and 'Returns address', making it clear this retrieves a governance address (likely the contract owner/admin). It implicitly distinguishes from sibling 'setGov' by emphasizing it is read-only, though it could be more explicit about what 'gov' represents (e.g., 'governance contract address').

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 through 'Read-only' and 'Unrestricted' (any address can call), indicating no permissions are needed and it's safe to call. However, it lacks explicit guidance on when to use this versus alternatives like 'setGov', or prerequisites for interpreting the returned address.

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

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

With no annotations provided, the description carries full disclosure burden and successfully delivers: it declares the read-only nature (no state modification), unrestricted access policy, and return type (uint256). This compensates well for missing structured safety 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 efficiently convey function signature, safety profile, access control, and return type. No extraneous information, though the opening 'Calls guaranteedUsd...' is slightly redundant given the tool name.

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

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

For a simple single-parameter read operation, the description is complete. It compensates for the lack of output schema by explicitly stating 'Returns uint256', giving the agent necessary type information to handle the response.

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 param0 clearly documented as an Ethereum address. The description mentions 'param0: string' which is less specific than the schema, but since the schema is complete, it meets the baseline expectation without adding redundant 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 states it calls the function and returns uint256, but opens with tautological 'Calls guaranteedUsd(param0: string)'. It fails to explain what 'guaranteedUsd' conceptually represents (e.g., guaranteed collateral value for a token) despite having opaque blockchain-specific nomenclature.

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 'Read-only' and 'Unrestricted — any address can call', providing clear guidance on access control and safety. However, it does not differentiate when to use this versus sibling read functions like 'getPosition' or 'tokenToUsdMin'.

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

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

With no annotations provided, the description carries full burden and successfully discloses read-only nature, unrestricted access, and boolean return type. However, it omits what the boolean signifies (true/false semantics) and potential revert conditions.

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

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

Three short sentences with zero fluff. Front-loaded with function name, followed by safety traits and return type. Every clause 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?

Adequate for a simple getter but incomplete due to lack of output schema and no explanation of what the returned boolean represents (e.g., true if dynamic fees enabled). Missing contextual relationship to sibling fee functions.

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 contains zero parameters, establishing baseline 4. The description confirms this is a parameterless call by stating 'Calls hasDynamicFees()' with no argument mention, consistent with the empty schema.

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

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

States it calls the hasDynamicFees() function and returns a boolean, establishing it as a read operation checking a specific contract state. While 'Calls hasDynamicFees()' is somewhat tautological, the addition of 'Read-only' and 'Returns bool' clarifies the operation type and output.

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

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

Mentions 'Unrestricted' access indicating no permissions needed, but provides no guidance on when to use this versus other fee-related functions like getFeeBasisPoints or swapFeeBasisPoints, or what to do with the boolean result.

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

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

With no annotations provided, the description carries full disclosure burden and successfully communicates read-only safety ('does not modify contract state'), permissionlessness ('any address can call'), and return type ('Returns bool'). No contradictions with structured data.

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 totaling ~20 words is appropriately brief, but the opening sentence ('Calls includeAmmPrice()') wastes precious front-loaded space on tautology rather than value. Subsequent sentences efficiently convey access patterns and return type.

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

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

For a simple state-reading tool with no parameters and no output schema, mentioning the boolean return and unrestricted access provides minimum viable context. However, it should clarify what 'include AMM price' means semantically (the boolean's business logic) to be 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?

Zero parameters present per input schema (empty object). Per scoring rules, 0-parameter tools receive baseline score of 4. No parameter documentation is required or provided.

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

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

The description opens with tautology ('Calls includeAmmPrice()') restating the tool name rather than explaining the business purpose. While 'Returns bool' hints at a getter function, it fails to specify what the boolean represents (e.g., whether AMM pricing is enabled) or distinguish from other read-only sibling getters.

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

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

Provides implicit usage guidance through access control statements ('Unrestricted — any address can call'), indicating no authentication requirements. However, it lacks explicit when-to-use guidance, comparisons to sibling tools (e.g., when to check this vs. other price configurations), 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully indicates this is a log subscription tool rather than a state-changing transaction, but fails to describe return format (event objects vs. arrays), polling intervals, historical range limits, or error conditions when filters match no events.

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

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

The description is extremely brief (two sentences) with no filler. The information is front-loaded with the event nature declared immediately. However, given the complexity of blockchain event subscription and the lack of other metadata, this brevity contributes to under-specification rather than elegant 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?

For a DeFi vault contract tool with no output schema and no annotations, the description is inadequate. It does not explain what 'guaranteedUsd' represents in the protocol, when this event is typically emitted (e.g., during position increases), what data structure is returned, or how to interpret the token/amount values in context.

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

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

The input schema has 100% description coverage (token as address, amount as uint256), establishing a baseline of 3. The description adds no additional context about these parameters—specifically, whether the amount represents the increase delta, the new total, or a filter threshold for event queries.

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 identifies the subject (an event emitted by the contract) but fails to clearly state what the tool actually does—whether it subscribes to real-time events, queries historical logs, or filters by the provided parameters. It also does not distinguish from sibling tools like DecreaseGuaranteedUsd or explain how this event relates to the contract's functionality.

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

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

No guidance is provided on when to use this tool versus alternatives, what prerequisites exist (e.g., connected wallet, specific network), or when to choose this over querying state directly via tools like guaranteedUsd. The phrase 'Subscribe via log filters' implies usage but doesn't explain when this is appropriate.

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

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

With no annotations provided, the description carries the full burden. It successfully clarifies this is a read-only subscription interface, not a state-changing transaction (critical given the imperative 'Increase' naming). However, it omits emission triggers, return data structure, and whether this streams ongoing events or queries historical logs.

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 zero redundancy. Every word conveys essential information (event type, subscription method). No filler or unnecessary elaboration.

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 the simple 2-parameter schema, the description lacks critical domain context: what triggers the event, the relationship between the token/amount parameters and the event payload, and expected return format. The imperative name creates significant ambiguity that the description only partially resolves.

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% description coverage with clear type definitions (Ethereum address, uint256). The description adds no parameter context or constraints, meeting the baseline for well-documented schemas.

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?

Identifies the tool as monitoring an 'Event emitted by the contract' and specifies the mechanism ('Subscribe via log filters'), clarifying it is not a function to increase pool amounts. However, it fails to explain what the event represents semantically (e.g., liquidity deposits) or what 'pool amount' refers to in this domain.

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

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

Provides the technical mechanism ('Subscribe via log filters') but offers no guidance on when to use this event subscription versus querying state directly (e.g., vs poolAmounts sibling) or whether to use this for historical queries versus real-time monitoring.

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

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

With no annotations provided, the description carries the burden. It correctly identifies the write nature, access control risks, and 'No return value'. However, it omits key behavioral details like whether this transfers tokens, emits events, or reverts under specific conditions (e.g., insufficient collateral).

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?

Compact three-sentence structure with no filler. The function signature is front-loaded, followed by behavioral warnings and return value. Efficient use of space, though the opening 'Calls increasePosition...' is slightly redundant with the tool name.

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?

Adequate for a raw contract interaction tool: it discloses the write nature, access control risks, and lack of return value (compensating for missing output schema). However, for a complex financial operation involving 5 parameters and significant state changes, it lacks context on side effects (e.g., position updates, fee accrual).

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% description coverage (types and formats like '0x-prefixed'), establishing a baseline of 3. The description repeats the parameter list from the schema but adds no business-level semantics (e.g., explaining that _sizeDelta represents the USD amount to increase position by, or that _isLong indicates bullish/bearish direction).

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?

Identifies it as a 'Write function' and lists the parameter types, but relies heavily on the function name ('increasePosition') without explaining the business logic (e.g., increasing leverage/size of a margin trading position). Does not differentiate from siblings like 'IncreasePosition' (capitalized) or 'decreasePosition'.

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

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

Provides critical safety guidance about access control restrictions (e.g., onlyOwner) and advises checking contract source for modifiers. However, lacks guidance on when to use this versus 'decreasePosition' or 'ClosePosition', or prerequisites like token approvals.

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

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

No annotations are provided, so the description carries full burden. While it identifies this as an event subscription, it lacks critical behavioral details: whether this is a persistent subscription or one-time fetch, what triggers the event (blockchain state changes), whether it returns historical logs or only new ones, and performance characteristics for a 9-parameter filter.

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

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

Extremely concise at two short sentences. No redundant or filler text. However, the brevity comes at the cost of omitting necessary context for a complex blockchain event subscription tool with 9 parameters.

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

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

Inadequate for the complexity. This is a 9-parameter blockchain event subscription tool with no output schema and no annotations. The description should explain the trading domain context (perpetual/ margin trading), the event trigger conditions, and what data is returned when the event fires, but provides none of this.

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 with type information (uint256, address, bytes32). The description adds no parameter-specific context, but with complete schema documentation, this meets the baseline expectation without additional penalty or credit.

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?

Identifies this as an event subscription tool ('Event emitted by the contract. Subscribe via log filters'), distinguishing it from the 'increasePosition' function sibling. However, it fails to explain the business semantics of 'increasing a position' (adding collateral/size to a leveraged trade) despite having trading-related parameters like collateralToken, sizeDelta, and isLong.

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

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

Mentions 'Subscribe via log filters' indicating the mechanism, but provides no guidance on when to use this event subscription versus querying state directly, or how it relates to sibling events like DecreasePosition/ClosePosition. No mention of filter criteria behavior or subscription lifecycle.

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

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

Without annotations, the description carries the burden of disclosure. It successfully clarifies this is a read-only event subscription (not a state-changing transaction), but omits what triggers the event, its side effects in the protocol, or return format details.

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

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

Extremely concise at two sentences with zero redundancy. Information is front-loaded with the critical 'Event emitted' classification first, though brevity comes at the cost of domain context.

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

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

Given the complexity of the vault protocol (evident from 90+ siblings including margin trading, swaps, and liquidations), the description is insufficient. It should explain that 'reserved amount' relates to collateral reservation for leveraged positions, and when this event typically fires.

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% description coverage (token as Ethereum address, amount as uint256 string). The description adds no parameter semantics, but baseline 3 is appropriate since the schema fully documents both required fields.

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 clarifies this tool subscribes to contract events via log filters, distinguishing it from function-call siblings (e.g., increasePosition vs IncreasePosition). However, it fails to explain what 'reserved amount' means in this DeFi vault context or what the event signifies semantically.

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 provided on when to monitor this event versus related siblings like DecreaseReservedAmount, nor when to use this instead of querying reservedAmounts directly. No prerequisites or filtering advice is included.

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

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

No annotations provided, so description carries full burden. It indicates this is a read/subscription operation ('Subscribe via log filters'), but omits critical blockchain-specific behaviors such as block confirmation requirements, polling intervals, rate limits, or whether the subscription is persistent versus one-time.

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

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

Extremely brief at two sentences. While no words are wasted, the extreme brevity leaves significant gaps in context. Structure is appropriately front-loaded with the event classification, but insufficient detail is provided for the complexity of blockchain event subscription.

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

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

Given zero annotations, no output schema, and the complexity of DeFi event monitoring, the description is inadequate. It fails to explain the event's business logic (USDG mechanics), return data structure, or expected latency characteristics essential for blockchain tool selection.

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% description coverage (token as Ethereum address, amount as uint256), establishing baseline of 3. The description adds no semantic context about what these parameters filter (e.g., that 'token' specifies which asset's USDG amount increased, or that 'amount' is the specific value to filter by).

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?

Identifies the tool as an event subscription mechanism ('Event emitted by the contract. Subscribe via log filters'), but fails to explain what the IncreaseUsdgAmount event represents (e.g., minting of USDG stablecoin) or when it is emitted. Does not differentiate from sibling event tools like IncreasePoolAmount or DecreaseUsdgAmount.

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

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

Provides no guidance on when to use this tool versus alternatives like DecreaseUsdgAmount, nor does it specify whether this is for historical log retrieval or real-time streaming. No prerequisites or contextual conditions are mentioned.

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

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

With no annotations provided, the description carries the full burden. It explicitly states 'Write function' (mutation), warns about access control modifiers, and notes 'No return value'. This covers safety profile and side effects adequately, though it omits revert conditions (e.g., if called twice).

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 efficiently structured: function signature for quick scanning, write classification, access control warning, and return value status. The parameter list in sentence one is redundant with schema but aids readability without excessive verbosity.

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?

Adequate for a 6-parameter initialization function with no output schema. It covers the critical safety warning (access control) and operation type. However, given the complexity of DeFi vault initialization, it should mention this is typically single-use or refer to the 'isInitialized' sibling for state checking.

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%, documenting all 6 parameters as Ethereum addresses or uint256 strings. The description lists parameters but adds no semantic context beyond types (e.g., what '_usdg' represents or how '_fundingRateFactor' affects the protocol), meeting the baseline for high schema coverage.

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

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

The description lists the specific contract addresses and parameters being initialized (router, usdg, priceFeed, fee factors), distinguishing this as the core contract setup function among the many operational siblings (buyUSDG, sellUSDG, etc.). While 'Calls initialize' restates the name, the parameter enumeration clarifies the scope.

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

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

It warns about access control restrictions ('onlyOwner') and advises checking contract source for modifiers, implying authorization requirements. However, it fails to state this is likely a one-time initialization (given sibling 'isInitialized' exists) or that it must be called before operational functions.

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

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

With no annotations provided, the description carries the full burden and successfully discloses key behavioral traits: it confirms the read-only nature ('does not modify contract state'), access restrictions ('Unrestricted'), and return value ('bool'). This adequately covers the safety and operational profile of the contract call.

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 four short, information-dense sentences covering function invocation, mutability, access control, and return type. Every sentence earns its place with no redundant or wasted words.

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

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

For a simple state-query tool with no parameters and no output schema, the description is complete. It compensates for the missing output schema by explicitly stating 'Returns bool', providing sufficient information for an agent to understand the tool's contract.

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 contains zero parameters, which establishes a baseline score of 4 per the evaluation criteria. The description correctly implies no arguments are needed by simply stating 'Calls inManagerMode()' without mentioning inputs.

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

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

The description clearly identifies the action ('Calls inManagerMode()') and return type ('Returns bool'), distinguishing it from sibling setter functions like 'setInManagerMode'. While it doesn't explain the business logic of 'manager mode' itself, it sufficiently identifies the specific contract function being invoked.

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 access control guidance ('Unrestricted — any address can call'), implying when the tool can be used (without authentication). However, it lacks explicit guidance on when to prefer this over related tools like 'isManager' or 'setInManagerMode'.

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

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

Without annotations, the description effectively carries the safety disclosure burden by explicitly stating 'Read-only — does not modify contract state' and 'Unrestricted — any address can call this read function'. It also compensates for the missing output schema by noting 'Returns bool', though it omits what true/false values signify semantically.

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 optimally concise with four discrete, front-loaded clauses covering function purpose, mutability, permissions, and return type. Every clause provides distinct information with no redundancy or filler 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?

For a simple getter with no output schema, the description adequately covers the return type (bool) and operational constraints. It is missing only the semantic interpretation of the boolean return value (what true vs false means regarding liquidation restrictions) to be fully complete.

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

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

With zero parameters, the baseline score applies. The description confirms no inputs are required by showing empty parentheses in 'Calls inPrivateLiquidationMode()', which aligns with the empty input schema. No additional parameter semantics are needed or provided.

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

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

The description identifies this as a read-only call to check the private liquidation mode state and distinguishes it from sibling setter functions like setInPrivateLiquidationMode. However, it relies on the function name rather than explaining the business concept (e.g., 'Checks if liquidations are restricted to authorized addresses'), which limits clarity for users unfamiliar with the contract.

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

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

The description implies usage through 'Read-only' and 'Unrestricted' labels, signaling this is for checking state without permissions. However, it lacks explicit guidance on when to use this versus the liquidation tools (e.g., 'Check this before calling liquidatePosition to verify you have access').

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