Skip to main content
Glama

lp_tier_plan

Read-only

Which PancakeSwap fee tier is actually paying its liquidity providers, the paid half (0.10 USD1, or half that in $BOBAI, or nothing for a wallet holding 1,000,000 $BOBAI (holder pass over x402: a signature, no transaction — terms in the reply)): A pair on PancakeSwap 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 interface ranks them by the money already parked in them, which is not what they pay. This measures each tier over a live window: turnover, the fees the pool actually paid out, and what your capital would have earned in each, both sides of the pool counted. And it does the sum the way the money actually works: fees go to the liquidity standing where the trade happens, so each tier is also read at the price — the tick book of the pool itself is walked to find what is parked within a couple of percent of it — with your own size in the denominator, because arriving is what dilutes it. On a constant-product pool that is under one percent of the balance, so the tier holding the most money is regularly not the tier you would be competing with least. It names the tiers holding real money that did not trade at all, and states how long the better tier would have to keep paying before a move pays for its own gas. Not annualised: the window travels with every figure. Calling this tool returns the terms; the answer is sold over x402 at https://agent.brainonbnb.com/answer?service=lp_tier_plan (or hired through the ERC-8183 escrow for 0.10 $U).

Input Schema

NameRequiredDescriptionDefault
taskNoWhat you want, with the address in it

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior4/5

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

Beyond the readOnly/destructive/openWorld annotations, the description discloses material behavior: the call returns terms only, the answer is sold over x402 at a specific URL, escrow payment is an option, and a 1,000,000 $BOBAI holder pass requires only a signature and no transaction. The one gap is that it is ambiguous whether the tool itself returns the analysis or merely a quote, and no latency/rate-limit expectations are given.

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

Conciseness2/5

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

One long run-on paragraph with nested parentheticals and rhetorical framing ('which is not what they pay', 'regularly not the tier you would be competing with least'). The concrete deliverable is not front-loaded and the payment mechanics are tacked onto the tail, forcing a full read to find the operative facts.

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

Completeness3/5

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

It covers what the analysis contains and how payment works, which is adequate for a one-parameter, no-output-schema tool. However, the window length is never specified, the shape of the returned answer is not characterized, and the 'returns the terms' wording leaves the agent unsure what a bare call actually yields.

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% with a single 'task' string already documented as 'What you want, with the address in it'. The description implies the task concerns a pair/address and a live window but adds no format, required tokens, or window syntax beyond the schema, so the baseline of 3 applies.

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

Purpose3/5

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

The core purpose is recoverable — it measures PancakeSwap fee tiers (V2 0.25%, V3 0.01/0.05/0.25/1.00%) over a live window for turnover, fees paid, and capital yield. But it is buried under heavy metaphor ('the paid half', 'arriving is what dilutes it', 'the tick book is walked') and never names or contrasts with the sibling pancakeswap_fee_tiers, so the agent must parse a paragraph to extract the verb+resource.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the scenario (choosing which tier to provide liquidity into, whether a move pays for gas) is inferable from the analysis described, and payment/access paths are named. There is no explicit when-to-use, no when-not, and no routing to pancakeswap_fee_tiers as the simpler alternative.

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