PancakeSwap V3 fee tiers for a BSC token, free; which tier and range to place liquidity in, paid.
Scored across 2 tools
Both tools describe the same core question — which PancakeSwap fee tier is actually paying its LPs — and the only real differentiator is buried marketing language ('the paid half' vs 'the free half'). An agent cannot reliably tell from the tool names or openings which one to call, and the paywalled x402 endpoint inside lp_tier_plan's description further muddies what the tool actually does.
Both names use snake_case and read as domain-qualified nouns (lp_tier_plan, pancakeswap_fee_tiers), so the convention is consistent. The only oddity is that one is abbreviated ('lp') and the other fully expanded with a chain prefix, which is a minor deviation.
Two tools is very thin for an LP-placement server, and one is essentially a free teaser for the other rather than a distinct capability. There is no operational surface beyond a single analysis query.
The stated purpose implies helping place liquidity, but there is no tool to actually open, size, or manage a position — only to measure tiers. The 'paid half places a position' promise has no corresponding callable tool, so the surface dead-ends at analysis.
Which PancakeSwap fee tier is actually paying its liquidity providers, the paid half (0.10 USD1, or half that in $BOBAI): 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).
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | What you want, with the address in it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, so the tool is known to be a safe, external-data-touching read. The description adds claims of measuring turnover, fees, and capital earnings, but no operational details about rate limits, data freshness, or what happens on invocation beyond a sales URL. This is insufficiently transparent for an unfamiliar, payment-gated tool.
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 a long, meandering monologue filled with tangential details, rhetorical flourishes, and an obvious commercial pitch. It is not front-loaded and wastes far too many words on non-essential context.
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?
The description is completely inadequate for an agent to select and invoke the tool correctly. It does not explain the tool's core function, does not differentiate it from the sibling, and instead pivots to a sales pitch for an external answer service.
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% for the single 'task' parameter, so the schema already documents it. The description does not clarify parameter usage beyond the schema, and additionalProperties is true, which she needed to be defined.
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 is a rambling essay rather than a clear statement of what the tool does. While phrases like 'Which PancakeSwap fee tier is actually paying its liquidity providers' hint at an analysis function, the tool names no clear verb+resource and never distinguishes itself from the sibling 'pancakeswap_fee_tiers' in a usable way.
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 mentions a payment mechanism (x402, ERC-8183 escrow) but does not say when to use this tool versus the sibling 'pancakeswap_fee_tiers'. No explicit when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liquidity placement, the free half: the up-to-five PancakeSwap pools a pair lives in and which fee tier is actually paying its liquidity providers. The paid half places a position in the tier that pays.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | A BEP-20 token address on BNB Chain (0x…) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description does add two pieces of behavioral context not in the annotations: the call is 'free' (no payment required) and the result is capped at up to five pools. But 'free' is ambiguous (no cost vs. unoccupied) and no other traits (auth, data freshness, rate limits) are disclosed.
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 is a reasonable size, but the opening fragment 'Liquidity placement, the free half' is cryptic and delays the payload. The useful content (up-to-five pools, which fee tier pays LPs) arrives only in the second half of the first sentence.
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 burden of explaining returns; it partially does (pool set plus the fee tier that pays LPs) but never says what fields come back or how a single token address resolves to pools. Adequate for a one-parameter read tool, but not 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 100%, so the single address parameter is fully documented in the schema; the baseline is therefore 3. The description adds no syntax or format detail, and it talks about 'a pair' while the input is one BEP-20 token address, leaving the token-to-pair mapping unexplained.
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 conveys that this returns the PancakeSwap pools a pair trades in and their fee tiers, but the verb is never stated and the framing ('the free half') is metaphorical rather than operational. It gestures at the sibling ('the paid half places a position') without naming lp_tier_plan, so differentiation is inferential.
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 free-vs-paid framing implies this is the lookup/inspection path while the sibling is the action path that places a position, which is usable routing guidance. However, it never explicitly says 'use this when X, use lp_tier_plan when Y', and no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
lp_tier_planpancakeswap_fee_tiersPancakeSwap V3 range check for any position or wallet, free; the re-centre plan is paid. BNB Chain.
What a BSC pool really costs to trade, free; grid levels with their break-even spacing, paid.
PancakeSwap best route on BNB Chain, free; a portfolio rebalance priced against real pools, paid.
BNB Chain: which AI agents answer, what a BSC trade costs, what your PancakeSwap V3 position earns
Add one secure layer between your agents and this server.