EchoLedger

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

With no annotations, the description carries the full burden. It discloses how IL is calculated, the unit convention, and the limitation that fee income is not attributed because Balancer only exposes vault-level fees. The rpc_url schema adds that the URL is never persisted or logged, which is meaningful behavioral context.

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

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

The description is two dense sentences with no filler. Every clause contributes: pool type, IL decomposition, unit convention, fee limitation, and version. It is front-loaded and easily scannable.

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

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

The tool has 9 parameters, no output schema, and no annotations, so the description must carry substantial weight. It covers purpose, IL behavior, units, and fee attribution. However, it does not describe the return values (e.g., net_pnl, real_apr) which would be helpful given the absence of an output schema.

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

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

Schema coverage is 100%, so the parameters are fully described in the schema. The description adds general context about units and IL decomposition but does not directly explain individual parameters beyond what the schema already provides. Baseline 3 applies.

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

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

The description clearly states a specific verb and resource: 'Analyze a 2-asset Balancer weighted-pool LP position's PnL.' It distinguishes itself from siblings by focusing on Balancer weighted pools, IL decomposition using the weighted-pool formula, and the convention of opp-token units.

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 this tool is for Balancer weighted-pool LP positions and the schema enforces pool_type='balancer'. However, it does not explicitly name alternatives like AnalyzeStableswapLP for Curve pools, so the context is clear but exclusions are implicit.

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 the non-mutating analysis nature by using 'Analyze' and detailing the return fields (current value, hold value, IL percentage, fee income, net PnL, real APR, diagnosis label). It also explains conditional behavior (real APR depends on holding period). It does not explicitly state 'read-only' or discuss side effects, but the verb and output list imply a safe read 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?

The description is two sentences front-loaded with the purpose, followed by a concise breakdown of the decomposition and outputs. Every sentence adds value, with no fluff or repetition. It is appropriately sized for the tool's 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 the tool's moderate complexity (11 params, no output schema), the description provides a clear overview and enumerates return values, which is sufficient for an agent to understand what to expect. It lacks edge-case context (e.g., out-of-range ticks, schema inconsistency in pool_address mentioning Balancer/Curve), but the main description resolves ambiguity by restricting to Uniswap V2/V3. The schema covers parameters thoroughly, so the description is nearly complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; it mentions 'holding period' which is already described in the schema. All parameters have detailed descriptions in the schema, so the description’s lack of parameter-specific detail is acceptable but does not enhance or clarify beyond the schema.

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

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

The description uses a specific verb ('Analyze') and clearly identifies the resource (Uniswap V2/V3 LP positions). It explicitly distinguishes itself from sibling tools by naming the protocol scope, and it details the analysis breakdown (IL, fees, net PnL) and outputs, leaving no ambiguity about what the tool does.

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 clearly states when to use the tool: for analyzing Uniswap V2 or V3 LP positions. It implies the protocol-specific scope, which differentiates it from sibling tools like AnalyzeBalancerLP and AnalyzeStableswapLP. However, it does not explicitly mention alternatives or provide exclusion criteria, so it misses the top score.

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 does well: it discloses valuation units (peg-numeraire), exclusions (fee income not attributed), and edge-case behavior (returns None for unreachable alpha regime). It also warns about high A's effect on IL, providing substantial behavioral 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?

Two sentences pack purpose, scope, and three caveats without redundancy. Every clause adds value, and the key purpose is front-loaded, making it appropriately sized and well-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?

For a complex analysis tool with no output schema, the description covers important output fields (il_percentage, net_pnl, real_apr) in edge cases and explains valuation/fee assumptions. It doesn't enumerate all potential outputs, but given the schema richness and sibling context, it is reasonably complete.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description adds no direct parameter semantics beyond mentioning the formula and None cases, which aligns with the baseline 3 for high coverage.

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

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

The description clearly states the tool analyzes a 2-asset Curve-style Stableswap LP position's PnL using a specific formula (amplified-invariant IL). This distinguishes it from siblings like AnalyzeBalancerLP and SimulateStableswapMove by specifying the pool type and analytical method.

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 stableswap LP analysis and scopes to 2-asset Curve-style pools, but does not explicitly name alternatives or exclusions. The schema's pool_type constraint reinforces the scope, yet the description lacks direct alternative guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does well by explaining the closed-form stableswap-invariant expansion, the optional V2 benchmark, and the important edge case where unreachable depeg levels return null for certain fields while the V2 benchmark remains populated. However, it does not explicitly state that the tool is read-only, nor does it mention authentication or rate-limit considerations. The schema's rpc_url comment covers privacy, but the main description omits side-effect and access-level 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?

Two dense, front-loaded sentences with no filler. The first sentence establishes purpose and computation; the second covers the critical edge case. Every clause earns its place, and the structure makes the description easy to scan.

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?

There is no output schema, but the description compensates by naming return fields (il_pct, lp_value_at_depeg, hold_value_at_depeg) in the null-case explanation and by specifying defaults and benchmark behavior. It still does not fully describe the output envelope (e.g., how scenarios are keyed), but for an LP risk tool with this complexity, the provided context is largely sufficient for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by naming default depeg levels (2%, 5%, 10%, 20%, 50%), the optional V2 benchmark, and the null-output behavior for unreachable levels, which enriches the meaning of depeg_levels and compare_v2. But it does not add semantic detail for parameters like lp_init_amt, pool_address, or chain_id 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 starts with a specific verb ('Quantify') and identifies a precise resource: a 2-asset Curve-style Stableswap LP position's exposure to stablecoin depeg. It clearly distinguishes this tool from siblings like AnalyzeStableswapLP (general analysis) and SimulateStableswapMove (price move simulation) by focusing on multi-level depeg IL with an optional V2 benchmark.

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 clearly conveys the intended context: use this when assessing IL from a stablecoin depeg on a 2-asset stableswap LP. It mentions the optional V2 comparison and default depeg levels, giving a solid sense of when it applies. However, it does not explicitly state when not to use it or name alternative tools for related but different analyses.

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 transparency burden. It explicitly discloses that 'The endpoint stores and logs nothing — your rpc_url is never persisted', a meaningful behavioral trait for a tool handling potentially sensitive RPC URLs. It also implies read-only semantics via 'Read', though it doesn't discuss rate limits or error behavior.

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

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

The description is three sentences long, each earning its place: the first states the core function and output, the second gives usage context, and the third adds a privacy guarantee. It's front-loaded and has 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?

The tool is moderately complex (7 parameters, no output schema), but the rich schema descriptions cover the parameters. The description adds the output format components (protocol-specific snapshot plus content_hash), the supported pool types, and the no-logging behavior. It could be more explicit about the exact JSON return structure, but overall it's sufficient for selection and 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%, with each parameter individually described in detail. The description itself does not add parameter-level semantics beyond what the schema already covers, so it meets the baseline of 3 without needing to compensate.

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 'Read a pool's on-chain state once and return it as a serialized State Twin (JSON)', clearly stating the verb ('read') and resource ('pool's on-chain state') and the output format. It distinguishes itself from sibling analysis tools by positioning itself as a data-pulling step for client-side counterfactuals, which sets it apart from the analysis-focused siblings.

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

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

The description advises to 'Use this to pull a single managed-RPC twin, then run any number of counterfactuals... client-side', providing clear context on when to choose this tool. It doesn't explicitly name alternatives or state when not to use it, but the context is specific enough to guide usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly lists what is returned (spot vs execution price, slippage percentage, slippage cost, price impact) and discloses a meaningful limitation: V3 returns null for the maximum trade size because tick-crossing math has not been inverted. This goes beyond a mere statement of 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 three sentences, front-loaded with purpose. Sentence 1 states what it does, sentence 2 enumerates the outputs, and sentence 3 explains the V2/V3 difference. Every sentence carries essential information, with no filler or repetition. This is exemplary conciseness.

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?

There is no output schema, so the description must convey return values; it does so by listing all key metrics. It also covers the V3 null behavior. It does not specify the exact output structure (e.g., field names or units) beyond 'output-token units', but for a calculation tool this level of detail is adequate. The parameter side is fully covered by the schema, so the description is sufficient for the tool's complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level detail beyond what the schema already provides. It mentions the maximum trade size result, but that is an output, not a parameter. The schema descriptions are already rich (e.g., rpc_url privacy, amount_in human units), so the description does not need to compensate.

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 specific verb and resource: 'Calculate slippage and price-impact decomposition for a proposed swap on a Uniswap V2 or V3 pool.' This clearly states what the tool does and distinguishes it from sibling analysis tools like AnalyzePosition or CheckPoolHealth, which focus on positions or pool health rather than swap execution metrics.

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 context: use this tool when you have a proposed swap on a Uniswap V2 or V3 pool and need slippage/price-impact decomposition. It does not explicitly mention alternatives or when-not-to-use, but the specific 'proposed swap' framing makes the intended use case evident. Sibling tools exist, but the description gives enough context to choose appropriately.

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 discloses that num_swaps and fee_accrual_rate_recent are V2-only and return null for V3, and that a single-block live snapshot returns null for LP-concentration and swap metrics because they are unrecoverable from state. These are significant behavioral caveats not evident from the schema alone.

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

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

The description is concise and front-loaded with the primary purpose, followed by metric details and caveats. Each sentence adds value: purpose, metric list, V2/V3 distinction, and null behavior. There is no redundancy or filler.

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

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

Given no output schema, the description explains what metrics are returned and when they are null, which is substantial context. However, it does not describe the return value structure or error handling, and the schema's pool_address description mentions Balancer/Curve pools, which conflicts with the stated V2/V3-only scope, leaving slight 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?

The schema provides 100% description coverage for all 6 parameters, so the baseline is 3. The description adds little beyond the schema—it mentions that recent_window is V2-only and defaults to 20, but this is already present in the schema. No additional parameter semantics are provided.

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

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

The description clearly states the tool snapshots pool-level health metrics for Uniswap V2/V3 pools and lists specific metrics (TVL, reserves, fees, LP concentration, swap activity). It distinguishes from position-level analysis and sibling tools by specifying the pool-level scope and protocol 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?

The description clearly indicates the use case: answers 'is this a pool I would deposit into?' at the pool level, not position level. This implies when to use it, but it does not explicitly name alternative tools or state when not to use it beyond the pool vs position 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, the description discloses key behavior: it returns per-signal booleans, a count-based risk level, and the V2-only restriction for inactive-pool-with-liquidity. It also notes it composes over CheckPoolHealth. However, it does not explicitly state side-effect-free behavior, but that is implied and the transparency is strong.

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, front-loaded with the core purpose, and each sentence adds essential value: listing checks, specifying output and composition, and clarifying V2-only behavior. No redundancy.

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

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

The description covers the main logic, output type, and V2 nuance, which is sufficient for a tool with no output schema. It doesn't document every parameter or external requirement (like needing RPC URL), but those are in the schema. Overall, it gives a clear picture of functionality and expectations.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds some meaning by linking signals (low TVL, top-LP concentration, inactive pool) to parameters, but it does not provide detailed parameter semantics beyond what the schema already offers. It adds context but not extensive new info.

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: detecting rug-pull signals on Uniswap V2/V3 pools via three specific threshold checks. It uses a specific verb ('Detect') and resource, and its composition over CheckPoolHealth distinguishes it from sibling 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 clear context for when to use it (when rug-pull signals are needed) and notes it composes over CheckPoolHealth, but it does not explicitly state exclusions or alternatives. The intended use case is clear, though 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?

No annotations are present, so the description carries the transparency burden. It discloses how the shock is applied (base-token price in opp units), what influences IL (weights), and what the return values are. It does not explicitly state that the operation is non-mutating/read-only, which is a minor gap for a simulation 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 text is three sentences, front-loaded with the core purpose, followed by the mechanics and return values. Every sentence adds necessary detail 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 8 parameters, no output schema, and no annotations, the description covers the essential aspects: what it computes, the key dependencies, and the return structure. It would benefit from explicit mention of alternatives and edge cases, but it is largely complete for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds conceptual value by explaining that the price shock is in base-token/opp units and that IL depends on pool weights, which connects the parameters to the underlying model. This goes beyond the schema descriptions.

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

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

The description uses a specific verb ('Project') and resource ('2-asset Balancer weighted-pool LP position'), clearly separating this from sibling stableswap or generic price simulators. It states exactly what the tool does: simulate value under a hypothetical price change from the current pool 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 clearly implies use for Balancer 2-asset weighted pools and explains the context (price shock, IL). However, it does not explicitly name alternatives like SimulateStableswapMove or SimulatePriceMove, so it lacks explicit exclusion guidance.

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

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

With no annotations, the description carries full transparency burden. It discloses a key limitation (fee projection is not modeled and always null), explains that the simulation starts from the current pool state, and lists the return fields (new value, IL, and percentage change). This adds meaningful behavioral context beyond the basic 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 two sentences, front-loaded with the core purpose, includes a concrete example (-0.30), and ends with the relevant limitation about fees. Every sentence earns its place with no filler or redundancy.

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

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

For a 10-parameter tool with no output schema, the description covers the purpose, input semantics via an example, return values, and a limitation. Minor gaps exist (e.g., how V2 vs V3 are handled differently, edge cases in batch), but the description is substantially complete and actionable for an agent.

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

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

Schema description coverage is 100% with rich per-parameter explanations (e.g., batch form, chain_id guard, rpc_url privacy, V3 tick constraints). The description adds high-level semantics about the simulation and output but does not need to restate parameter details, so 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 uses the specific verb 'project' with a clear resource ('Uniswap V2 or V3 LP position's value') and explicitly defines the scope ('from the CURRENT pool state (not from entry)'). It distinguishes the tool from siblings like SimulateBalancerMove and SimulateStableswapMove by naming Uniswap V2/V3, and the example clarifies the simulation semantics.

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 clearly indicates this tool is for Uniswap V2/V3 LP positions and emphasizes the simulation is from the current state, not entry, which guides when to use it. It does not explicitly name alternatives or exclusions, but the protocol scoping and example are sufficient for an agent to infer appropriate usage relative to 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 and does well: it explains the shock formula (alpha multiplied by (1+price_change_pct)), discloses that large shocks may be physically unreachable and returns nulls for certain fields, and states units are in peg-numeraire. It does not explicitly state read-only behavior, but 'project' and 'simulate' strongly imply no mutation.

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

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

The description is two sentences, front-loaded with the purpose, followed by essential behavioral detail (formula, null case, units). Every sentence earns its place without 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?

Despite lacking an output schema, the description names key outputs (new_value, il_at_new_price, value_change_pct), their units, and null behavior. The batch-vs-single mode is left to the schema, which already documents it thoroughly. Minor gap: no mention of when the batch form should be preferred, but the schema covers the 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 coverage is 100%, so the baseline is 3. The description adds value by defining price_change_pct's effect on alpha and explaining the null-output edge case, which goes beyond the schema. It correctly avoids restating parameter-by-parameter details already available in the schema.

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

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

The description opens with a specific verb 'Project' and clearly identifies the resource: a 2-asset Curve-style Stableswap LP position. It distinguishes itself from sibling tools by scoping to Curve stableswap and specifying the hypothetical depeg scenario from the current pool 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 conveys a clear use case—simulating a depeg shock on a stableswap LP—and states it operates on the CURRENT pool state. However, it does not explicitly name alternatives like SimulateBalancerMove or exclusion criteria, so it lacks full when-to-use vs 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.