DeFiMind

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

With no annotations, the description partially covers behavioral aspects: it clarifies that the 'rpc_url' is not persisted or logged, indicating a read-only, stateless operation. However, it does not explicitly state that the tool is read-only, nor disclose rate limits, authorization needs, or side effects.

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

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

The description is three sentences long, front-loaded with the key purpose, and each sentence adds essential information: what it does, how it decomposes PnL, and what it returns. No redundant or extraneous text.

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

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

Given 11 parameters, no output schema, and no annotations, the description covers purpose, return values, and one behavioral detail (rpc_url logging). Missing are error conditions, prerequisites (e.g., need for a valid pool), and assurance that it is read-only. Feels adequate but not comprehensive.

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 all parameters are documented clearly. The description adds value by summarizing the output variables (current value, hold value, IL%, fees, net PnL, real APR, diagnosis), but does not elaborate on 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 verb 'analyze' and the resource 'Uniswap V2 or V3 LP position', specifying PnL decomposition into impermanent loss, fees, net result, etc. It distinguishes itself from sibling tools by focusing on PnL analysis rather than slippage, pool health, or price simulation, though not explicitly naming alternatives.

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

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

The description implies usage for diagnosing position performance but lacks explicit guidance on when to use this tool vs alternatives like CheckPoolHealth or SimulatePriceMove. No conditions, prerequisites, or exclusions are provided.

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

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

The description discloses key behaviors: returns specific slippage components, notes that V3 max trade size returns null due to incomplete tick math, and is a read-only calculation. It also references RPC usage details from parameter descriptions.

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, front-loaded with purpose and key returns, no filler. Each sentence adds meaningful information about functionality and limitations.

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 medium complexity (9 params, no output schema), the description lists all return fields and explains V2 vs V3 behavior. Could mention error handling or edge cases, but overall sufficient for understanding inputs and outputs.

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

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

Schema description coverage is 100%, providing baseline clarity. The description adds minimal extra meaning beyond schema, mainly explaining the V2/V3 difference in max trade size field. Parameter descriptions in schema are already thorough.

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 calculates slippage and price-impact decomposition for Uniswap V2/V3 pools, specifying the returned fields. It distinguishes from siblings like AnalyzePosition or SimulatePriceMove by focusing on slippage 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 no guidance on when to use this tool versus siblings such as AnalyzePosition or SimulatePriceMove. There is no mention of prerequisites, limitations, or alternative 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?

Describes the tool as a read-only snapshot with no side effects. Discloses that the rpc_url is not persisted. Annotations are absent, so description carries full burden; it sufficiently covers behavioral traits without contradiction.

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?

Highly concise: a few sentences front-loaded with purpose. Every sentence adds value, no repetition 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?

Explains the returned metrics (TVL, reserves, fees, etc.) and V2/V3 differences. Without an output schema, description covers the essential return structure, though more detail on formats would improve completeness.

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

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

Schema coverage is 100%, but description adds value beyond schema by explaining V2/V3 differences for metrics and providing security context for rpc_url. This elevates it above the baseline of 3.

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

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

Clearly states it snapshots pool-level health metrics for Uniswap V2/V3 pools and answers a specific question ('is this a pool I would deposit into?'). Differentiates from sibling tools like AnalyzePosition (position-level) and DetectRugSignals (security analysis).

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?

Specifies the scope as pool-level (not position-level) and notes that num_swaps and fee_accrual_rate_recent are V2-only, guiding the agent on when V3 returns null. Implicitly distinguishes from sibling tools, but lacks explicit 'use this when' or 'alternatives'.

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

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

No annotations are provided, so the description carries full burden. It discloses the V2-only limitation for one signal, the return format (booleans and risk level), and the non-persistent handling of the RPC URL. It does not explicitly state read-only, but the detection nature implies no modification.

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: purpose, composition/output, and a V2-specific caveat. No wasted words; every sentence adds value. It is front-loaded with core functionality.

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

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

While the description covers the three checks, risk level categories, and V2-only limitation, it lacks detailed output structure (e.g., field names for booleans and risk level). No output schema exists, so the description should be more precise about the return format. The composition over CheckPoolHealth is mentioned but not elaborated.

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 three threshold checks (TVL, LP concentration, inactivity) which maps to parameters but does not significantly enhance the schema's explanations. It provides useful overall context but no new parameter-level details.

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 Uniswap V2/V3 pools using three specific threshold checks, and distinguishes itself from sibling tools by composing over CheckPoolHealth and returning a composite 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?

The description implies usage for rug-pull assessment and composition over CheckPoolHealth, but does not explicitly state when to use this versus alternatives like CheckPoolHealth or other sibling tools, though the purpose includes sufficient differentiation.

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 key behaviors: projects from current pool state (not entry), returns new value/IL/percentage change, and notes fee projection is always null. It also transparently mentions the BYO-RPC nature and that URLs are not persisted. However, it omits failure modes (e.g., invalid pool address, missing ticks for V3). Overall, fairly transparent.

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 concise sentences: first establishes purpose, second provides example and output summary, third clarifies a limitation. Every sentence is necessary, front-loaded with the core business logic, and avoids 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 9 parameters, no output schema, and moderate complexity, the description covers core functionality, return values, and a key limitation. It mentions reading live state via RPC but does not specify prerequisites like valid pool address or connectivity checks. Almost complete for a simulation 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 100%, baseline 3. The description adds meaningful context: explains price_change_pct with example (-0.30), clarifies lwr_tick/upr_tick are V3-only, notes position_size_lp > 0, and explains rpc_url is BYO-RPC not persisted. This adds value beyond the schema's field 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's verb and resource: 'Project a Uniswap V2 or V3 LP position's value at a hypothetical price change from the CURRENT pool state'. This distinguishes it from sibling tools like AnalyzePosition (analysis) and CalculateSlippage (slippage), as it specifically focuses on hypothetical price simulation from current 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 implies usage for 'what if' scenarios but does not explicitly state when to use this tool versus alternatives like CalculateSlippage or AnalyzePosition. No 'when not to use' or alternative recommendations are provided, leaving some ambiguity for an AI agent.

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