A
licenseA
qualityB
maintenanceOn-chain rug-pull & honeypot risk screen for ERC-20 tokens, providing a SAFE / CAUTION / HIGH-RISK verdict based on live public RPC reads.
2
MIT
bsc-token-preflight
Server Details
Honeypot and rug-pull check for any BNB Chain token before a trade, measured on chain, free
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
TDQS
A4.1/5.0
Scored across 2 tools
Disambiguation3/5
The two tools overlap heavily: bsc_pool_scan is described as the full honeypot/rug/liquidity read behind the preflight, while bsc_token_preflight performs the pre-trade honeypot/rug check and surfaces bsc_pool_scan details. The layering is explained, but an agent must infer when to use the raw scan versus the preflight, so boundaries are only partially clear.
Naming Consistency4/5
Both names use a lowercase snake_case bsc_ prefix, which is consistent and readable. However, bsc_pool_scan follows a noun+action pattern while bsc_token_preflight is noun+noun, so the set is not a strict uniform verb_noun scheme.
Tool Count3/5
Two tools is thin for the stated server purpose, even though both are broad and information-dense. The wrapper-plus-underlying-scan structure is reasonable, but the surface sits at the borderline of 1-2 tools feeling under-scoped.
Completeness4/5
For a pre-trade BSC token preflight server, the tools cover the core needs: sellability, cost at size, taxes, liquidity/LP custody, holders, flow, age, and contract control flags. Minor gaps remain, such as no standalone route/quote tool in the exposed set, but the central preflight lifecycle is well covered.
Available Tools
2 toolsbsc_pool_scanARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | A BSC token address, a pool/pair address, or any BscScan / DexScreener / PancakeSwap link containing one | |
| scan_pass | No | 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 |
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.
bsc_token_preflightARead-onlyInspect
START HERE for any BSC token. Honeypot and rug-pull pre-trade check, measured not labelled: For an agent about to trade ANY token on BNB Smart Chain: the check to run before every trade, in one call and at YOUR size. Answers the two questions that matter before signing - can I get in, and can I get out again - and what the trip costs. Returns stop[] (facts that end an automated trade: the sell does not go through from a fresh address, nothing quotes, half the money is gone on an immediate round trip) and caution[] (facts to weigh, each with its figure and the line it was measured against: a transfer tax that is high, unknown or changeable by the owner; a size that moves the price more than 1%; a deeper pool elsewhere; LP that can still be withdrawn, and by whom - the deployer holding the LP is named - or that was already withdrawn; holders unknown or concentrated; the deployer or a wallet it funded selling into the pool (net of liquidity it added back), a top holder selling over a quarter of its balance, launch buyers holding over 10%; contract flags), then the figures: the token’s spot price in dollars from the pool read (token.price_usd), the best PancakeSwap route at this size, what you pay and receive, the slippage in bps this size really needs, per side, from the measured tax (a fee-on-transfer token reverts below its tax), the round trip with the transfer tax applied (measured from executed trades, or, when the pool has not traded in the window, simulated on chain at that block — the answer says which), the 1% depth in both directions, LP burned and who holds the rest, pool and token age, the swaps of the last hour and who sold in it (flow). A short answer, built from bsc_pool_scan and pancakeswap_best_route, which stay available under details for every figure behind it. A token still on its four.meme launch curve is answered from four.meme's own contract. It also reads who controls the contract on-chain (control: owner() / getOwner() and whether that owner is renounced, a plain wallet or a contract, an EIP-1967 proxy and its admin, a mint(address,uint256) function in the bytecode) and names an owner that is one wallet where the token has a tax, a mint function or a proxy. gate is the verdict in one word to branch on - stop, weigh or no_known_stop - and each stop/caution item with a figure carries it as value, line and unit. A refusal comes with a code (is_wallet, not_a_token, bad_address, bad_usd, ...) and a hint. It does not say "safe" and returns no score: it cannot see an owner who has not acted yet, and says so. No API key; pool figures are never cached, the GoPlus contract flags and holder list for up to 6 h.
| Name | Required | Description | Default |
|---|---|---|---|
| usd | No | Trade size in dollars, optional - defaults to 250 | |
| address | Yes | A BSC token address, a pool/pair address, or a link containing one |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations declaring readOnlyHint=true and destructiveHint=false, the description adds extensive behavioral context beyond the schema: it explains stop[] vs caution[], the gate verdict, refusal codes and hints, caching rules, and the explicit limitation that it cannot see an owner who has not acted yet and returns no "safe" score. This is unusually transparent for a read-only analysis tool.
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 "START HERE" is appropriately front-loaded, but the description is an extremely long, dense run-on paragraph with heavy parenthetical nesting. Much of the detail is useful, yet it would be easier to scan if structured into shorter clauses or bullets; several phrases repeat the same pre-trade-check idea.
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?
For a complex tool with no output schema, the description is highly complete: it names the returned stop[] and caution[] categories, explains gate, describes price/route/slippage/tax/round-trip/depth/LP/age/flow figures, covers refusal codes, and states key limitations. An agent has enough information to invoke and interpret the tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters, including the usd default of 250 and accepted address formats. The description reinforces that measurements are taken at the caller's chosen size, but it does not add format or constraint details beyond what the schema provides.
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 states a specific verb and resource: a pre-trade honeypot and rug-pull check for any BSC token, run before signing. It distinguishes itself from sibling tools by positioning itself as the one-call preflight built from bsc_pool_scan and pancakeswap_best_route, so an agent can tell why to choose this tool rather than the lower-level ones.
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?
It gives clear selection guidance: "START HERE for any BSC token" and "the check to run before every trade, in one call and at YOUR size". It also explains that bsc_pool_scan and pancakeswap_best_route remain available under details, though it does not explicitly state when an agent should prefer those lower-level tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
bsc_pool_scan - First observed
bsc_token_preflight
Related MCP Connectors
BNB Chain token risk ratings (AAA to C), honeypot checks and rug pull forensics with on-chain proof
Token Risk — rug-pull / honeypot screening for crypto tokens.
Read-only honeypot, holder and liquidity scam checks for tokens across 64 networks.
Honeypot detection & token risk scan for ERC-20s. Risk score 0-100, tax, source verification.
Related MCP Servers
- AlicenseAqualityBmaintenancePre-trade token safety check for AI agents. Simulates a sell before you buy, then reports honeypot, tax, liquidity, pair age, same-ticker impersonation and owner powers as one low/medium/high/unknown verdict. Fail-closed: when a critical check cannot run it answers unknown rather than guessing low. Publishes its own measured error rate with the benchmark harness in the repo.3MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents and trading bots to query BNB Chain token risk ratings, inspect wallet histories, receive liquidity alerts, and assess rating reliability for rug-pull forensics.MIT
- AlicenseNot gradedqualityDmaintenanceDetects potential honeypot tokens on Ethereum, BNB Smart Chain, and Base using the honeypot.is API.MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.