uniswap-mcp

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

With no annotations provided, the description carries full disclosure burden effectively. It explicitly states 'Write function', warns about access control restrictions (onlyOwner), mandates ETH value attachment, and documents the return value (amountOut uint256) despite the absence of an output schema. This covers safety-critical behavioral traits.

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 dense sentences follow a logical progression: function signature → ETH requirement → access control warning → return value. No filler content, though the function signature syntax is slightly technical. Information is front-loaded with critical constraints early.

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 basic invocation given the complexity: it covers return values (missing from schema) and safety warnings. However, it omits DeFi-critical context like explaining that 'amountOutMinimum' is slippage protection, how 'path' encodes multiple token addresses, or deadline timestamp format, which are necessary for correct parameter construction.

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

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

Schema coverage is 100% but minimal (only field names listed). The description expands by documenting the full tuple structure with types (path: string, recipient: string, etc.) and crucially adds the ETH transaction value requirement—a behavioral parameter not captured in the input schema. This compensates well for the schema's brevity.

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 calls exactInput and requires ETH, but relies heavily on the function name itself ('Calls exactInput'). It fails to distinguish from sibling 'exactInputSingle' (single-hop vs multi-hop swaps) or explain the high-level purpose (token swapping), leaving semantic gaps for an AI selecting between similar swap 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?

Provides critical usage constraints—'Requires ETH value to be sent' and 'Check contract source for modifier requirements'—which prevent failed transactions. However, it lacks guidance on when to choose this over 'exactInputSingle' or 'exactOutput', leaving the agent without selection criteria among the swap variants.

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

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

With no annotations, the description carries the full burden and succeeds in disclosing key behavioral traits: ETH value requirement, access control risks ('onlyOwner'), write-function nature, and return value ('amountOut'). It does not mention failure modes or slippage protection semantics.

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

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

Efficiently packs the function signature, ETH requirement, access control warning, and return value into four sentences. The density is appropriate for a low-level contract interaction, though leading with the raw signature is slightly opaque.

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 Uniswap V3 swaps and lack of annotations, the description covers essential safety warnings (ETH, access control) and return values. However, it omits sibling differentiation and detailed explanations of swap mechanics (e.g., deadline enforcement, price limits), leaving gaps for an agent trying to select or configure the tool.

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

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

Schema coverage is marked 100%, establishing a baseline of 3. The description lists all nested parameter names with types (e.g., 'tokenIn: string'), but adds no semantic explanations for complex fields like 'sqrtPriceLimitX96' or 'amountOutMinimum' (slippage). It meets but does not exceed the schema's descriptive burden.

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 tautological 'Calls exactInputSingle' but implies token swapping through the parameter list (tokenIn, tokenOut). However, it fails to explicitly state the high-level purpose (e.g., 'swaps tokens') or distinguish this single-hop variant from the multi-hop 'exactInput' sibling.

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 operational prerequisites ('Requires ETH value to be sent', 'Check contract source for modifier requirements') and notes it is a 'Write function'. However, it lacks guidance on when to choose this over siblings like 'exactInput' (multi-hop) or 'exactOutputSingle' (different trade direction).

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

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

Excellent disclosure given zero annotations: explicitly states 'Write function' (mutation), warns of 'access control restrictions (e.g. onlyOwner)', notes the ETH value requirement, and specifies the return value 'amountIn (uint256)' despite the absence of an output schema.

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

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

Information density is high with no wasted sentences, but the structure is slightly awkward—mixing a function signature style opening with prose bullet points. The functional syntax 'Calls exactOutput(params...)' is somewhat redundant with the tool name.

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

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

Given the complexity of a DeFi router call with nested parameters, no annotations, and no output schema, the description adequately covers the gaps by disclosing the return type, ETH requirements, and permission risks that would otherwise be missing.

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

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

While the input schema has 100% coverage of the top-level 'params' object, the description adds significant value by unpacking the nested tuple fields and explicitly typing them (path: string, recipient: string, etc.), which the schema buries in a single string description.

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

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

The description identifies this as a 'Write function' and lists parameter fields (amountOut, amountInMaximum, path) that strongly imply a token swap where exact output is specified, distinguishing it from the 'exactInput' sibling. However, opening with 'Calls exactOutput' is slightly tautological, and it could explicitly state 'swap' for absolute clarity.

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

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

Provides critical prerequisites ('Requires ETH value to be sent', 'Check contract source for modifier requirements'), but lacks explicit guidance distinguishing when to use exactOutput vs exactInput or exactOutputSingle vs this multi-hop variant.

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: declares it a 'Write function' with access control risks, specifies ETH value requirements, and documents the return value 'amountIn (uint256)' despite the absence of an output schema. This covers mutation safety, prerequisites, and outputs.

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 pack the function signature, behavioral warnings (ETH/access), and return value. Every clause earns its place, though the first sentence is structurally heavy with the inline parameter object.

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?

Excellent coverage for a complex 8-parameter swap function with no annotations or output schema. Compensates by documenting return values, side effects (ETH transfer), authorization risks, and all parameter semantics.

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 describes the tuple fields at 100% coverage (baseline 3), the description adds value by specifying types (string) for each field and formatting them into a clear function signature structure, aiding comprehension of the nested object structure.

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 documents the specific function signature with all 8 nested parameters (tokenIn, tokenOut, fee, etc.), implying a token swap operation where exact output is specified. It distinguishes from siblings like exactInput by parameter names (amountOut vs amountIn) and structure, though it could explicitly state 'swaps tokens' for absolute clarity.

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

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

Provides critical technical prerequisites: 'Requires ETH value to be sent' and warns about access control restrictions (onlyOwner). However, it lacks explicit guidance on when to choose this over exactInputSingle (when you know the output amount vs input amount) or the batch exactOutput variant.

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

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

With no annotations provided, the description carries the full burden and successfully discloses key behavioral traits: read-only nature (no state modification), permissionless access (any address), and return type (address). It omits potential revert conditions or gas considerations.

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

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

Four short sentences with zero waste. Front-loaded with the operation (Calls factory), followed by safety properties (Read-only, Unrestricted), and return value (Returns address). Each clause earns its place.

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

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

For a simple view function with no parameters, no output schema, and no annotations, the description is adequately complete. Minor gap: it does not specify that the returned address is the Uniswap V3 Factory contract, which would contextualize the 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?

The tool has zero parameters, triggering the baseline score of 4 per the evaluation rules. The schema is empty and requires no additional semantic clarification.

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 factory() and returns an address, which distinguishes it from transactional siblings like exactInput or sweepToken. However, 'Calls factory()' is slightly circular with the tool name; stating 'Retrieves the factory contract address' would be stronger.

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 implies safe usage via 'Read-only' and 'Unrestricted', it lacks explicit guidance on when to call this (e.g., to verify pool creation permissions) versus alternatives. It does not reference sibling tools or specific use cases.

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

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

With no annotations provided, the description carries full disclosure burden and delivers: explicitly states 'Write function' (mutation), warns of access control restrictions, notes ETH requirement, and documents return type (bytes[]) despite no output schema being present.

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?

Dense single sentence packs critical safety information (ETH requirement, write nature, access controls) upfront. Each clause earns its place: mutation warning, permission risk, and return value documentation are all essential for a blockchain transaction tool.

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 mutation tool without output schema, the description adequately covers return values (bytes[]), authentication risks, and ETH requirements. Minor gap: could mention atomic batching behavior expected of multicall patterns, but safety coverage is complete.

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

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

Schema coverage is 100% with good parameter description ('bytes[] (hex-encoded bytes, 0x-prefixed)'). The description adds the TypeScript-style signature 'data: string[]' which clarifies the expected JSON input format, but doesn't significantly expand on the schema's 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?

States it calls multicall with a data array and requires ETH, but 'Calls multicall' is somewhat tautological. It distinguishes itself from swap siblings (exactInput, etc.) by mentioning the data parameter and ETH requirement, though it doesn't explain the batching behavior inherent to multicall patterns.

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 operational prerequisites (ETH value required, check contract source for onlyOwner/modifier restrictions), but lacks explicit guidance on when to choose multicall versus individual swap functions like exactInputSingle or exactOutput.

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 delivers well: explicitly states 'Write function,' warns about potential access control (onlyOwner), notes the ETH value requirement, and clarifies 'No return value.' This covers the essential 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?

Four sentences with zero waste: (1) function identification, (2) ETH requirement, (3) write nature + auth warning, (4) return value. Each sentence provides distinct, essential information. Front-loaded with the function signature and critical safety warning.

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 zero-parameter write function. Explicitly covers return value (compensating for missing output schema), transaction requirements (ETH), and authorization risks. Minor gap: does not explain what specifically gets refunded (excess ETH from previous operations), which would help situate it among the swap-heavy sibling tools.

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

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

Input schema contains zero parameters. Per the calibration rules, zero-parameter tools baseline at 4. The description does not need to compensate for missing schema documentation, and the sentence about requiring ETH value effectively describes the transaction context rather than input parameters.

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 calling refundETH() and specifies ETH as the involved resource. While 'Calls refundETH()' slightly restates the tool name, it immediately adds critical context about ETH requirements and write behavior. It implicitly distinguishes from swap siblings (exactInput, etc.) by focusing on refund semantics, though it could more explicitly state the business purpose (refunding excess ETH).

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 constraints: 'Requires ETH value to be sent' and 'Check contract source for modifier requirements.' However, it lacks workflow context—critical given siblings like exactInput/multicall—failing to explain *when* to call this (e.g., 'use after multicall swaps to retrieve excess ETH') versus alternatives like sweepToken.

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

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

Excellent disclosure given no annotations: declares it a write function, requires ETH value transfer, warns of potential access control restrictions (onlyOwner), and confirms no return value. Covers the critical behavioral traits an agent needs for safe invocation.

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

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

Four efficient sentences with no wasted words. Critical information (ETH requirement, write nature, access control) is front-loaded. The function signature in the first sentence is somewhat redundant with the schema but serves to fix parameter order.

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

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

Adequate for a contract call tool with complete schema: covers ETH handling, mutation warnings, and return behavior. However, gaps remain regarding what selfPermit accomplishes (gasless token approval via signature) and specific failure modes or side effects beyond the generic 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?

With 100% schema description coverage, the baseline is 3. The description lists parameters in the function signature but adds no semantic context beyond the schema (e.g., doesn't explain that v/r/s are ECDSA signature components or that deadline is an expiration timestamp).

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

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

The description states the tool calls the specific selfPermit function with its parameter signature, clearly identifying it as a write operation. It distinguishes from siblings (selfPermitAllowed, selfPermitIfNecessary) by listing the exact parameters (v,r,s signatures vs. allowed variant patterns), though it could better explain the high-level purpose (executing ERC20 permits).

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

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

Provides implicit guidance by noting ETH requirements and access control checks, but lacks explicit comparison to sibling alternatives like 'use selfPermitIfNecessary when approval amount is uncertain' or clear prerequisites beyond 'check contract source'.

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 any annotations, the description carries the full disclosure burden and succeeds: it states this is a write function, warns about potential access control restrictions (onlyOwner), notes the ETH value requirement, and confirms no return value. This gives the agent necessary context about side effects and prerequisites.

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

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

Five sentences with the first being wasted on signature repetition. The remaining sentences are dense and valuable, but the structure is not optimally front-loaded (critical ETH requirement follows the tautology). No verbose fluff, but not maximally efficient.

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

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

For a complex Ethereum contract interaction, the description covers operational safety (ETH, access control) but omits domain context (what constitutes a 'permit' and why one uses it). Given the complexity of EIP-2612 permits, this functional context gap limits 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?

With 100% schema description coverage (detailed types for all 6 parameters), the schema adequately documents inputs. The description does not add semantic context (e.g., that v/r/s comprise an ECDSA signature) beyond the type strings already in the schema, warranting the baseline score.

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

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

The description opens with a tautology ('Calls selfPermitAllowed...') that merely restates the function signature. While it identifies this as a 'Write function,' it fails to explain what 'self permit allowed' actually achieves (EIP-2612 style permit for token allowances) or how it differs from siblings like `selfPermit` or `selfPermitAllowedIfNecessary`.

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 warnings (requires ETH value, access control restrictions, check modifiers), which help prevent misuse. However, lacks explicit guidance on when to choose this over related permit functions in the sibling list, leaving the selection criteria ambiguous.

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 disclosure burden and succeeds in conveying three critical behavioral traits: (1) ETH must be sent with the transaction, (2) access control restrictions may apply (e.g., onlyOwner), and (3) there is no return value. It loses a point for not describing the side effect (token approval state change) or what 'ifNecessary' evaluates.

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 five sentences long. The first sentence is wasted space (repeating the function name and parameter types already evident in the schema). The remaining sentences are efficient and front-loaded with critical ETH and access control warnings. Structure would improve by removing the signature list.

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

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

Given the lack of annotations and output schema, the description provides essential safety context (ETH requirement, access control, no return value) that prevents misuse. However, it is incomplete regarding the specific functional domain (ERC20 permits) and the conditional logic implied by 'IfNecessary', leaving agents to infer purpose from parameter names (v, r, s).

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 (each parameter is typed in the schema), establishing a baseline of 3. The description lists parameters in the opening sentence but adds no semantic meaning beyond the schema (e.g., it doesn't explain that v/r/s are signature components or that nonce prevents replay attacks).

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

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

The description identifies the function as a 'Write function' and notes the ETH value requirement, which provides some purpose. However, it opens with a tautological 'Calls selfPermitAllowedIfNecessary...' that merely restates the name with parameter types. It fails to explain what the function actually does (EIP-2612 permit for token approvals) or how it differs from sibling tools like 'selfPermit' or 'selfPermitAllowed'.

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

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

It provides a prerequisite ('Check contract source for modifier requirements before calling') but offers no guidance on when to choose this specific permit variant over siblings (e.g., 'selfPermitIfNecessary'). There is no explanation of the 'IfNecessary' conditional logic or the 'Allowed' semantics despite these being distinguishing features in the name.

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 in disclosing key behavioral traits: ETH requirement, write nature, access control risks, and lack of return value. These are critical safety properties for blockchain transactions not inferable from the schema.

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

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

Five efficient sentences with no fluff. The opening function signature is slightly redundant with the schema but serves as a quick reference. Safety-critical information (ETH, access control, return value) is front-loaded appropriately.

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

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

Given 100% schema coverage and disclosure of critical execution properties (ETH, write, no return), the description meets minimum viability. However, it lacks domain context explaining EIP-2612 permit semantics or the gas-optimization purpose of 'if necessary' 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?

With 100% schema description coverage, the schema adequately documents types (bytes32, uint8, addresses). The description lists parameters but doesn't semantically group them (e.g., explaining v/r/s are signature components or that deadline is for signature expiry), though at this coverage level 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 requiring ETH and specifies it handles token permits via signature parameters (v, r, s). However, it doesn't explain what 'IfNecessary' means—the conditional logic that distinguishes this from the 'selfPermit' sibling—leaving agents unclear on selection criteria.

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 ETH requirements, it provides no guidance on when to use this versus 'selfPermit', 'selfPermitAllowed', or 'selfPermitAllowedIfNecessary'. The critical distinction (conditional vs unconditional permit) is undocumented.

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. Effectively discloses three key behaviors: ETH value requirement (unusual for token transfers), write/mutation nature, access control risks, and lack of return value. This gives the agent necessary context for safe invocation.

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

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

Four sentences with efficient structure: signature first, then ETH requirement (critical), then security warning, then return value. Every sentence provides unique value. Slight redundancy between signature and schema, but frontloading the call pattern is acceptable.

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 blockchain complexity and no output schema, description adequately covers security-critical aspects (ETH, access control) and hints at failure modes (modifier restrictions). Missing only business logic context (what sweeping means) and minimum amount revert behavior.

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 (baseline 3). The description repeats the parameter types in the function signature but adds no semantic depth—e.g., it doesn't clarify that amountMinimum prevents slippage/failed sweeps or that recipient receives the swept 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?

Clearly identifies this as a write function requiring ETH value and lists the specific contract parameters. Avoids tautology by adding critical ETH requirement detail. However, it doesn't explain what 'sweeping' means (collecting residual tokens) or how it differs from sweepTokenWithFee.

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 security guidance about access control restrictions (onlyOwner) and advises checking contract modifiers. However, lacks explicit comparison to sibling sweepTokenWithFee or guidance on when to use this versus other token transfer methods.

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

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

Excellent disclosure given no annotations: explicitly states 'Write function' (mutating), warns about access control restrictions, notes 'Requires ETH value to be sent', and clarifies 'No return value'. Covers authorization needs, transaction value requirements, and state-change nature that would normally be in annotations.

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

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

Five sentences, all high-value: function signature (clarity), ETH requirement (critical), write/access control (safety), check source (due diligence), return value (output expectation). No waste, logical flow from what it is to how to use it safely.

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?

Comprehensive for a smart contract tool: covers function behavior, transaction value requirements, authorization risks, and return values. Given 5 parameters with full schema coverage and no output schema, the description is nearly complete. Minor gap: could explain what 'sweeping' means (collecting residual tokens) for agents unfamiliar with DEX terminology.

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

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

With 100% schema description coverage (addresses with 0x-prefix notation, uint256 decimal string formats), the schema fully documents parameter syntax. The description lists parameters in the function signature but adds no additional semantic context beyond the schema's technical specifications. Baseline 3 appropriate when schema does heavy lifting.

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

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

The description clearly identifies this as a token sweep operation with fee parameters, distinguishing it from sibling 'sweepToken' by explicitly listing the feeBips and feeRecipient parameters. However, it assumes familiarity with DeFi 'sweep' terminology without explaining that this collects residual tokens from the contract.

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

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

Provides critical prerequisites: 'Requires ETH value to be sent with the transaction' and warns about 'access control restrictions (e.g. onlyOwner)'. Advises checking contract source for modifiers. Missing explicit comparison to when to use 'sweepToken' vs this fee variant, though the fee parameters imply the distinction.

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 disclosure burden. It successfully communicates three key behavioral traits: that it is a write/mutating operation, that access control restrictions may exist (e.g., onlyOwner), and that there is no return value. This covers the essential safety and execution profile.

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

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

The description is three sentences and appropriately compact. The first sentence is somewhat wasteful (repeating the signature already evident in the schema), but the access control warning and return value disclosure efficiently deliver critical information 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?

Given the specialized DeFi context, the description is minimally viable. It covers basic contract call metadata (write nature, access control, return value) but lacks domain-specific context about flash swaps, callback mechanics, or the relationship between this function and the swap router. With full schema coverage and no output schema, it meets basic requirements but misses critical architectural 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%, so the baseline is 3. The description lists the parameter names and types in the first sentence but adds no semantic meaning beyond the schema (e.g., it doesn't explain that amount0Delta represents the change in token0 balance or that negative values indicate amounts owed). It meets the baseline without adding 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 identifies this as a 'Write function' and lists parameters, which adds slight value beyond the tautological 'Calls uniswapV3SwapCallback'. However, it fails to explain what the callback actually does (settling swap debts) or how it fits into the Uniswap V3 swap lifecycle, 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?

The description warns to 'Check contract source for modifier requirements' but provides no guidance on when to use this tool versus siblings like exactInput or exactOutput. Critically, it fails to mention that this is an internal callback typically invoked by pools during swaps, not a direct user entry point.

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 any annotations, the description carries full disclosure burden effectively. It states the write/mutating nature, warns of potential access control restrictions ('onlyOwner'), and confirms 'No return value.' The ETH requirement warning is critical behavioral context not inferable from the schema.

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

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

Four concise sentences each deliver distinct value: function signature identification, ETH transaction requirement, write/auth classification, and return value declaration. No redundant fluff, though sentences 3-4 could potentially be combined without loss.

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 contract write function with no output schema, the description adequately covers operational safety (access control, ETH requirement) and return behavior. It misses high-level domain context (relationship to WETH9 token contract) but provides sufficient tactical information for invocation.

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

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

Schema description coverage is 100% (recipient: Ethereum address, amountMinimum: uint256 as decimal string), establishing baseline 3. The description lists parameters in the function signature but adds no semantic explanation beyond the schema (e.g., what 'amountMinimum' conceptually represents as a minimum output guard).

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 specific contract function being invoked (unwrapWETH9) with its exact parameter signature, and explicitly labels it as a 'Write function.' However, it slightly restates the tool name ('Calls unwrapWETH9') without fully explaining the semantic concept of unwrapping (converting WETH to ETH) or differentiating from sibling 'unwrapWETH9WithFee.'

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 clear operational prerequisites: 'Requires ETH value to be sent with the transaction' and warns to 'Check contract source for modifier requirements before calling.' While it doesn't explicitly name alternatives like unwrapWETH9WithFee, it gives concrete safety guidance necessary for invoking the tool correctly.

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

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

With no annotations provided, the description carries significant weight. It successfully discloses that this is a write function, requires ETH value to be sent, may have access control restrictions (onlyOwner), and has no return value. This provides solid safety-critical context for a smart contract interaction, though it omits specific failure modes or fee calculation 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 opening sentence wastes space with tautological function signature repetition that duplicates information already present in the tool name and schema. However, subsequent sentences are dense and valuable, efficiently covering ETH requirements, access control warnings, and return value status.

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 4-parameter blockchain mutation with no annotations, the description covers essential execution mechanics (access control, ETH requirement) but lacks semantic completeness. It omits explanation of the core business logic (WETH unwrapping), the fee mechanism implications, and does not contrast with the sibling non-fee variant.

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% (all 4 parameters have type descriptions). The description merely lists parameters with their types in the first sentence, offering no additional semantic context (e.g., explaining that feeBips represents basis points or amountMinimum is a slippage protection floor). Baseline 3 is appropriate since the schema carries the full descriptive load.

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

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

The description opens with tautology ('Calls unwrapWETH9WithFee...') restating the tool name. While it identifies this as a write function requiring ETH value, it fails to explain what 'unwrapping WETH9' actually means (converting WETH to ETH) and does not explicitly distinguish when to use this versus the sibling 'unwrapWETH9' (without fee).

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 one concrete usage constraint ('Requires ETH value to be sent with the transaction'), which is valuable for blockchain contexts. However, it lacks explicit guidance on when to prefer this over 'unwrapWETH9' or other withdrawal methods, and does not clarify the purpose of the fee parameters versus the non-fee alternative.

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 disclosure burden. It successfully communicates read-only safety ('does not modify contract state'), permission requirements ('any address can call'), and the return value. No contradictions present.

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 using em-dashes for structured detail. No redundant phrases; each clause adds distinct information (function name, mutability, permissions, return type). Front-loaded with the call 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?

Appropriately complete for a zero-parameter getter function. Compensates for missing output schema by explicitly stating 'Returns address.' With no annotations and low complexity, the description covers necessary behavioral and return-value 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?

Input schema contains zero parameters, warranting a baseline score of 4. The description correctly implies no inputs are required by focusing solely on the call behavior and return 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?

States the specific action (Calls WETH9()) and return type (address). Distinguishes from mutating sibling tools like unwrapWETH9 and sweepToken by identifying itself as a read function. Slight circularity with tool name prevents a 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?

Provides implicit guidance by noting the function is 'Read-only' and 'Unrestricted,' suggesting it can be called safely without permissions. However, lacks explicit guidance on when to retrieve the WETH9 address versus using other token-related siblings.

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