PancakeSwap V3 fee tiers of a BSC token, free; tier and range plan paid, or free holding 1M $BOBAI.
Scored across 2 tools
Both tools are about the same thing — which PancakeSwap fee tier is worth placing liquidity in — and their descriptions repeat key phrasing ('which fee tier is actually paying its liquidity providers'). The only real boundary is free-vs-paid, which is not expressible in the names and only becomes clear after reading the long prose. An agent can easily pick the wrong one.
One tool uses an 'lp_' domain prefix with a noun phrase, the other a 'pancakeswap_' prefix with a different noun phrase; neither uses a verb_noun action pattern. There is no predictable scheme an agent could generalize to a third tool.
The domain is narrow (LP fee-tier analysis for a single DEX), so a small surface is defensible, but one tool is essentially a teaser for the other. Effectively there is one capability split across two entry points.
The stated purpose includes planning a position (tier + range), but neither tool actually returns a plan — the paid tool only returns purchase terms, and the free tool only lists the pools and the paying tier. There is no range computation, position read, or any lifecycle operation beyond the single diagnostic answer.
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).
| 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?
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.
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.
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.
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.
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.
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.
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 plans the position: the tier and the range to put it in. It signs and moves nothing.
| 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=true, openWorldHint=true and destructiveHint=false, and the description reinforces this with 'It signs and moves nothing', which directly addresses the common agent worry about whether a liquidity tool will submit a transaction. It also discloses the five-pool result cap, a behavioral detail not present in annotations or schema. It stops short of describing pagination or what happens when a token has no pools.
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?
It is short and the key capability is front-loaded, but the colon-based 'free half / paid half' framing is stylized and requires unpacking, and the second sentence is about a different tool rather than this one. Content earns its place, but the phrasing could be plainer.
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?
There is no output schema, so the description must convey the return shape; it does so only loosely (up to five pools plus their active fee tier) without naming fields or ordering. For a one-parameter read-only lookup this is adequate, but an agent still lacks a precise picture of the response.
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?
With a single parameter at 100% schema description coverage, the schema already carries the semantics ('A BEP-20 token address on BNB Chain'). The description adds no format or constraint detail and in fact refers to 'a pair' where the schema expects one token address, so it neither compensates nor clarifies beyond baseline.
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 concrete resource — the up-to-five PancakeSwap pools a token trades in and which fee tier is paying LPs — plus a scope cap ('up-to-five'). It never uses an explicit verb like 'list' or 'return', and it speaks of 'a pair' while the schema takes a single token address, but an agent can still tell what data comes back and how it differs from lp_tier_plan ('the paid half plans the position').
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?
Usage is implied through the 'free half' vs 'paid half' framing: this is the discovery step, and the planning step is the paid one. However, the sibling lp_tier_plan is never named and no explicit when-to-use / when-not-to-use condition is stated, so the agent must infer the ordering.
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.
pancakeswap_fee_tiers1 field changedInput schema / examplesAdded value: +[
+ {
+ "address": "0x0e09fabb73bd3ade0a17ecc321fd13a19e81ce82"
+ }
+]lp_tier_planpancakeswap_fee_tiersPancakeSwap V3 range check for any position, free; re-centre plan paid, or free holding 1M $BOBAI.
PancakeSwap best route, free; a rebalance priced on real pools paid, or free holding 1M $BOBAI.
What a BSC pool costs to trade, free; grid levels and break-even spacing paid, free with 1M $BOBAI.
Venus supply rates on BNB Chain, free; whether moving pays its gas paid, or free holding 1M $BOBAI.
Add one secure layer between your agents and this server.