Skip to main content
Glama

lp-placement

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): 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

TableJSON Schema
NameRequiredDescriptionDefault
taskNoWhat you want, with the address in it

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

D1.8/5.0
Behavior2/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters2/5

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.

Purpose2/5

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.

Usage Guidelines2/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources