DeFiMind

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

With no annotations, the description fully covers behavioral traits: values are denominated in opp-token units per BalancerImpLoss convention, fee income is not attributed, and the RPC URL is not persisted. These details add crucial context beyond the schema.

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

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

The description is a single paragraph of three sentences, efficient but slightly dense. It front-loads the primary purpose and then adds caveats. No wasted words, but could be better structured with separation.

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

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

Given 9 parameters, no output schema, and no annotations, the description covers purpose, denomination convention, fee limitation, and RPC privacy. It lacks output format hints, but the key behavioral aspects are addressed, making it fairly 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%, so baseline is 3. The description adds meaningful context for rpc_url (privacy and BYO-RPC) and clarifies pool_type restriction. This elevates it above baseline.

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

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

The description clearly states the tool analyzes a 2-asset Balancer weighted-pool LP position's PnL and decomposes impermanent loss. It specifies the formula convention and distinguishes from siblings like AnalyzeStableswapLP by naming Balancer specifically.

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

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

No explicit guidance on when to use this tool over alternatives. While it states 'This tool accepts only balancer', it does not compare to siblings like SimulateBalancerMove or AnalyzePosition. The context is implicit but not actionable.

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 the tool returns current value, hold value, IL percentage, fee income, net PnL, real APR, and a diagnosis label. However, it does not disclose any side effects, authentication needs, rate limits, or potential failures beyond implying it reads live pool state.

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 paragraph that efficiently conveys purpose, decomposition, and outputs without extraneous words. It is front-loaded with the main action and could be slightly more structured but remains concise.

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

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

Given the 11 parameters (6 required) and no output schema, the description is reasonably complete. It lists all output components and explains the purpose. While it does not detail return types or units, it covers the essential context for an agent to understand the tool's functionality.

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

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

Schema description coverage is 100%, so the schema itself fully describes all 11 parameters. The description adds overall purpose and output context but does not provide additional semantic detail for individual parameters beyond what the schema already offers.

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

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

The description clearly states the tool's function: analyzing why a Uniswap V2 or V3 LP position is gaining or losing money. It specifies the key decompositions (impermanent loss, fees, net result) and lists the outputs. This distinguishes it from sibling tools like AnalyzeBalancerLP and AnalyzeStableswapLP by explicitly mentioning Uniswap.

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

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

The description implies usage for Uniswap LP positions but does not explicitly state when to use this tool versus alternatives like AnalyzeBalancerLP or AnalyzeStableswapLP. It lacks guidance on when not to use or specific prerequisites, providing only implied 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, the description carries full burden and discloses key behaviors: IL formula used, valuation in peg-numeraire, fee attribution not included, and unreachable regime returning None on certain metrics. It does not mention any destructive actions or auth needs, but as a read-only analysis tool, this is sufficient.

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

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

The description is a single paragraph that efficiently conveys multiple pieces of information: purpose, formula, caveats, and return behaviors. It is concise but could be slightly more structured for easier scanning.

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 complexity and absence of output schema, the description covers the purpose, method, and notable behaviors well. It mentions return fields (il_percentage, net_pnl, real_apr) but only in the context of the unreachable regime, lacking a full list of output fields. Overall, it is fairly complete for an analysis tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds some context (e.g., peg-numeraire, fee exclusion) but does not provide additional parameter-level semantics beyond what the schema already offers.

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

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

The description clearly states the tool analyzes a 2-asset Curve-style Stableswap LP position's PnL using the amplified-invariant IL formula. It specifies the resource (Stableswap LP), action (analyze PnL), and method (amplified-invariant IL formula), distinguishing it from sibling tools like AnalyzeBalancerLP or AnalyzePosition.

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 context for when to use this tool, mentioning small depegs and high A values, and lists limitations such as fee exclusion and unreachable regime. However, it does not explicitly state when not to use it or name alternatives, which would be helpful given multiple sibling tools.

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

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

The description discloses that some depeg levels are physically unreachable at high A and explains the resulting null fields. It also states the RPC URL is not stored/logged. With no annotations provided, the description adequately covers 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?

The description is mostly concise and front-loaded with the main purpose. Slight redundancy (e.g., default depeg levels repeated in both description and schema) prevents a perfect score.

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

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

Given 9 parameters and no output schema, the description covers inputs, constraints, and behavioral quirks well. However, the output format is not described (beyond mentioning fields that may be null), leaving some ambiguity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining default depeg levels, the effect of compare_v2, and unreachable scenario behavior, which goes beyond the schema's basic parameter descriptions.

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

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

The description clearly states the tool quantifies IL exposure to a stablecoin depeg for a 2-asset Curve Stableswap LP, lists default depeg levels, and mentions the closed-form computation. It is distinct from sibling tools like AnalyzeStableswapLP by focusing specifically on depeg risk assessment.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The description implies usage for depeg risk on 2-asset stableswap pools, but does not mention alternatives or prerequisites (e.g., knowing the pool's amplification coefficient). Minimal guidance beyond scope.

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

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

Discloses key behaviors: reads once, persists nothing, logs nothing, uses BYO-RPC. Lacks details on error handling or edge cases, but sufficient for a read-only tool with no annotations.

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

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

Three efficient sentences: functionality+output, usage guidance, scope+privacy. No wasted words.

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

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

Covers main aspects: input, output, use case, privacy. Without output schema, describing the wire format helps. Could add output field details but fine overall.

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% parameter descriptions. The tool description adds minimal new info beyond schema (e.g., supported pool types already in enum). Baseline 3 is appropriate.

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

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

The description clearly states the tool reads on-chain state and returns a serialized State Twin JSON with content_hash. It specifies supported pool types and differentiates from sibling tools that analyze or simulate.

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

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

Explicitly says to use this for pulling a single twin then running counterfactuals client-side. Does not mention when not to use or alternatives, but context is clear given sibling tools.

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

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

With no annotations, the description carries the full burden. It transparently explains that V3 returns null for the max trade size field due to unimplemented math. It lists the return components (spot vs execution price, slippage percentage, etc.) without hiding limitations. Authentication, rate limits, or side effects are not mentioned, but the tool appears read-only.

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

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

The description is two sentences, front-loaded with the primary purpose. It is concise and free of unnecessary details, every sentence earns its place.

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

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

Given 10 parameters, no output schema, and no annotations, the description provides a solid overview of return values and V2/V3 behavioral differences. It does not cover error scenarios or constraints like batching limits, but the core use case is well explained.

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 adds context about the V2/V3 distinction and the meaning of return fields, but does not significantly enhance parameter-level meaning beyond what the schema already provides.

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

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

The description clearly states the tool's purpose: 'Calculate slippage and price-impact decomposition for a proposed swap on a Uniswap V2 or V3 pool.' It specifies the resource (swap pool), action (calculate decomposition), and distinguishes from sibling tools that analyze LP positions or detect risks.

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 indicates that the tool is for Uniswap V2/V3 pools and notes that for V3 pools, the max trade size field is null. However, it lacks explicit guidance on when to use this tool versus alternatives like SimulatePriceMove or CheckPoolHealth. The context provided is clear but not exhaustive.

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

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

With no annotations, the description carries full burden. It discloses that num_swaps and fee_accrual_rate_recent are V2-only and that V3 returns null for those, plus that single-block snapshots return null for LP-concentration and swap metrics. No contradictions with annotations.

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

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

The description is a single paragraph that front-loads the purpose and lists key metrics. While somewhat lengthy, every sentence adds value. It could be more structured but remains reasonably 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?

Despite no output schema, the description lists the returned metrics (TVL, reserves, fees, LP concentration, swap activity) and explains null cases for V3 and single-block snapshots. For a tool with 6 parameters and complex behavior, this is sufficiently complete.

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

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

Schema coverage is 100% with detailed parameter descriptions. The tool description adds context about V2-only behavior and null returns, but does not significantly enhance parameter semantics beyond what the schema already provides.

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

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

The description clearly states the tool snapshots pool-level health metrics for Uniswap V2 or V3 pools, answering a specific question ('is this a pool I would deposit into?') and distinguishes from sibling tools focused on other protocols like Balancer or Curve.

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 specifies when to use the tool (for V2/V3 pools) and clarifies scope (pool-level, not position-level). It notes V2-only fields and null behavior for V3, providing clear context, though it does not explicitly contrast with sibling tools or state when not to use.

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

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

No annotations provided, so description carries full burden. It discloses behavior: three checks, composition over CheckPoolHealth, V2-only signal, non-persistence of rpc_url, and output format. This is transparent for a read-only analysis 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?

Three sentences that are front-loaded with purpose, followed by composition and V2/V3 distinction. Every sentence adds value with no redundancy or fluff.

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

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

Given complexity (7 params, no output schema), description explains signals, risk level, and V2/V3 differences. Lacks explicit return structure but provides sufficient context for an agent to understand usage.

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

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

Schema coverage is 100% with detailed parameter descriptions. The tool description adds overall context but does not significantly enhance parameter meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool detects rug-pull signals on a Uniswap V2 or V3 pool via three specific threshold checks. It distinguishes from sibling tools like CheckPoolHealth by noting composition and from others by specifying Uniswap focus.

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

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

Description implies usage context (detecting rug-pull signals) but does not explicitly state when to use this tool versus alternatives or provide exclusions. No guidance on when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It explains that the tool reads live pool state via RPC, does not persist URLs, and returns projected values. It does not explicitly state it is read-only, but the simulation nature implies no state mutation. Good disclosure of 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?

The description is two sentences with no waste. The first sentence states the primary purpose, and the second details the outputs. It is front-loaded and every sentence earns its place.

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

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

For a tool with 8 parameters, no output schema, and moderate complexity, the description covers the key aspects: what it does, return values (value, IL, % change), and the RPC interaction. It lacks details on error handling or the numeraire, but it is largely complete given the 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%, so baseline is 3. The description adds little param-specific meaning beyond the schema; it mentions shock magnitude and pool weights but does not elaborate on individual parameters like rpc_url or chain_id. The schema already documents these thoroughly.

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

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

The description clearly states the tool projects a 2-asset Balancer weighted-pool LP position's value under a hypothetical price change. It specifies the action (project), resource (LP position value), and scope (Balancer weighted-pool, 2-asset), effectively distinguishing it from siblings like SimulateStableswapMove.

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

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

The description implies it is used for Balancer weighted-pools and hypothetical price changes. It does not explicitly state when not to use or mention alternatives, but the sibling tools provide differentiation. A clear context is given, but lack of exclusion criteria prevents a 5.

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

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

With no annotations, the description must disclose behavioral traits. It explains that the simulation uses current pool state, does not model fees (always null), and requires parameters like price_change_pct > -1.0. However, it does not explicitly state that the operation is read-only or non-destructive, which is important for safe agent use.

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

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

The description is a single, concise paragraph with front-loaded purpose. Every sentence serves a purpose: stating the action, clarifying the baseline, giving an example, listing key returns, and noting fee absence. No waste.

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

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

Given 10 parameters (4 required), no output schema, and moderate complexity (batch option, V2/V3 distinction), the description covers essential aspects: current state projection, fee exclusion, batch batch capability, and key return values. It lacks explicit output structure (fields/types), but the listed returns provide sufficient guidance.

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

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

Schema coverage is 100%, so baseline is 3. The description adds little beyond the schema: it reiterates constraints (e.g., price_change_pct > -1.0) already in the schema, and notes fee projection is null (a return, not parameter). No new meaning is added for 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 clearly states the tool simulates the value of a Uniswap V2 or V3 LP position under a hypothetical price change from the current pool state. It uses specific verbs ('project') and identifies the resource, distinguishing it from sibling tools like `SimulateBalancerMove` and `SimulateStableswapMove`.

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

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

The description implies usage for Uniswap V2/V3 LP positions via the mention of pool_type and the context from sibling names, but does not explicitly state when to use this tool over alternatives (e.g., 'use for Uniswap, not Balancer'). The guidance is clear within context but lacks explicit when-not or alternative references.

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

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

No annotations provided, so description carries full burden. It discloses that the shock multiplies current alpha by (1+price_change_pct) and that large shocks may return null for some fields. Adds behavioral context beyond a simple 'simulate' statement.

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

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

Two sentences, no fluff. First sentence states purpose, second explains the shock mechanism and edge case. Every sentence earns its place.

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

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

Given complexity (8 params, no output schema), the description covers purpose, shock mechanism, null behavior, and units. Lacks explicit return structure but is sufficient for an agent to understand the tool's scope.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the shock formula and null return condition, providing context beyond the schema's individual parameter descriptions.

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

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

The description clearly states the tool projects a 2-asset Curve-style Stableswap LP position's value at a hypothetical depeg from the current pool state. It uses a specific verb and resource, and distinguishes from sibling tools like SimulateBalancerMove.

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

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

The description implies usage for depeg scenarios but does not explicitly state when to use this tool versus alternatives like AssessDepegRisk or SimulatePriceMove. No direct when-to-use or when-not-to-use guidance.

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