LPSignal

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds the substantive methodological facts an agent cannot guess: the range is centered on the price at the window's start, not the current price, and the evaluation horizon is the trailing `days` window.

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?

One densely packed sentence with the operation front-loaded and the output metrics trailing after a colon. Every clause earns its place, though the density makes it slightly hard 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?

With no output schema, enumerating fee APR, impermanent loss, net APR, time in range, and ticks in the description is the right call, and the anchoring/window semantics are covered. Minor gaps remain on result granularity and chain/pool compatibility.

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 75%, and the description supplies the missing semantics: `rangePct` is a half-width anchored symmetrically at the window-start price with 0 meaning full range, and `days` defines the observation window. It adds real meaning beyond the schema text rather than restating it.

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?

Specific verb (backtest) plus resource (a symmetric price range on a pool) and a concrete list of the metrics produced. It is clearly distinct from the list/get siblings, though it never names them.

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 when-to-use statement, no prerequisites, and no routing to alternatives such as get_pool for current (non-historical) data. Usage must be inferred from the verb alone.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the bar is low, yet the description adds real behavior: a TVL ≥ $10k filter, ordering by best 7-day net APR ('best first'), a ranking caveat warning that low-TVL pools can top the list, and case-insensitive, order-agnostic symbol matching.

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?

A single dense sentence, front-loaded with the resource and filter, followed by ranking behavior and matching rules. Every clause carries information, though the length makes it slightly run-on rather than crisply segmented.

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 read-only lookup with no output schema, the description adequately conveys what comes back (pools with their best range by 7-day net APR). Gaps remain around the chain filter's effect and any result-count limits, but the core call semantics are 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 67% (tokenA/tokenB have examples, chain is enum-only with no description). The description compensates usefully by specifying that symbols match case-insensitively and in either order, clarifying the two required params, but it says nothing about how the optional chain parameter limits the search.

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

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

States a specific verb+resource ('Every listed pool of a token pair') plus exact scope: across chains, DEXes and fee tiers with a TVL ≥ $10k floor. This is clearly distinguishable from the sibling list_pools, since it is scoped to a token pair rather than all pools.

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 the use case (look up all pools for a pair, ordered by best 7-day net APR) and even gives an interpretation caveat ('a small pool can rank first, so weigh tvlUsd'). It does not explicitly say when to prefer a sibling such as list_pools over this tool, so routing is left partly to inference.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld=false, so the safety profile is covered. The description adds real value by disclosing exactly what a call returns (fee APR, impermanent loss, net APR, time in range, exact ticks) across four fixed windows. It stops short of noting failure behavior for a bad address/pool id.

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?

A single dense sentence that leads with the resource and then the returned fields and time windows. Nothing is padded, though the parenthetical metric list is long enough that a lead sentence plus a second sentence would scan faster.

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?

With no output schema, the description carries the return-value burden and does so concretely for a read-only, idempotent lookup. Both required inputs are covered by the schema, and the safety profile is covered by annotations, so an agent has everything needed to call 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 coverage is 50%: the address parameter is documented in-schema (0x40 hex pool address or 0x64 hex v4 pool id) and chain has an explicit enum. The description contributes nothing about either parameter, so it neither compensates for nor worsens the half-documented schema. 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 names a specific resource (one pool's details plus its backtests) and enumerates the metrics returned, so it is clearly not the same as list_pools or find_pair_pools. It never names a sibling explicitly, and it opens with a noun phrase rather than a verb, so the differentiation is implied rather than stated.

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?

Selecting this tool is inferable from the singular scope ("one pool's") plus the fixed 1h/24h/7d/30d windows, which contrasts with a custom-range sibling. However, no alternative is named and no condition is given for choosing this over backtest_range, leaving the routing to inference.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description clears it by disclosing what is returned (ticks, TVL, 24h volume, pool-level fee APR) and how net APR is computed over the window. It doesn't mention pagination or result-size behavior, keeping it short of a 5.

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 tight sentences that front-load the ranking method before the return payload and filters. Dense but every clause carries information; the parenthetical formula is justified because the metric is the tool's core.

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?

With no output schema and 8 parameters, the description usefully spells out the returned fields and metric semantics, so an agent can interpret results. Pagination and ordering behavior are left to the schema, a minor gap rather than a blocking one.

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 63%, and the description compensates by explaining the window default (7 days/168h), the net APR sort basis, and the 'best price range' concept that ties into the range fields returned. It adds meaning beyond enum labels, though undocumented params like offset/limit remain schema-only.

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?

Starts with a specific verb+resource ('Active pools ranked by...') and defines the ranking metric precisely as net APR = fees − impermanent loss, which distinguishes it from peers like get_pool and find_pair_pools. An agent can identify this as the ranking/discovery tool 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.

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

It states the filtering dimensions ('Filter by chain and pool class') and the default window, implying when the tool fits, but never contrasts itself with siblings such as find_pair_pools or get_pool or says when a single-pool lookup is preferable. Usage is inferable rather than explicit.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely non-obvious behavior: signals carry an access label, opportunities on a free plan or without sign-in are delayed 24 hours, and outcomes are only populated 'once scored'. That freshness/plan gating is valuable and not derivable from 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?

Purpose is front-loaded in the first clause and every sentence carries information (signal taxonomy, access gating, pagination). The heavy nested parentheticals make it denser to parse than ideal, but there is 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?

With no output schema, the description carries the return-shape burden and does so: 'the exact ticks,' the realised outcome once scored, and the per-signal access field. Pagination is covered via `before`. Auth requirements for the `source` values remain slightly under-explained, but the picture is largely 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 75%, so the schema already documents limit, before, and source. The description earns credit by explaining the meaning of the `kinds` enum values themselves (net_apr = high net APR range over 7 days and still today; burst = last hour; hot_pool = fee APR jump), which the schema does not. It omits any explanation of `smart_lp`, and doesn't add to `source`/`limit`.

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

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

The description states a specific resource ('the newest signals') and enumerates what those signals are (net_apr, burst, hot_pool, depeg, tvl_outflow), giving the agent a precise picture of the payload. It never names sibling tools like signal_track_record, so the boundary is inferred rather than stated.

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

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

It gives operational guidance for pagination ('Page back with before') and explains access tiers (live vs delayed_24h for free/no-sign-in), which is helpful context. However, it never says when to prefer this tool over signal_track_record or smart_lp_leaderboard, so usage against alternatives is only implied.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real context: re-backtesting on exact ticks, the distinct evaluation horizons (7 days for net_apr, 24 hours for burst), and the shape of the result (counts, share positive, median APR at signal vs realised, worst case).

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?

A single dense sentence covers scope, method, horizons, and outputs with little waste. The phrasing 'How past opportunity signals really did' is slightly colloquial and requires a re-read, but it is compact and front-loaded.

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?

With no output schema, the description usefully enumerates the returned metrics, and both optional parameters are fully documented with defaults in the schema. It is complete enough to call correctly, though a note on the lookback vs horizon interaction (days=30 but 7-day evaluation) would help.

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, but the description adds meaning the schema does not: the per-kind evaluation horizon (7 days for net_apr, 24 hours for burst) explains what 'kind' actually changes. The 'days' lookback and default are already 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 names the resource (past opportunity signals) and the specific operation (re-backtesting them on their exact ticks after the fact), which is clearly distinct from list_signals or backtest_range conceptually. It never names a sibling outright, so an agent must infer differentiation, keeping it below 5.

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

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

There is no explicit when-to-use guidance, no exclusions, and no mention of the sibling backtest_range, which sounds like an adjacent capability. The agent can infer that this is a retrospective accuracy check, but nothing states when this beats 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?

Annotations already establish readOnly/idempotent/non-destructive and a closed (non-open-world) data source, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the free tier is capped at 10 entries and masks addresses, which tells the agent the output differs by credential tier. It does not explain what changes with a Pro key, so it is not fully 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?

Two sentences, no filler, with the core ranking definition front-loaded before the tier caveat. The first sentence is a dense comparative construction that takes a moment to parse, but nothing is wasted and it fits an easy-to-scan size.

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 read-only, zero-required-parameter tool the description is close to adequate, and with no output schema the description carries the burden of explaining returns — it gives the ranking basis but not the fields or the fact that masked results are still ranked. Combined with the unstated meaning of windowDays and chain, it is the minimum viable rather than 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 only 33% — only 'limit' carries a description, and chain/windowDays are documented solely by enum values. The description mentions the top-10 default (relevant to 'limit') but says nothing about the chain filter or what a 30 vs 90 day window means, so it does not compensate for the coverage gap.

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 names the resource (wallets) and the ranking metric precisely: realized LP performance of closed positions versus a hold benchmark. That is far more informative than the bare title 'Smart-LP leaderboard' and easily distinguishes it from siblings like list_signals or signal_track_record. It stops short of stating that the output is a ranked list with a defined shape, but the intent is unambiguous.

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?

There is no when-to-use guidance, no mention of alternatives, and no statement of prerequisites such as needing a Pro key. The 'Without a Pro key' clause is a result-tier caveat rather than invocation guidance, so an agent still cannot tell when this tool is the right choice over the other analytics siblings.

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