Skip to main content
Glama

bsc_pool_scan

Read-only

The full honeypot / rug-pull / liquidity read behind bsc_token_preflight, every figure and its source. Use it when the preflight’s short answer is not enough (an audit, a dashboard, a second look at one figure); for the go/no-go before a trade call bsc_token_preflight, and for the route alone pancakeswap_best_route. 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "bsc_pool_scan"
  }
}

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. Changed1 schema field changed
    • addedInput schema / properties / scan_pass
      Added value: +{
      +  "description": "Only 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",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.5/5.0
Behavior4/5

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

With readOnlyHint and destructiveHint already supplied, the description still adds substantial non-obvious behavior: no API key is required, pool figures are never cached while GoPlus contract properties are cached up to 6 hours, there is a 1,000-scan-per-caller-per-UTC-day free tier that returns code free_limit past the cap, and the paid day pass with X-Scan-Pass header. It also warns that tax.measured may be false, that an unmeasured tax returns null with a warning rather than 0%, and that quotable:false is an answer not an error — genuine operational guardrails. It stops short of 5 only because the response shape for some sub-objects (venues[], flow) is described in prose rather than pinned down precisely.

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 opening two sentences are well front-loaded, placing purpose and sibling routing ahead of the detail. However, the remainder is a single run-on block of several hundred words with no paragraph or list structure, restating the free-tier and day-pass mechanics that the scan_pass schema already carries, which makes it hard for an agent to scan for a specific field.

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?

There is no output schema, so the description carries the full burden of explaining return values, and it does so field by field: tax.measured/tax.source, quotable, deeperPoolElsewhere, lp.custody, holders, age, activity, flow, venues and contract.properties. For a tool this complex with only two parameters, an agent has enough to call it correctly and interpret the result without further documentation.

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 already 100%, so the address parameter needs no help; the description's contribution is on scan_pass, tying it to the free-limit boundary, the day-pass purchase endpoint, the pricing tiers and the fact that it exists for clients that cannot set the X-Scan-Pass header. That is real context beyond the schema's one-line description, raising it one step above the baseline for full coverage.

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?

The description names a specific verb and resource ('reads the pool live from the chain', 'measure what a trade on BNB Smart Chain would actually cost') and enumerates the concrete outputs: cost per trade size, 1% price-impact depth, measured transfer tax, LP custody, holders, age, activity, flow, venues and GoPlus contract flags. It explicitly positions itself against both siblings, bsc_token_preflight and pancakeswap_best_route, so an agent can distinguish it from those tools without opening any schema.

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

Usage Guidelines5/5

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

It states when to use it ('when the preflight's short answer is not enough — an audit, a dashboard, a second look at one figure') and when not to ('for the go/no-go before a trade call bsc_token_preflight, and for the route alone pancakeswap_best_route'). The two alternatives are named with the exact condition that selects them, leaving nothing to inference.

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