Skip to main content
Glama

bsc_pool_scan

Read-only

Free for 1,000 scans per caller a day, then a day pass. The full honeypot / rug-pull / liquidity read behind the preflight. Measure what a trade on BNB Smart Chain would actually cost, for ANY token or pool — before placing it. Reads the pool live from the chain and returns: real cost per trade size (price impact + swap fee + transfer tax together, not the headline slippage a router shows), the USD size that moves the price 1% in each direction, the transfer tax measured from executed trades (simulated on chain at that block when the pool has not traded in the last hour, and flagged measured:false) rather than taken from a label, how much of the token's liquidity the readable pool actually holds, and whether the LP is burned or still withdrawable — plus our own sell simulation on the router from a fresh address (sellability). A token still raising on four.meme with no pool yet is measured from four.meme's own contract instead (curve: raise progress, price, buy/sell cost per size, fee). Works on PancakeSwap V2, V3 and Infinity CL (an Infinity pool is found from its key on chain and priced by PancakeSwap's own Infinity quoter, its hook included), Uniswap V2 and V3, and Biswap; a token still on four.meme's or flap.sh's launch curve is read from that curve. Read tax.measured and tax.source before using the cost columns: a tax that could not be measured comes back null with a warning, never as 0%; quotable: false with a reason is an answer, not an error. Also returned: deeperPoolElsewhere (a bigger pool for the same token than the one read), tax.simulated (an independent cross-check next to the measured tax), lp.custody (who holds the LP of a V2 pair, wallet by wallet, the deployer flagged; complete from the pair's own logs when it is under an hour old; V3 positions not read), holders (the largest wallets with exchange, lock and burn addresses named apart, or unknown: true with the reason when there is no real list yet), age (pool and token, from the first block their code existed), activity (swaps, buys vs sells, unique traders, volume and the largest sell over the window read), flow (who sold over that window: the deployer and wallets it funded, netted against liquidity they added back to the same pair, top holders selling over a quarter of their balance, and for a pool under an hour old the launch-block buyers still holding), venues[] (the scanned pool first, pools under $100 left out) and contract.properties (the GoPlus contract flags, true/false/null, with the ones it did not check named). No API key; pool figures are never cached, contract properties (from GoPlus) for up to 6 h. Free for 1,000 scans per caller and UTC day; past that it answers code free_limit, and a day pass carries on (POST https://agent.brainonbnb.com/scan-pass: 0.50 USD1, half that in $BOBAI, nothing for a wallet holding 1,000,000 $BOBAI), sent as HTTP header X-Scan-Pass.

Input Schema

NameRequiredDescriptionDefault
addressYesA BSC token address, a pool/pair address, or any BscScan / DexScreener / PancakeSwap link containing one
scan_passNoOnly past the free 1,000 scans a day: the day pass from POST https://agent.brainonbnb.com/scan-pass, for clients that cannot set the X-Scan-Pass header

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint annotations: discloses free-tier limits and the exact free_limit failure mode, the day-pass purchase path and header, what is and isn't cached (pool figures never, GoPlus flags up to 6h), and warns that unmeasurable tax returns null with a warning, never 0%. This is rich behavioral context an agent needs.

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

Conciseness3/5

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

The content is valuable but the structure is weak: it opens with pricing text rather than purpose, and the free-scan/day-pass information is repeated at the start and again at the end. It is a dense wall of clauses that could be trimmed and front-loaded.

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?

With no output schema, the description carries the burden of explaining returns, and it does so thoroughly: cost columns, price-impact sizes, tax measurement and flags, LP custody, holders, age, activity, flow, venues, and contract properties, plus edge cases like four.meme curves and Infinity pools.

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

Parameters4/5

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

Schema coverage is 100%, so the address and scan_pass parameters are already documented. The description adds useful operational semantics the schema doesn't: no API key is needed, the scan_pass exists only past the free limit and for clients that cannot set the X-Scan-Pass header, and the day-pass endpoint is given.

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+resource: measures what a trade on BNB Smart Chain would actually cost by reading the pool live from the chain, including honeypot/rug-pull/liquidity signals. It explicitly positions itself as 'the full read behind the preflight,' distinguishing it from the sibling bsc_token_preflight, and enumerates supported venues.

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

Usage Guidelines4/5

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

Makes the timing explicit ('before placing it') and tells the agent how to interpret results ('Read tax.measured and tax.source before using the cost columns'; 'quotable: false with a reason is an answer, not an error'). It does not give an explicit when-not-to-use or name a competing sibling, so it falls short of a 5.

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