Skip to main content
Glama

pancakeswap-lp-route

pancakeswap_fee_tiers

Read-only

Measure which PancakeSwap fee tier of a pair actually pays liquidity providers, to decide WHERE to put liquidity. Use it before adding liquidity to a pair; once the pool is chosen use pancakeswap_range_plan for the price range, for a position you already hold use pancakeswap_position_look, and for a swap (not liquidity) use pancakeswap_best_route. Pass a token to compare all its pools against its main quote, or a pool address to pin the exact pair. A pair lives in up to five pools at once — V2 at 0.25% and V3 at 0.01%, 0.05%, 0.25% and 1.00% — and every source ranks them by the money already parked in them, which does not say which one pays. This measures each tier over a live window: swaps, turnover, the fees the pool actually paid out, and those fees per $1,000 of capital — over TWO denominators. The first is everything the pool holds, which is what every interface shows. The second is the capital standing within 2% of the current price, reconstructed by walking the tick book of the pool itself, because concentrated liquidity parked far from the price earns nothing and a new dollar only competes with the capital that is at the price. The two rankings disagree often, and both are returned. It also names tiers holding real money that did not trade at all. Measured, never annualised: the window is about an hour of chain and is reported with the answer. The same token asked again within 60 seconds gets the same measurement from the edge cache (cache.hit, cache.age_seconds). Read-only, free, no key; a tier whose pool could not be read is listed in tiers_unreadable and comparison_complete says whether every tier was measured.

Input Schema

NameRequiredDescriptionDefault
addressYesA BSC token address (all of its PancakeSwap pools against its main quote are compared), or one PancakeSwap pool address to pin that exact pair; 0x + 40 hex

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and non-destructive, and the description still adds substantial context beyond that: read-only, free, no key required; a measured ~1-hour window rather than annualised figures; the two denominators and why the second is reconstructed from the tick book; cache behaviour with cache.hit and cache.age_seconds within 60 seconds; and partial-failure signalling via tiers_unreadable and comparison_complete.

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?

Purpose and usage routing are front-loaded, followed by methodological detail, which suits a complex metric. It is long but nearly every sentence carries information; a few clauses (e.g. explaining what every interface shows and why distant liquidity earns nothing) could be tightened without losing meaning.

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?

No output schema exists, so the description carries the return-value burden and does: both rankings, two denominators, unreadable tiers, comparison_complete, and cache metadata. For a one-parameter analytical tool this is complete enough to call correctly and interpret the result.

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

Parameters3/5

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

Schema coverage is 100% and the single address parameter already documents the token-vs-pool dual meaning and the 0x+40 hex format. The description restates that choice with a little extra context about comparison scope, but adds no format or edge-case detail 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.

Purpose5/5

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

States a specific verb and resource: measures which PancakeSwap fee tier of a pair actually pays liquidity providers, to decide where to place liquidity. It explicitly distinguishes itself from the three sibling liquidity tools (range_plan, position_look, best_route), so an agent can route without opening a 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 explicit when-to-use (before adding liquidity to a pair), names the alternatives and the conditions that select them (range_plan for the price range once the pool is chosen, position_look for an existing position, best_route for swaps not liquidity). It also tells the agent how to choose between the two input modes: token vs pool address.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources