stargate-mcp

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 this is a 'Write function,' warns about access control restrictions, and clarifies 'No return value.' Could improve by describing the state change (what happens to the chain path when activated) and 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 filler. Front-loaded with technical signature and safety warnings (write access, permissions). Slightly redundant to list parameter types when schema is present, but acceptable for blockchain contract documentation conventions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 write function with no output schema: covers mutation nature, authorization requirements, and return void. Missing functional explanation of what 'activation' accomplishes and its relationship to the pool/chain lifecycle. Sibling differentiation would improve completeness.

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

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

Schema coverage is 100% with clear type annotations (uint256, uint16). The description lists the parameters but adds no semantic context (e.g., that _dstChainId represents the destination blockchain identifier or _dstPoolId the target liquidity pool). Baseline score appropriate given schema completeness.

Input schemas describe structure but not intent. Descriptions should explain 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 resource (chain path) and action (activate/write) clearly, including the specific function signature. However, it assumes domain knowledge about what 'activating' a chain path entails rather than explaining the business outcome (enabling cross-chain liquidity flow).

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 guidance on access control restrictions (e.g., onlyOwner), advising users to check contract modifiers before calling. However, it fails to distinguish when to use this versus sibling tools like createChainPath or creditChainPath.

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 discloses critical traits: it is a write function, may have onlyOwner restrictions, and has no return value. Missing details on side effects like LP token minting, token transfers from sender, or events emitted.

Agents need to know what a tool does to the 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 of appropriate length, but the opening 'Calls addLiquidity...' wastes space restating the tool name. The subsequent sentences about access control and return values earn their 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?

Acknowledges the lack of return value, compensating for no output schema. However, for a DeFi mutation tool, it omits critical context such as requiring token approvals, slippage risks, or what happens to the deposited funds.

Complex tools with many parameters or behaviors need more documentation. 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 parameter names and types but adds no semantic meaning beyond the schema (e.g., does not explain what '_amountLD' represents, or that '_to' receives LP tokens).

Input schemas describe structure but not intent. Descriptions should explain 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 addLiquidity' which is tautological, but clarifies it is a 'Write function'. It does not explain what 'adding liquidity' means (e.g., depositing tokens into a pool) or how it differs from sibling operations like createPool 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?

Provides a prerequisite warning to 'Check contract source for modifier requirements before calling' due to potential access control restrictions. However, it lacks guidance on when to use this versus alternatives (e.g., addLiquidity vs createPool) or conditions for failure.

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 communicates the read-only nature ('does not modify contract state'), access control ('any address can call'), and return type ('Returns address'). It misses specifics on gas characteristics or error states, but covers the essential safety profile for a simple getter.

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

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

The description is appropriately brief at four sentences, though the first sentence ('Calls bridge()') is wasted space that merely restates the tool name. The remaining three sentences efficiently convey the read-only status, permissionlessness, and return value.

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

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

Given the absence of parameters and output schema, the description adequately covers the essential behavioral context for a simple getter function. It explains what the function does (returns address), its side effects (none), and its access pattern (unrestricted), which is sufficient for an AI agent to invoke this correctly among the many state-modifying siblings.

Complex tools with many parameters or behaviors need more documentation. 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, establishing a baseline score of 4. No parameter documentation is required or provided in the description, which is appropriate for this tool.

Input schemas describe structure but not intent. Descriptions should explain 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 function that returns an address, distinguishing it from state-modifying siblings like 'addLiquidity' or 'swap'. However, it wastes the first sentence on tautology ('Calls bridge()') and fails to specify what 'bridge' refers to (e.g., the bridge contract address) within the protocol context.

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

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

The description provides permission guidance ('Unrestricted — any address can call this read function'), which helps distinguish it from permissioned functions. However, it lacks explicit guidance on when to use this versus other read-only address getters like 'factory' or 'owner', or what the returned address is used for.

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 succeeds well: it discloses the read-only nature, states that any address can call it ('Unrestricted'), and documents the return object structure with specific fields. It does not mention error behaviors (e.g., return values on cache miss), preventing a perfect score.

Agents need to know what a tool does to the 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 containing behavioral traits, return types, and access controls. The '[DISCOVERY]' prefix appears to be metadata noise, and listing the parameter types is redundant given the schema, but overall there is minimal 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?

Despite lacking an output schema and annotations, the description adequately compensates by documenting the return object fields. For a lookup function with three parameters, the combination of schema type coverage and description-provided return structure provides sufficient context for invocation, though explaining what constitutes a 'cached swap' would improve completeness.

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

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

The input schema has 100% coverage with type descriptions (uint16, bytes, uint256), establishing a baseline of 3. The description repeats the parameter signature but does not add semantic meaning (e.g., identifying param0 as chain ID or param1 as transaction hash), which would be necessary to elevate the score given the opaque parameter names.

Input schemas describe structure but not intent. Descriptions should explain 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 lookup operation for cached swaps and specifies the return structure (token, amountLD, to, payload). It distinguishes itself from state-modifying siblings like clearCachedSwap, swap, and addLiquidity by explicitly stating 'Read-only — does not modify contract state.' However, it relies heavily on the function name to convey purpose rather than explicitly stating 'Retrieves cached swap transaction details.'

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

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

The description provides implied usage guidance through the 'Read-only' and 'Unrestricted' labels, suggesting it is safe to call without authentication or state-change concerns. However, it lacks explicit when-to-use guidance (e.g., checking cache before calling clearCachedSwap) and does not mention prerequisites like the swap having been previously cached.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an event but fails to describe what triggers it (under what conditions is a cached swap saved?), whether the subscription is persistent or one-shot, or what format/structure the returned log data will take.

Agents need to know what a tool does to the 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 efficient sentences with no redundant words. It front-loads the critical information (that this is an event) and immediately follows with the action mechanism (subscription via log filters). While terse to the point of being underspecified, there is no structural 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 an 8-parameter tool with no output schema and no annotations, the description is insufficient. It does not explain the relationship to the broader caching system evident in siblings like 'clearCachedSwap' and 'cachedSwapLookup', nor does it clarify the significance of the event parameters or return 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 (all 8 parameters have type format descriptions like 'Ethereum address, 0x-prefixed'). The description adds no semantic context about what 'amountLD', 'srcAddress', or 'payload' represent in the context of a cached swap, but baseline 3 is appropriate given the schema completeness.

Input schemas describe structure but not intent. Descriptions should explain 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 emitted by the contract' which distinguishes it from function siblings like 'swap' or 'clearCachedSwap'. However, it fails to explain what 'CachedSwapSaved' actually represents (when a swap is cached, what caching means in this context) or what semantic data the event carries.

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

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

The description mentions 'Subscribe via log filters' indicating the mechanism for usage, but provides no guidance on when to use this specific event versus other event siblings like 'OwnershipTransferred' or 'Revert', nor when to prefer listening for this event versus calling 'cachedSwapLookup'.

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 disclosure. It successfully indicates this is a write operation with potential access control requirements and explicitly states there is no return value. However, it lacks detail on what state changes occur (what gets updated in the pool?), failure modes, or side effects beyond the generic 'write' classification.

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

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

The description is three sentences long. The first sentence is wasted on tautological signature restatement rather than purpose. The remaining sentences efficiently convey safety-critical information about access control and return values. Structure is acceptable but front-loading wastes space.

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

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

Given the simple parameter schema (2 primitives, no output), the description should explain the core functional purpose (what does calling delta do to the pool?). It omits this entirely, leaving the agent unable to determine when this tool is appropriate except for the generic 'write' classification. The safety warnings are present but insufficient for functional completeness.

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

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

The input schema has 100% description coverage (uint256 and bool types are documented). The description lists the parameters by name and type in the first sentence but adds no semantic value beyond the schema (e.g., it does not explain what _fullMode controls or what the poolId represents). This meets the baseline for high schema coverage.

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

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

The description opens with a tautology ('Calls callDelta...') that merely restates the function name and parameter types without explaining what the function actually does (e.g., what is 'Delta' and why would one call it?). While it classifies the tool as a 'Write function,' it fails to describe the business outcome or distinguish this from sibling liquidity management tools.

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

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

The description provides safety warnings about access control restrictions (e.g., onlyOwner) and advises checking contract modifiers, which is useful. However, it offers no functional guidance on when to use this tool versus alternatives (e.g., when to use _fullMode true vs false), or what conditions necessitate calling this specific function.

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 adequately discloses key behavioral traits: it confirms this is a write operation (mutation), warns of potential access control failures, and explicitly states there is no return value. It appropriately flags the permissioned nature of the operation.

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

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

Four sentences efficiently convey the function signature, write classification, access control warning, and return behavior. The opening signature repetition is slightly redundant, but the warning about access control modifiers is appropriately prominent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 state-mutating blockchain function without annotations, the description covers the essential safety-critical information (permissions, write nature, no return value). It appropriately delegates parameter format details to the comprehensive schema while highlighting the critical access control considerations.

Complex tools with many parameters or behaviors need more documentation. 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 type descriptions (uint256, bytes, uint16 formats). The description lists the parameter names but does not add semantic meaning beyond the schema (e.g., explaining what '_nonce' represents in the swap lifecycle). Baseline 3 is appropriate given the schema completeness.

Input schemas describe structure but not intent. Descriptions should explain 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' that clears cached swaps, distinguishing it from the read-only sibling 'cachedSwapLookup'. While the opening sentence repeats the function name, classifying it as a write operation provides essential behavioral context.

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

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

The description provides critical prerequisite guidance by warning about access control restrictions (e.g., onlyOwner) and advising to check contract source for modifiers. However, it lacks explicit guidance on when to use this tool versus alternatives like 'retryRevert' or 'redeemLocal' for failed swaps.

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 discloses: (1) it's a write function, (2) potential access control restrictions, and (3) no return value. It appropriately flags the permission risk. However, it omits what side effects occur (e.g., does this establish a new cross-chain route? affect existing liquidity?).

Agents need to know what a tool does to the 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 wastes space restating the function signature already implicit in the tool name and explicit in the schema. However, the access control warning and return value note are efficiently placed. Length is appropriate but structure could front-load the behavioral warning over the tautology.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 blockchain mutation tool with 4 parameters and no output schema, the description provides essential safety context (write operation, permissions) but lacks operational context. It should explain what creating a chain path accomplishes (connecting source pool to destination pool across chains) and how it relates to the broader pool management workflow.

Complex tools with many parameters or behaviors need more documentation. 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 type descriptions (uint256, uint16). The description lists parameters but adds no business semantics (e.g., that _dstChainId is a LayerZero chain identifier, or that _weight represents allocation capacity between pools). Baseline 3 is appropriate given schema completeness.

Input schemas describe structure but not intent. Descriptions should explain 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' and lists the parameters, but opens with tautological 'Calls createChainPath...'. It fails to explain what a 'chain path' represents in this system (likely a cross-chain liquidity route) or how it differs from siblings like activateChainPath or setWeightForChainPath.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 important access control warnings ('may have onlyOwner restrictions') and advises checking contract modifiers, which helps determine prerequisites. However, it lacks explicit when-to-use guidance relative to siblings (e.g., when to create vs activate a path) or workflow 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 that this is a 'Write function' (state-mutating), warns about access control modifiers, and specifies the return type ('Returns address'). This covers the critical safety and behavioral traits for a blockchain interaction tool.

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

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

The three-sentence structure is efficient and logically ordered: function signature, safety warning, return value. There is no extraneous text, though the first sentence largely mirrors the schema. The critical access control information is prominently placed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 6-parameter write operation with no output schema and no annotations, the description covers the minimum: it mentions the return value (address) and access control risks. However, it omits prerequisite steps (e.g., whether the token must be pre-approved), failure modes, and the relationship between the created pool and the input token, leaving gaps in the 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% description coverage, establishing a baseline of 3. The description lists the Solidity function signature, but this largely duplicates information already present in the schema (which already specifies Solidity types like 'uint256' and 'address'). It adds no semantic depth regarding what distinguishes '_sharedDecimals' from '_localDecimals' or what '_poolId' represents.

Input schemas describe structure but not intent. Descriptions should explain 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 createPool' which is somewhat tautological, but lists the specific parameters involved. However, it fails to explain what a 'pool' represents in this DeFi context or how it differs from siblings like addLiquidity (which adds to pools) or createChainPath. It lacks the domain-specific verb+resource clarity needed to confidently select this over similar tools.

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

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

The description provides a crucial access control warning ('may have access control restrictions... onlyOwner'), implying when NOT to use it. However, it lacks explicit guidance on WHEN to use this versus alternatives like addLiquidity, or prerequisites such as token approval requirements prior to pool creation.

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 identifies this as a write operation with potential access control restrictions (onlyOwner) and notes the absence of return values. However, it omits critical blockchain-specific context such as gas implications, revert conditions, state change specifics (what exactly gets credited), or transaction finality requirements.

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

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

The description wastes space repeating the full parameter list ('_dstChainId: string, _dstPoolId: string...') which is already defined in the schema. While the warning about access control is appropriately placed, the structure could be more front-loaded by starting with the write-function warning rather than the redundant signature.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 complex blockchain mutation operation with nested objects and no output schema, the description is insufficient. It fails to explain the business logic of crediting chain paths, the protocol context (likely cross-chain liquidity), or how this operation fits into the lifecycle of chain path management. For a write function with 4 parameters including nested structures, more domain context 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% description coverage, documenting types (uint16, uint256) and structure. The description merely repeats the function signature without adding semantic context—such as explaining that _dstChainId represents the destination blockchain identifier or clarifying the relationship between credits and idealBalance in the tuple. Baseline score applies since schema is complete but description adds no value.

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

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

The description begins with 'Calls creditChainPath' which is tautological, merely restating the tool name. While it identifies this as a 'Write function,' it fails to explain what 'crediting a chain path' actually accomplishes in business terms (e.g., updating liquidity accounting, enabling cross-chain transfers) or how it differs from siblings like sendCredits or createChainPath.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 to 'Check contract source for modifier requirements,' but provides no explicit guidance on when to use this tool versus alternatives like activateChainPath or sendCredits. It lacks 'when-to-use' or 'when-not-to-use' criteria, leaving the agent without decision boundaries among the numerous sibling chain-path 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 of disclosure. It effectively communicates safety (read-only, no state modification), access control (any address can call), and return value (address), covering the essential behavioral traits for a blockchain view function.

Agents need to know what a tool does to the 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 with zero redundancy. It is front-loaded with the action (Calls factory()), followed by critical behavioral constraints (read-only, unrestricted), and concludes with the return type, earning its place efficiently.

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

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

Given the tool's simplicity (zero parameters, single return value) and lack of output schema, the description is sufficiently complete. It documents the return type (address), mutability guarantees, and access restrictions, which covers the essential context needed for a smart contract getter function.

Complex tools with many parameters or behaviors need more documentation. 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 evaluation rules, tools with no parameters receive a baseline score of 4, as there are no parameter semantics to describe beyond what the empty schema already conveys.

Input schemas describe structure but not intent. Descriptions should explain 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 factory() function and returns an address, which clearly identifies it as a getter for the factory contract address. The explicit 'Read-only' distinction effectively differentiates it from state-modifying siblings like addLiquidity, bridge, and 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 provides clear contextual guidance by stating the function is 'Read-only' (indicating when to use it for queries vs. transactions) and 'Unrestricted' (clarifying no special permissions or addresses are required), which helps the agent select it appropriately over permissioned 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?

No annotations are provided, so the description carries the full burden. It successfully discloses: (1) mutation nature ('Write function'), (2) security risks ('access control restrictions'), and (3) return value ('amountSD (uint256)') despite the absence of an output schema. Could be improved by mentioning revert conditions or side effects.

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

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

Four distinct sentences with no filler. Each conveys specific information: function signature, write nature/access control, prerequisite check, and return value. The opening function signature is slightly redundant given the schema, but overall efficiently structured.

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

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

Effectively compensates for missing annotations (disclosing write nature and safety restrictions) and missing output schema (disclosing return type). However, it lacks explanation of the domain logic (what 'redeeming' entails, what LP tokens are) and sibling differentiation, which would be expected for a complete DeFi tool description.

Complex tools with many parameters or behaviors need more documentation. 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 type information for all three parameters. The description repeats the parameter signatures but adds no semantic meaning beyond the schema (e.g., does not explain that _amountLP represents LP tokens to burn, or that _srcPoolId identifies the liquidity 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 begins with a tautology ('Calls instantRedeemLocal...') rather than explaining what the function actually does (e.g., redeeming LP tokens instantly). While it clarifies this is a 'Write function' and mentions the return value 'amountSD', it fails to distinguish from siblings like 'redeemLocal' or explain the domain concept.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 safety guidance regarding access control restrictions ('onlyOwner') and advises checking contract source before calling, which is valuable for blockchain write functions. However, it lacks guidance on when to use this versus alternatives like 'redeemLocal' or 'redeemRemote'.

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 succeeds well: it explicitly states 'Read-only — does not modify contract state,' clarifies permissionlessness ('Unrestricted'), and discloses the return type ('Returns address'). This comprehensively covers behavioral traits an agent needs to invoke safely.

Agents need to know what a tool does to the 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 waste. Critical behavioral info (readonly, unrestricted, return type) is front-loaded effectively. The initial function identification serves necessary disambiguation among siblings 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 simple state-reading function with no parameters and no output schema, the description adequately compensates by specifying the return type (address). It could improve by explicitly stating this address is the 'mint fee owner' for absolute clarity, but coverage is sufficient for correct invocation.

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

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

The input schema is empty (zero parameters) with 100% description coverage, meeting the baseline expectation. The description correctly omits parameter discussion as there are none to document, which is appropriate for this getter function.

Input schemas describe structure but not intent. Descriptions should explain 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 call to mintFeeOwner() that returns an address, which distinguishes it from state-modifying siblings like setMintFeeOwner. However, it uses the indirect phrasing 'Calls mintFeeOwner()' rather than explicitly stating 'Gets the mint fee owner address,' which would more clearly distinguish it from similar getters like protocolFeeOwner or owner.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 implicit guidance about access requirements. However, it lacks explicit when-to-use guidance distinguishing this from protocolFeeOwner or owner, or when an agent should prefer this over setMintFeeOwner.

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 the read-only nature (no state modification), access restrictions (any address can call), and return type (address). It omits potential revert conditions or gas considerations, but coverage is strong for a simple getter.

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

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

Four short sentences with zero redundancy. Each sentence delivers critical distinct information: function call, mutability, access control, and return value. Information density is optimal for a simple read function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 zero-parameter read function without output schema or annotations, the description is complete. It compensates for missing annotations by specifying read-only behavior and return type, and no further complexity requires explanation.

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

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

The tool has zero parameters and 100% schema description coverage vacuously. Per the rubric, 0 params warrants a baseline score of 4. The description correctly focuses on behavior rather than inventing parameter 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 explicitly states it 'Calls owner()' and 'Returns address', clearly identifying this as a getter for the contract owner. It distinguishes from siblings like 'mintFeeOwner', 'protocolFeeOwner' (which return different addresses), and 'transferOwnership' (which modifies 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 clear usage context by labeling it 'Read-only' (distinguishing from write operations like transferOwnership) and 'Unrestricted' (indicating no authentication needed). It doesn't explicitly contrast with similar read functions like mintFeeOwner, but the scope is clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses that parameters are indexed/filterable and mentions subscription via log filters, but omits critical behavioral details like whether this returns historical events or streams new ones, callback frequency, or connection 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?

Three sentences with zero waste: sentence 1 identifies the event type, sentence 2 highlights the indexed/filterable nature of parameters, and sentence 3 provides the subscription mechanism. Information is front-loaded and appropriately dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 an event subscription tool with complete parameter schema, the description adequately covers the subscription mechanism but lacks details about what data is returned when the event fires, duration of subscription, or error handling patterns typical for blockchain log subscriptions.

Complex tools with many parameters or behaviors need more documentation. 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 coverage, the baseline is 3. The description adds value by explicitly stating the fields are 'Indexed fields (filterable)', providing crucial semantic context about how these parameters function in log filtering beyond just being addresses.

Input schemas describe structure but not intent. Descriptions should explain 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 an event listening tool ('Event emitted by the contract', 'Subscribe via log filters'), distinguishing it from the imperative action 'transferOwnership' in the sibling list. However, it doesn't explicitly contrast when to monitor events versus when to trigger ownership changes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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' implying usage for monitoring, but lacks explicit when-to-use guidance contrasting this passive subscription with active ownership transfer tools like 'transferOwnership' or 'renounceOwnership'. No prerequisites or alternatives are named.

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

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

No annotations are provided, so the description carries the full disclosure burden. It excellently compensates by specifying mutability ('does not modify contract state'), access control ('any address can call'), and return value ('Returns address')—critical safety and usage information.

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

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

Four sentences efficiently convey: (1) function identification, (2) mutability safety, (3) access restrictions, and (4) return type. No redundancy or fluff; every clause earns its place in the risk/safety profile of a blockchain read operation.

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

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

Given zero parameters and no output schema, the tool is inherently simple. The description compensates for the missing output schema by explicitly stating 'Returns address', providing sufficient information for an agent to understand the complete operation cycle.

Complex tools with many parameters or behaviors need more documentation. 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. With no parameters to document, the baseline score applies. The description correctly omits parameter discussion since none exist, and the schema's 100% coverage (trivially) 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 explicitly states it 'Calls protocolFeeOwner()' and 'Returns address', clearly identifying this as a getter for the protocol fee owner address. It effectively distinguishes from siblings like 'setProtocolFeeOwner' (mutation) and 'owner'/'mintFeeOwner' (different state variables).

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

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

The description provides clear behavioral context ('Read-only', 'Unrestricted') that helps determine when to use this tool (for reading state without authentication). However, it does not explicitly contrast with 'setProtocolFeeOwner' or state when to prefer this over other owner-getter 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 that the operation is read-only (does not modify state), unrestricted (any address can call), and returns a specific tuple structure {_0: string, _1: string}. It could be improved by explaining what the return values represent (e.g., native fee and ZRO fee).

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

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

The description is a single dense sentence that front-loads the function signature and efficiently packs in mutability, access control, and return type information with minimal redundancy. Every clause 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?

Given the nested object parameter and lack of structured output schema, the description adequately covers the return structure manually and explains auth/mutability. However, it lacks business context about LayerZero fee quoting and omits what the return tuple fields represent (e.g., fee amounts), leaving gaps for users unfamiliar with the specific 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 has 100% description coverage, establishing a baseline of 3. The description repeats the parameter names and types in the function signature but adds no semantic meaning beyond the schema (e.g., it does not explain that _dstChainId represents the destination blockchain identifier or what _functionType values signify).

Input schemas describe structure but not intent. Descriptions should explain 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 quoteLayerZeroFee' which is tautological, but adds that it is read-only and returns specific values. However, it fails to explain what 'quoting' actually means (calculating cross-chain messaging fees) or what business purpose it serves, leaving the purpose implied by the name rather than explicitly stated.

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

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

While the description notes the function is 'Read-only' and 'Unrestricted' (indicating no authentication needed and safe to call), it provides no guidance on when to use this tool versus siblings like 'bridge' or 'swap', or that it should be called prior to bridging to estimate costs.

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: (1) financial cost (ETH required), (2) mutation type (write function), (3) authorization risks (access control restrictions), and (4) output behavior (no return value). This is strong behavioral coverage despite missing side-effect 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?

The description is relatively compact (4 sentences), but the opening function signature is redundant given the structured schema. The remaining sentences are dense with useful warnings (ETH, access control) and earn their 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 complex 7-parameter write function with nested objects and access control, the description covers transactional requirements (ETH) and permissions adequately. However, it omits business logic explanation (what 'redeeming local' means) and sibling differentiation that would be necessary for complete context.

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

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

Schema description coverage is 100%, providing type information for all 7 parameters (uint256, address, tuple fields). The description repeats the function signature but does not add semantic meaning beyond the schema (e.g., explaining that _dstChainId represents the destination blockchain or _amountLP represents liquidity pool tokens).

Input schemas describe structure but not intent. Descriptions should explain 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' and mentions ETH requirements, but opens with a tautological function signature ('Calls redeemLocal...') rather than explaining what redeeming local LP tokens actually accomplishes. It fails to distinguish from siblings like instantRedeemLocal or redeemRemote.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 that ETH must be sent with the transaction and warns about access control restrictions (onlyOwner). However, lacks explicit guidance on when to use this versus instantRedeemLocal or redeemRemote, which are important alternatives in the sibling set.

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) it's a write function, (2) it has no return value, and (3) access control restrictions may apply. However, it omits what state changes occur (which pool balances change?), potential failure modes, gas considerations, or that this is part of a LayerZero-style cross-chain messaging pattern implied by the '_srcChainId' parameter.

Agents need to know what a tool does to the 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 four sentences: function signature, write classification with access control warning, advisory to check source code, and return value declaration. There is minimal redundancy; even the signature listing serves to confirm the exact parameter order and types beyond the schema structure.

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

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

Given the complexity (8 parameters, blockchain mutation, callback pattern) and absence of annotations or output schema, the description covers the essential safety and behavioral basics. However, it lacks domain-specific context that would help an agent understand this is a callback for completing local redemptions in a cross-chain bridge protocol, and how it fits into the transaction 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, establishing a baseline of 3. The description mirrors the function signature but adds no semantic context beyond the schema—such as explaining that '_amountSD' refers to 'shared decimals', that '_srcAddress' is the remote contract address, or the relationship between source and destination pool IDs. It strictly repeats what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain 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' and lists the full function signature, confirming it performs a state mutation. However, it merely states it 'Calls redeemLocalCallback' without explaining what 'redeeming' means in this context (e.g., completing a cross-chain liquidity redemption). It also fails to distinguish this callback completion step from siblings like 'redeemLocal', 'instantRedeemLocal', or 'redeemLocalCheckOnRemote'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 critical guidance about access control restrictions (e.g., onlyOwner) and advises checking contract source for modifiers, which is essential given no annotations. However, it lacks workflow context—such as when to use this callback versus initiating a redemption with 'redeemLocal', or that this typically completes a cross-chain message flow.

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 establishes that this is a read-only subscription tool (not a transaction) via 'Event' and 'Subscribe' language, and notes the filterable indexed fields. However, it fails to explain what triggers this event, what the data represents (e.g., cross-chain redemption completion), or subscription constraints.

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

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

The description is efficiently structured in two sentences with no wasted words. It front-loads the critical classification ('Event emitted by the contract') before providing practical implementation details (filterable fields, subscription method). The information density is appropriate for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 8 parameters with complete schema coverage and no output schema, the description meets baseline requirements by identifying the tool type and filterable fields. However, for a domain-specific event (likely LayerZero/cross-chain bridge related), it lacks contextual explanation of what the event signifies (e.g., 'Emitted when local redemption is finalized') which would help the agent understand when to monitor for it.

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

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

While the schema has 100% coverage with technical types, the description adds valuable semantic context by explicitly aggregating and highlighting which fields are 'filterable' (srcAddress, nonce). This helps the agent understand which parameters are most useful for log filtering, going beyond the individual '(indexed)' tags scattered in the schema properties.

Input schemas describe structure but not intent. Descriptions should explain 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 an 'Event emitted by the contract' using specific terminology (verb 'emitted' + resource 'Event'), which effectively distinguishes it from the function sibling 'redeemLocalCallback' (camelCase) in the tool list. However, it lacks context about what 'RedeemLocal' signifies in the protocol 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?

The description provides basic usage instruction ('Subscribe via log filters') and identifies which fields are filterable (srcAddress, nonce). However, it lacks explicit guidance on when to use this event versus other similar events (like RevertRedeemLocal or CachedSwapSaved) or what conditions trigger this specific emission.

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) mutability ('Write function'), (2) access control risks ('onlyOwner'), and (3) return value ('No return value'). However, it omits what state changes occur (token transfers, burns, validations) and the cross-chain protocol mechanics.

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

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

The description is four sentences. The first sentence wastes space restating the function signature. The remaining sentences are information-dense (write status, auth warnings, return value), but the structure buries the function signature tautology at the start instead of leading with behavioral classification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 blockchain operation, the description covers basic safety concerns (write, auth, no return) and the schema covers types adequately. However, it lacks essential context about the cross-chain redemption workflow and the meaning of 'local check' vs 'remote' execution, which is critical given the sibling tool density.

Complex tools with many parameters or behaviors need more documentation. 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 hints (e.g., 'uint256, pass as decimal string'), so the baseline is 3. The description lists parameter names but adds no semantic context (e.g., what '_amountSD' represents, relationship between '_srcPoolId' and '_dstPoolId', or what '_to' receives).

Input schemas describe structure but not intent. Descriptions should explain 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 a tautological function signature that restates the tool name and parameters. It fails to explain what 'redeeming a local check on remote' actually accomplishes in business terms or how it differs from sibling tools like redeemLocal, redeemRemote, or instantRedeemLocal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 to 'Check contract source for modifier requirements' which is a prerequisite, but provides no guidance on when to use this tool versus the 40+ sibling tools (e.g., redeemLocal vs redeemRemote). No workflow context or alternatives 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 full burden and discloses critical behavioral traits: ETH value requirement ('Requires ETH value to be sent'), mutation nature ('Write function'), access control risks ('may have access control restrictions'), and return value status ('No return value'). These safety disclosures are valuable for a blockchain transaction tool.

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

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

The description is efficiently structured with four distinct sentences covering signature, ETH requirement, access control, and return value. No filler text. The function signature listing is somewhat verbose given the schema already defines parameters, but it is front-loaded and clearly formatted.

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

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

Given the complexity (8 params, nested objects, cross-chain operation) and absence of annotations/output schema, the description adequately covers safety-critical aspects (ETH, access control) but lacks business context. It does not explain the cross-chain redemption flow, what 'redeem' means in this DeFi context, or how to construct valid '_lzTxParams', leaving operational 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?

Input schema has 100% description coverage (type/format info for all 8 parameters), establishing baseline 3. The description lists the full function signature but adds no semantic meaning beyond the schema (e.g., does not explain what '_amountLP' represents versus '_minAmountLD', or the purpose of '_lzTxParams'). It neither adds nor detracts from the schema's technical 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 redeemRemote' which is tautological, but adds that it's a 'Write function' with access control. However, it fails to explain the business purpose (redeeming LP tokens across chains) or differentiate from siblings like 'redeemLocal' or 'instantRedeemLocal'. The agent cannot determine why to use 'redeemRemote' versus the local alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 to 'Check contract source for modifier requirements' but provides no guidance on when to use this tool versus the numerous sibling redemption tools (redeemLocal, instantRedeemLocal, etc.). There is no mention of prerequisites, typical workflows, or selection criteria for cross-chain vs local redemption.

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 excels: it declares it a write function, warns of irreversibility, lists specific functions that become inaccessible (adapter management, oracle configuration, emergency controls, set* functions), and notes there is no return value.

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

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

Every sentence serves critical function: function identification, access control check, irreversibility warning, specific consequence enumeration, and return value disclosure. No redundant text despite the high information density.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 high-stakes administrative function with no output schema, the description is complete. It covers preconditions (onlyOwner), irreversible effects, specific locked functionality, and return behavior—everything needed to invoke this dangerous tool safely.

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

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

The input schema has 0 parameters, which per guidelines establishes a baseline of 4. The description appropriately does not invent parameters, though the '()' in 'Calls renounceOwnership()' subtly confirms the parameterless nature.

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

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

The description explicitly states it 'Permanently and irreversibly removes all owner control from the contract,' distinguishing it from sibling transferOwnership by emphasizing the destructive nature of renouncing versus transferring ownership.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 notes access control restrictions (onlyOwner) and warns to check contract source requirements. While it doesn't explicitly name transferOwnership as the alternative, the 'DANGER' warning and explanation of permanent consequences clearly imply this should only be used for contract abandonment, not ownership changes.

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 performs well: it explicitly states ETH value is required, flags it as a write function, warns of potential onlyOwner access control, and notes 'No return value.' These are critical safety disclosures for blockchain operations.

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

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

Five sentences, zero waste. Structure is logically ordered: function signature → ETH requirement → access control warning → prerequisite check → return value disclosure. Every sentence earns its place with critical invocation 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 this is a blockchain write operation with no output schema, the description adequately covers safety-critical invocation requirements (ETH, access control). It could be improved by explaining the retry mechanism or cross-chain context, but the operational essentials are present.

Complex tools with many parameters or behaviors need more documentation. 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 (types and formats), establishing a baseline of 3. The description lists parameters in the opening sentence but adds no semantic context beyond the schema (e.g., explaining that _nonce refers to the failed transaction's nonce or that _srcChainId identifies the origin chain).

Input schemas describe structure but not intent. Descriptions should explain 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 retryRevert(...)' which is somewhat tautological, though it clarifies this is a write function requiring ETH. It fails to explain what 'retrying a revert' means in business terms (e.g., retrying a failed cross-chain bridge message), and doesn't distinguish from similar siblings like revertRedeemLocal or clearCachedSwap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 warns to 'Check contract source for modifier requirements,' it provides no guidance on when to use this tool versus alternatives like revertLookup or revertRedeemLocal. No prerequisites or conditions for retry eligibility are mentioned.

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

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

No annotations are provided, so the description carries full burden. It discloses that this is for subscription via log filters, but provides no information about what triggers the event, what the return data represents, or any side effects of the subscription.

Agents need to know what a tool does to the 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 redundant words. However, the brevity crosses into under-specification given the lack of domain context. The key information is front-loaded but insufficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 blockchain bridge operations and the critical nature of revert events, the description is inadequate. It fails to explain what operation was reverted, why the event fires, or how to interpret the parameters beyond their types.

Complex tools with many parameters or behaviors need more documentation. 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 type definitions (uint256, uint16, bytes). The description adds no semantic context for what 'bridgeFunctionType,' 'srcAddress,' or 'nonce' represent in the context of a revert event. With high schema coverage, this meets the baseline of 3.

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

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

Identifies the tool relates to an 'Event emitted by the contract' and mentions 'Subscribe via log filters,' indicating it's for event subscription. However, it fails to explain what specifically a 'Revert' event signifies (e.g., transaction failure, bridge rollback) or under what conditions it is emitted, leaving the core purpose vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 'retryRevert' or 'revertRedeemLocal.' No mention of prerequisites for subscription or when this event fires versus other events in the bridge 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?

With no annotations provided, the description carries the full burden of behavioral disclosure and succeeds reasonably well. It explicitly states the operation is read-only, unrestricted (no auth required), and returns bytes. However, it misses what the returned bytes represent (e.g., encoded error data, transaction receipt) and doesn't mention gas implications for blockchain calls.

Agents need to know what a tool does to the 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 four sentences, but the first sentence ('[DISCOVERY] Calls revertLookup...') wastes space with tautology and auto-generated noise. The remaining three sentences efficiently convey access control, mutability, and return type, earning their place.

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

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

Given the complexity of the blockchain/bridge domain (evident from siblings like bridge, swapRemote, redeemLocal), the description is insufficient. It fails to explain the domain concept of 'revert' in this context, what specific data is being looked up, or how to interpret the opaque bytes return value. For a 3-parameter state-reading tool with full schema coverage, this is below minimum viable completeness.

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

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

Schema coverage is 100%, establishing a baseline of 3. The description lists parameters in the function signature but adds no semantic meaning beyond the schema's type information (e.g., it doesn't explain that param0 likely represents a chain ID, param1 a transaction hash, or param2 an amount, which would be essential for correct invocation).

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

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

The opening statement 'Calls revertLookup' is tautological, merely restating the tool name. While it mentions the function is read-only and returns bytes, it fails to explain WHAT the tool looks up (e.g., failed transaction details, revert reasons) or how it differs from siblings like retryRevert or revertRedeemLocal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 siblings like retryRevert, revertRedeemLocal, and clearCachedSwap, the description should specify this is for querying revert state versus executing recovery actions, but it provides no such 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 full disclosure burden and succeeds on critical safety aspects: it explicitly states the ETH value requirement, identifies it as a write function with potential onlyOwner restrictions, and notes the lack of return value. However, it doesn't explain the side effects (e.g., what state changes occur when a redeem is reverted).

Agents need to know what a tool does to the 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 opening sentence simply repeats the function signature and parameter types already documented in the schema, wasting space. The remaining sentences are efficient and front-loaded with critical warnings (ETH requirement, access control), but the redundant signature reduces overall information density.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 5-parameter mutation function with nested objects, the description covers technical mechanics (ETH, access control, return value) but omits the business logic explanation. Given the complexity and lack of output schema, it should explain what constitutes a valid revert scenario (e.g., failed cross-chain messages).

Complex tools with many parameters or behaviors need more documentation. 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%, establishing a baseline of 3. The description lists parameters in the signature but adds no semantic meaning beyond the schema (e.g., it doesn't explain that _nonce likely refers to the original transaction nonce being reverted, or that _lzTxParams controls LayerZero gas settings).

Input schemas describe structure but not intent. Descriptions should explain 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 a tautological function signature ('Calls revertRedeemLocal...') but partially recovers by classifying it as a 'Write function.' However, it fails to explain what 'reverting a redeem' actually means in business terms (e.g., canceling a pending redemption) or how it differs from siblings like 'instantRedeemLocal' or 'redeemLocalCallback.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 to 'Check contract source for modifier requirements,' but provides no guidance on when to use this tool versus alternatives like 'redeemLocal' or 'redeemRemote.' It mentions access control risks but doesn't specify prerequisites (e.g., ownership of the original transaction).

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 that this is an event subscription via log filters and identifies which fields are filterable, but fails to clarify whether this sets up a persistent subscription or queries historical logs, what triggers the event, or what data structure is 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 extremely terse at only two sentences, with no redundant words. However, given the complexity of the domain (cross-chain bridging with 8 parameters) and lack of annotations, this brevity comes at the cost of necessary context, making it too concise rather than appropriately sized.

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

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

For a tool with 8 required parameters in a complex blockchain domain and no annotations or output schema, the description is insufficient. It lacks explanation of the event's business meaning, the conditions under which it fires, the return format of the subscription, and how it relates to the broader redemption flow.

Complex tools with many parameters or behaviors need more documentation. 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 (bytes, uint256) and format instructions. The description mentions that nonce and srcAddress are indexed/filterable, but this merely duplicates the '(indexed)' notation already present in the schema parameter descriptions, adding no new semantic value beyond the structured data.

Input schemas describe structure but not intent. Descriptions should explain 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 emitted by the contract and mentions indexed fields, but fails to explain what 'RevertRedeemLocal' actually signifies in business terms (reverting a local redeem operation). It does not distinguish this event subscription tool from its sibling action tool 'revertRedeemLocal', leaving ambiguity about which tool to invoke for what 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?

There is no guidance on when to use this tool versus alternatives. Given the presence of similar sibling tools like 'revertRedeemLocal', 'redeemLocal', and 'RedeemLocalCallback', the description should explicitly state when to subscribe to this event versus calling the redeem function directly, but it provides no such comparison.

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

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

With no annotations provided, the description carries the full burden and successfully discloses critical behavioral traits: ETH value requirement, write/mutation nature, potential access control restrictions (onlyOwner), and lack of return value. This gives the agent necessary safety context.

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

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

Five sentences totaling essential information without excessive verbosity. The opening tautology ('Calls sendCredits') is the only structural weakness; otherwise efficiently front-loaded with safety-critical information (ETH requirement, access control) before implementation details.

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

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

Adequate for a basic contract write operation but lacks conceptual context: it doesn't explain the cross-chain credit transfer mechanism, what constitutes a 'credit' in this protocol, or the relationship between pool IDs and chain IDs. Given the complexity implied by 45+ sibling tools, this conceptual gap is significant.

Complex tools with many parameters or behaviors need more documentation. 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%, establishing a baseline of 3. The description lists parameter names in the function signature but adds no semantic meaning beyond the schema's type definitions (e.g., doesn't explain that _dstChainId represents the destination LayerZero chain ID or what the refund address is for).

Input schemas describe structure but not intent. Descriptions should explain 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 a tautological 'Calls sendCredits(...)' but recovers by identifying it as a write function requiring ETH. However, it fails to explain what 'credits' represent (liquidity units, token balances?) or how this differs from siblings like 'bridge', 'swap', or 'creditChainPath'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 warning ('Check contract source for modifier requirements') but offers no guidance on when to use this tool versus alternatives like 'bridge' or 'redeemRemote'. No mention of typical use cases or prerequisites beyond access control checks.

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 discloses key behavioral traits: it identifies the operation as a write/mutation, warns about potential access control modifiers, and explicitly states 'No return value' (compensating for the lack of output schema). It could improve by describing the state change effects.

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

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

Three sentences with zero waste. Critical information is front-loaded: the write nature and access control risks appear immediately. The structure moves from signature to behavioral warning to return value disclosure—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?

Adequate for a 2-parameter administrative setter. The description covers the essential safety and behavioral context (write operation, access control, no return value) that the schema and missing annotations don't provide. Minor gap: doesn't explain the functional impact of changing bridge/factory addresses within the protocol ecosystem.

Complex tools with many parameters or behaviors need more documentation. 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 (both parameters documented as Ethereum addresses). The description mentions the parameter names and types but doesn't add semantic context beyond what's in the schema (e.g., what the bridge or factory addresses represent functionally). Baseline 3 is appropriate given schema completeness.

Input schemas describe structure but not intent. Descriptions should explain 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' that operates on bridge and factory addresses, distinguishing it from read-only siblings like 'factory' and 'owner'. While it opens with a slightly tautological 'Calls setBridgeAndFactory', it quickly clarifies the operation type and target resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 warns about access control restrictions (e.g., onlyOwner) and instructs to 'Check contract source for modifier requirements before calling'. This provides critical prerequisite guidance for an administrative function, though it doesn't name alternative tools (likely because this is a unique configuration setter).

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 key behavioral traits: it explicitly states this is a write function, warns about access control modifiers requiring contract source review, and notes the absence of return values. However, it omits side effects or state change 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?

The description is compact but inefficiently structured. The first sentence wastes space restating the function signature already evident from the tool name and schema. The access control warning and return value note are appropriately concise.

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

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

Minimally viable for a blockchain contract wrapper. Covers technical execution context (write operation, access control, return value) but omits domain context—what delta parameters control, their impact on pool behavior, or how they relate to the protocol's fee/swap mechanics. No output schema exists, but the description compensates by noting 'No return value'.

Complex tools with many parameters or behaviors need more documentation. 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 type information for all 6 parameters. The description repeats the parameter list but adds no semantic meaning (e.g., what '_swapDeltaBP' represents, valid ranges, or relationship between the boolean flags). Baseline 3 is appropriate given schema completeness.

Input schemas describe structure but not intent. Descriptions should explain 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 operation as a 'Write function' and lists parameters, but fails to explain what 'delta parameters' actually do or what business effect this call has. The opening 'Calls setDeltaParam...' is tautological, merely restating the tool name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 regarding access control restrictions (onlyOwner), but lacks guidance on when to use this versus sibling configuration tools like setSwapStop, setFees, or setWeightForChainPath. Does not explain prerequisites or typical usage patterns.

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. It successfully identifies this as a write operation, warns about potential onlyOwner restrictions, and explicitly states 'No return value.' It could be improved by describing what happens to the existing fee library (replacement vs. update) and whether this change affects existing pool operations immediately.

Agents need to know what a tool does to the 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. Critical information (write nature, access control, return value) is front-loaded. The warning to 'Check contract source' is appropriately cautionary without being verbose. Structure is logical: signature → behavior warning → auth requirements → return value.

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

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

For a 2-parameter blockchain write operation, the description adequately covers safety concerns (access control) and return characteristics. However, given the complexity of fee libraries in DeFi contexts and the absence of an output schema, it should explain what a 'fee library' contract does functionally (e.g., calculates fee rates) to help the agent understand the operation's business logic impact.

Complex tools with many parameters or behaviors need more documentation. 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 (uint256, address types documented). The description repeats the parameter names and types in the first sentence but adds no semantic context beyond the schema—such as what the feeLibraryAddr contract should implement or whether poolId refers to an existing pool. Baseline score appropriate given schema completeness.

Input schemas describe structure but not intent. Descriptions should explain 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 write operation that sets a fee library for a specific pool (via _poolId). It uses specific technical verbs ('Calls setFeeLibrary') and identifies the resource being modified. However, it doesn't distinguish from similar sibling tools like 'setFees' or 'setDeltaParam', leaving ambiguity about whether this configures fee logic vs. fee amounts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 critical access control guidance ('may have access control restrictions (e.g. onlyOwner)') and advises checking contract modifiers before calling. This implies usage constraints. However, it lacks explicit comparison to sibling tools—particularly 'setFees'—to clarify when to set the library contract address versus when to configure fee parameters directly.

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 identifies this as a write function, warns about potential access control restrictions, and explicitly states there is no return value. This covers the essential safety and behavioral context needed for a blockchain mutation tool.

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

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

Four well-structured sentences each serve distinct purposes: function signature, write nature/access warning, prerequisite check instruction, and return value disclosure. No significant waste, though 'Calls setFees' slightly duplicates the tool name. The technical specificity is appropriate for the smart contract domain.

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

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

Given the simple 2-parameter schema with complete coverage and no output schema, the description adequately covers the essential context: function purpose, access control risks, and return behavior. It could be improved by explaining the '_mintFeeBP' parameter semantics (basis points) and valid ranges, but it meets the minimum viable threshold for a setter function.

Complex tools with many parameters or behaviors need more documentation. 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 (uint256 decimal strings), establishing a baseline of 3. The description mirrors the parameter names and types but adds minimal semantic meaning beyond the schema—it does not explain what '_mintFeeBP' represents (e.g., basis points) or valid value ranges, which would have been helpful given the technical blockchain context.

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

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

The description clearly identifies this as a write operation that sets fees using a pool ID and mint fee basis points parameter. While 'Calls setFees' is slightly tautological with the tool name, it specifies the exact contract function signature and distinguishes from siblings like setMintFeeOwner or setFeeLibrary by focusing on fee values rather than ownership or library configuration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 modifier requirements, which effectively communicates prerequisites for safe usage. However, it does not explicitly differentiate from similar fee-related siblings like setDeltaParam or setFeeLibrary regarding when to use each specific fee configuration 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: (1) it's a write/mutating operation, (2) potential access control modifiers exist, and (3) explicitly states 'No return value.' Missing only specific 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?

Four sentences efficiently structured: function signature, write classification with risk warning, prerequisite check instruction, and return value disclosure. No redundant words, though the first sentence restates the tool name which is slightly tautological but acceptable for clarity on function signatures.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 setter with no output schema, the description is complete. It covers the operational effect, safety warnings (access control), and return behavior. Only minor gap is not explicitly linking to the `mintFeeOwner` getter sibling to complete the usage context.

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

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

Schema coverage is 100% with the parameter described as 'address (Ethereum address, 0x-prefixed).' The description mentions '_owner: string' but adds no semantic meaning beyond the schema's technical specification, which is acceptable given 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 setter for the mint fee owner and explicitly labels it as a 'Write function.' However, it doesn't differentiate from the sibling tool `setProtocolFeeOwner` or clarify its relationship to the likely getter `mintFeeOwner`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 guidance on access control prerequisites ('may have access control restrictions (e.g. onlyOwner)') and instructs to check contract source requirements before calling. Could be improved by mentioning the corresponding getter or when to use vs `setProtocolFeeOwner`.

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 three critical traits: (1) it's a write/mutation operation, (2) it likely requires specific permissions (onlyOwner), and (3) it returns no value. This covers the essential safety and behavioral context needed for a blockchain state-changing function.

Agents need to know what a tool does to the 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 four sentences: function signature, write classification with risk warning, prerequisite check, and return value disclosure. There is no redundant or filler content; every clause provides actionable information for an AI agent invoking a blockchain write operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 single-parameter setter function with no output schema, the description adequately covers the essential context: the mutation nature, access control risks, and absence of return values. While it could enhance completeness by mentioning the relationship to protocol fee withdrawal (per sibling withdrawProtocolFee), it provides sufficient context 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 input schema has 100% coverage with a clear description of '_owner' as an Ethereum address. The description references the parameter ('_owner: string') but does not add semantic meaning beyond the schema (e.g., what this owner controls, validation beyond format). With high schema coverage, the 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 this as a 'Write function' that sets the protocol fee owner, which clarifies the resource being modified. While it opens with the somewhat circular 'Calls setProtocolFeeOwner', the inclusion of 'Write function' and the specific parameter context provides clarity. It does not explicitly distinguish from siblings like setMintFeeOwner or transferOwnership, preventing a score of 5.

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

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

The description provides implicit usage guidance by warning about 'access control restrictions (e.g. onlyOwner)' and advising to 'Check contract source for modifier requirements before calling.' However, it lacks explicit comparisons to sibling tools (e.g., when to use this vs setMintFeeOwner) or clear prerequisites beyond the access control hint.

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. It successfully identifies this as a 'Write function' (mutation), warns of access control restrictions, and explicitly states 'No return value'. This covers critical safety and behavioral traits. It could be improved by explaining whether the stop is reversible or its impact on pending operations.

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

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

The description is efficiently structured with four short sentences. It front-loads the function signature (slightly redundant with schema but acceptable), followed by operation type, access control warning, and return value. Every sentence conveys distinct information with no filler.

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

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

Given this is a 2-parameter write operation with no output schema, the description adequately covers safety prerequisites (access control) and return behavior. However, it omits the business effect of the operation (pool pause mechanism) and lacks context about reversibility or side effects on existing liquidity, leaving gaps for a state-changing function.

Complex tools with many parameters or behaviors need more documentation. 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 (uint256 and bool documented), establishing a baseline of 3. The description mirrors the parameter names and types but adds no additional semantic context—such as explaining that _poolId identifies a specific liquidity pool or that _swapStop=true halts trading operations.

Input schemas describe structure but not intent. Descriptions should explain 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 setSwapStop' which is partially tautological, though it adds parameter signatures. It identifies this as a write operation, distinguishing it from read-only siblings like 'factory' or 'owner'. However, it fails to explain the business purpose—what does stopping swaps actually do (pause trading)?—forcing reliance on the function 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 safety-critical guidance about access control restrictions ('onlyOwner') and advises checking contract source for modifiers, which implies when to use (when caller has owner permissions). However, it lacks guidance on when to prefer this over sibling tools like 'swap' or 'addLiquidity', or when stopping swaps is appropriate versus other pool management actions.

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

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

With no annotations provided, the description carries the full burden and successfully discloses mutability ('Write function'), authorization requirements, and return value status ('No return value'). It fails to explain functional side effects (e.g., how weight affects routing/liquidity allocation) 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 opening sentence is wasted on tautology. The remaining three sentences efficiently convey critical information (write operation, access control, return value), but the structure suffers from the redundant lead. Every sentence after the first 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 contract write function with no output schema—it covers safety-critical aspects (mutability, auth). However, given the complexity of cross-chain routing implied by sibling tools (bridge, swapRemote), it lacks domain context explaining what 'weight' controls in the protocol's routing logic.

Complex tools with many parameters or behaviors need more documentation. 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 (typing uint256/uint16), establishing a baseline of 3. The description adds no semantic value beyond repeating parameter names in the signature string—it does not clarify that _dstChainId refers to a destination chain identifier or explain what the _weight value represents functionally (e.g., allocation priority).

Input schemas describe structure but not intent. Descriptions should explain 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 for setting weights on chain paths, but opens with a tautological restatement of the function signature ('Calls setWeightForChainPath...'). It does not differentiate from siblings like createChainPath or activateChainPath regarding when to configure weights versus creating or activating paths.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 crucial access control guidance ('may have access control restrictions (e.g. onlyOwner)') and advises checking contract modifiers, which is relevant for blockchain write functions. However, it lacks explicit when-to-use guidance versus alternative configuration tools or prerequisites beyond ownership checks.

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. It successfully communicates that this is a write function requiring ETH value transfer, warns about potential onlyOwner restrictions, and explicitly states there is no return value. This covers key safety and behavioral traits necessary for invocation.

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

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

Three dense sentences convey essential information without fluff. The function signature, while lengthy, serves as quick reference. Critical warnings (ETH requirement, access control) are front-loaded in the second sentence. No redundant or wasted language.

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

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

Given the complexity (9 parameters, nested objects, cross-chain mechanics) and lack of output schema, the description covers minimum requirements: ETH requirement, write nature, and null return. However, it omits cross-chain delivery mechanics, failure modes, and slippage behavior explanation expected for this complexity tier.

Complex tools with many parameters or behaviors need more documentation. 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 (type specifications for all 9 parameters), establishing baseline 3. The description mirrors the function signature but adds no semantic context beyond types—failing to explain business logic like _minAmountLD representing slippage protection or _lzTxParams controlling cross-chain gas.

Input schemas describe structure but not intent. Descriptions should explain 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 swap(...)' which is somewhat tautological, merely restating the tool name. While the parameter signature hints at cross-chain functionality (via _dstChainId and _lzTxParams), it never explicitly states what 'swap' means in this context (cross-chain liquidity transfer) or distinguishes this tool from siblings like 'bridge' or 'swapRemote'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 critical operational constraints—specifically that ETH value must be sent and that access control restrictions may apply. However, it lacks guidance on when to use this tool versus alternatives like 'bridge' or 'redeemLocal', 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. It successfully discloses that this is a write function with potential onlyOwner restrictions and explicitly states 'No return value'. However, it omits what state changes occur (e.g., token transfers, pool updates) or cross-chain behavioral specifics.

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

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

The description wastes the opening sentence on a verbose function signature redundant with the schema. The remaining three sentences are efficient, but the front-loaded parameter dump violates the 'every sentence earns its place' standard.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 cross-chain operation with 9 parameters and nested objects, the description is under-specified. It lacks explanation of the cross-chain mechanism, relationship between source/destination pools, prerequisites, or effects beyond the access control warning.

Complex tools with many parameters or behaviors need more documentation. 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%, establishing a baseline of 3. The description lists parameters in the opening sentence but adds no semantic context beyond the schema (e.g., explaining that _s contains fee structures or what _payload represents functionally).

Input schemas describe structure but not intent. Descriptions should explain 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 tautological function signature ('Calls swapRemote...') that restates the tool name and parameter types without explaining what the tool actually does (e.g., finalizing a cross-chain swap). It fails to distinguish from siblings like 'swap' or 'bridge'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 warns about access control restrictions and advises checking contract source, it provides no guidance on when to use swapRemote versus alternatives like 'swap' or 'redeemRemote', 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?

No annotations provided, so description carries full burden. Discloses write function nature, access control restrictions, two-step pattern mechanics, and absence of return value. Could be improved by mentioning revert conditions or gas implications, but covers critical behavioral traits well.

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

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

Six sentences each earning their place: signature declaration, write/access warning, prerequisite check, core purpose, workflow explanation, and return value disclosure. Logical flow from mechanics to prerequisites to outcomes. No redundancy despite technical detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 blockchain mutation with complex ownership semantics, description adequately covers the critical domain-specific context (onlyOwner restrictions, two-step pattern, acceptance requirement) that schema cannot express. No output schema exists, so return value disclosure is appropriate.

Complex tools with many parameters or behaviors need more documentation. 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% description coverage ('address (Ethereum address, 0x-prefixed)'), establishing baseline 3. Description references 'newOwner' in context of two-step pattern (must call acceptOwnership), adding workflow context, but does not significantly expand on address format or validation beyond schema.

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

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

Clear specific verb ('Transfers') + resource ('ownership') + scope ('to a new address'). Distinguishes from sibling 'renounceOwnership' by emphasizing transfer to new address vs abandonment, and mentions the two-step acceptance pattern unique to this operation.

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

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

Explicitly states access control prerequisites ('may have access control restrictions e.g. onlyOwner'), advises checking contract source for modifiers before calling, and explains the two-step workflow requiring the new owner to call acceptOwnership(), establishing clear when-to-use and prerequisite 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 full disclosure burden and successfully notes: (1) write/mutation behavior, (2) access control risks, and (3) absence of return value. Could improve by describing the actual asset transfer (fees moving to `_to` address) but covers critical safety 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?

Extremely efficient three-sentence structure: signature documentation, behavioral warnings, and return value declaration. No redundant words; information density is high with zero filler content.

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

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

Appropriately complete for a DeFi contract write operation. Compensates for missing output schema by explicitly stating 'No return value'. Covers access control and write nature which are essential given zero annotations. Minor gap in not describing the token transfer mechanics.

Complex tools with many parameters or behaviors need more documentation. 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 structured data already documents types (uint256, address). The description lists parameters with types but adds no semantic context beyond the schema (e.g., does not clarify that `_poolId` identifies the source pool or that `_to` receives the withdrawn fees). 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 identifies this as a write function for withdrawing mint fees, distinguishing it from sibling `withdrawProtocolFee` through the specific function name reference. While it opens with a slightly tautological 'Calls withdrawMintFee', the subsequent context about access control and write behavior clarifies the intent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 warns about access control restrictions (e.g., onlyOwner) and advises checking contract source for modifier requirements, providing crucial prerequisite guidance for blockchain interactions. Lacks explicit comparison to `withdrawProtocolFee` but effectively communicates authorization requirements.

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 this is a 'Write function', warns about potential 'access control restrictions', and notes 'No return value', which helps the agent understand the mutation risk and response handling.

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

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

The description is appropriately brief at four sentences, front-loading the function signature and write nature; while the opening sentence 'Calls withdrawProtocolFee' is redundant given the tool name, the remaining sentences efficiently convey critical access control and return value 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?

While the description covers technical safety aspects like access controls and the absence of return values, it lacks domain context about what protocol fees are, when they are available for withdrawal, or the financial implications, leaving gaps for a complete understanding of the tool's role in the DeFi system.

Complex tools with many parameters or behaviors need more documentation. 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 _poolId as uint256 and _to as an Ethereum address; the description merely repeats the parameter names and types without adding semantic context about what the pool ID represents or the purpose of the destination address, meeting the baseline expectation.

Input schemas describe structure but not intent. Descriptions should explain 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 'Calls withdrawProtocolFee' which largely restates the tool name, and while it identifies this as a 'Write function', it fails to explain what protocol fees are being withdrawn or from where, missing the business logic clarity needed to distinguish this from the sibling withdrawMintFee tool.

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

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

It provides implicit usage guidance by warning about 'access control restrictions (e.g. onlyOwner)' and advising to check contract sources, but it does not explicitly state when to use this tool versus the similar withdrawMintFee sibling or prerequisites like fee accumulation.

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