LP Pool Check

Estimate fees versus impermanent loss

estimate_lp

Read-onlyIdempotent

Estimate fees versus impermanent loss. Use this when the user gives numbers for a what-if and wants to know whether swap fees cover impermanent loss, gas, and exit cost. It needs no pool and reads no live data. Pass price_now, holding_days, and fee_apr_percent, for example price_now 2500, holding_days 14, fee_apr_percent 40. Add price_lower and price_upper for a concentrated range, or omit both for the full-range formula. Optionally pass price_later, capital_usd, gas_usd, and exit_cost_usd. Returns the formula, the fee fraction, the impermanent loss fraction, whether fees cover it and the costs you passed, a plain break-even price line, and break-even prices from a sample. It does not look up gas or recommend a position. To read a real pool's volume and fee APR, use check_pool.

Input Schema

TableJSON Schema

Name	Required	Description
`gas_usd`	No	Gas you expect to pay. Not looked up
`price_now`	Yes	Current price, quote token per base token, such as 2500 for ETH in USDC
`capital_usd`	No	Position size, so gas and exit cost can be turned into a fraction of the position
`price_later`	No	A later price to score. Omit to get break-even prices and the range edges only
`price_lower`	No	Lower bound of a concentrated range. Omit, with price_upper, for the full-range formula
`price_upper`	No	Upper bound of a concentrated range
`holding_days`	Yes	How many days the fee APR is applied, a whole number from 1 to 365, such as 14
`exit_cost_usd`	No	Other exit cost. Not looked up
`fee_apr_percent`	Yes	Annualized fee APR in percent, not a fraction: 40 means 40%. For example the 1-day fee APR from check_pool

Output Schema

TableJSON Schema

Name	Required	Description
`notice`	Yes
`status`	Yes
`formula`	Yes
`gas_usd`	No
`warnings`	No
`assumptions`	Yes
`fee_fraction`	Yes	Expected fee income over the holding period, as a fraction of the position: 0.0153 means 1.53%
`in_range_now`	No	Whether price_now is inside the range. null for the full-range formula
`cost_fraction`	No	(gas_usd + exit_cost_usd) / capital_usd. null without capital_usd
`exit_cost_usd`	No
`sampled_edges`	No
`break_even_line`	No
`fee_apr_formula`	Yes
`break_even_prices`	Yes	Later prices where the net result crosses zero, from a sample
`il_fraction_at_later`	No	Impermanent loss at price_later as a negative fraction. null without price_later
`fees_cover_il_and_costs`	Yes	null without price_later
`net_versus_holding_at_later`	No	fee_fraction + il_fraction_at_later - cost_fraction

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedOct 13, 2026

changedInput schema / properties / fee_apr_percent / description

Previous value: -"Annualized fee APR in percent, such as the 1-day fee APR from check_pool"New value: +"Annualized fee APR in percent, not a fraction: 40 means 40%. For example the 1-day fee APR from check_pool"

changedInput schema / properties / holding_days / description

Previous value: -"How many days the fee APR is applied"New value: +"How many days the fee APR is applied, a whole number from 1 to 365, such as 14"

changedInput schema / properties / price_now / description

Previous value: -"Current price, quote per base"New value: +"Current price, quote token per base token, such as 2500 for ETH in USDC"

addedOutput schema / description

Added value: +"Bad input, such as a price of 0 or price_lower above price_upper, is refused with invalid_input and a message instead of this shape"

addedOutput schema / properties / break_even_prices / description

Added value: +"Later prices where the net result crosses zero, from a sample"

addedOutput schema / properties / cost_fraction / description

Added value: +"(gas_usd + exit_cost_usd) / capital_usd. null without capital_usd"

addedOutput schema / properties / fee_fraction / description

Added value: +"Expected fee income over the holding period, as a fraction of the position: 0.0153 means 1.53%"

addedOutput schema / properties / fees_cover_il_and_costs / description
```
Added value: +"null without price_later"
```

addedOutput schema / properties / il_fraction_at_later / description

Added value: +"Impermanent loss at price_later as a negative fraction. null without price_later"

addedOutput schema / properties / in_range_now / description

Added value: +"Whether price_now is inside the range. null for the full-range formula"

addedOutput schema / properties / net_versus_holding_at_later / description
```
Added value: +"fee_fraction + il_fraction_at_later - cost_fraction"
```
removedOutput schema / properties / sampled_edges / items / additionalProperties
```
Removed value: -true
```

addedOutput schema / properties / sampled_edges / items / properties

Added value: +{
+  "il_fraction": {
+    "type": "number"
+  },
+  "net_versus_holding": {
+    "type": "number"
+  },
+  "price": {
+    "type": "number"
+  }
+}

addedOutput schema / properties / sampled_edges / items / required

Added value: +[
+  "price",
+  "il_fraction",
+  "net_versus_holding"
+]

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

Changed2 schema fields changedOct 3, 2026
- addedOutput schema / properties / break_even_line
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / warnings
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
First observedOct 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds genuinely useful behavior the annotations cannot express: it is a pure calculation with no pool lookup, no live data, no gas lookup, and no position recommendation, plus a description of what it returns. That is solid added context, though it does not discuss limits or failure modes (e.g. invalid range edges where price_lower >= price_upper).

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

Conciseness4/5

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

Front-loaded with purpose and usage before parameter detail, and every sentence carries information. It is on the long side for a single tool, but the length is justified by nine parameters and the range/optional branching; no filler sentences.

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

Completeness5/5

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

For a nine-parameter calculator with an output schema, the description covers when to use it, required vs optional inputs, the full-range vs concentrated-range branch, and the shape of the result. Nothing needed to invoke it correctly is missing, and it correctly does not lean on the description to explain return values.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes further: it names the three required parameters with concrete example values, states the price_lower/price_upper pairing rule (both or neither), and enumerates the optional set. That adds usable invocation guidance beyond the schema.

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

Purpose5/5

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

States a specific verb and subject ('Estimate fees versus impermanent loss') and immediately distinguishes itself from siblings by naming check_pool as the tool for live pool data. An agent can tell what this does and what it is not without opening the schema.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('when the user gives numbers for a what-if'), explicit exclusions ('needs no pool', 'reads no live data', 'does not look up gas or recommend a position'), and names the alternative for the other case ('To read a real pool's volume and fee APR, use check_pool'). Routing is unambiguous.

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

All LP Pool Check tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.