Skip to main content
Glama

A.U.G.U.R Foresight · Bundle Forensics

EVM launch + bundle forensics

evm_bundle_forensics
Read-onlyIdempotent

Who bundled an EVM token launch (Base, BSC, Ethereum, Arbitrum, Robinhood and 13 more): creation-tx airdrops to fake holders, first-seconds buys, scripted fixed-cadence buying, fresh-wallet and transfer-only holders, dev holdings, exchange-labelled holders, GoPlus contract flags — plus a skip/pass verdict. Replays every ERC-20 Transfer of the token from its first mint on the public RPC, so for young tokens (Base ~4 days, BSC ~6 h of history in budget) holder balances, buys and wallet-to-wallet hand-offs are exact. Launchpads (Four.meme, Uniswap v4 PoolManager, v2/v3 pairs from Dexscreener) are detected; vault/locker contracts that never bought are kept out of the wallet rules, while contracts that DID buy (smart wallets, bundler contracts) count as wallets. Older tokens fall back to GoPlus holders with 527 exchange wallets named. Skip rules: GoPlus honeypot/tax>10%/owner powers; top-10 wallets >35%; first ~2 s of buys >20%; >10% held by wallets that never bought; creation tx airdropping ≥10 wallets or >10%; scripted buying (≥5 buys ≥1% at a regular cadence taking ≥15%); fresh wallets / buyer contracts >15%. Heuristic on EVM (mirrors the back-tested Solana guard); "pass" is not a safety promise. When to use: Bundles and who holds an EVM token launch (Base/BSC first-class); for contract-only flags use evm_token_security (on the A.U.G.U.R Foresight · Wallets & Risk server, https://augur-trade.com/hub/mcp/risk). Price: $0.005 per call (10 free/day; after that a payment-required result lists x402 options). Errors: returns isError with a message for invalid input or an upstream failure (not charged).

Input Schema

NameRequiredDescriptionDefault
chainYesEVM chain: ethereum, base, arbitrum, optimism, polygon, bsc, avalanche, linea, blast, scroll, gnosis, sonic, unichain, mantle, berachain, hyperevm, monad, robinhood. One of "ethereum", "base", "arbitrum", "optimism", "polygon", "bsc", "avalanche", "linea", "blast", "scroll", "gnosis", "sonic", "unichain", "mantle", "berachain", "hyperevm", "monad", "robinhood". Default "base".base
tokenYesERC-20 token contract address. 0x + 40 hex chars.

Output Schema

NameRequiredDescriptionDefault
msNo
okNo
noteNo
warnNo
chainNo
poolsNo
tokenNo
bundleNo
launchNo
supplyNo
symbolNo
holdersNo
reasonsNo
verdictNo
contractNo
transfers_replayedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent safety, yet the description adds a lot beyond them: full Transfer-log replay semantics, per-chain history budgets that change accuracy, launchpad/locker handling, fallback behavior for older tokens, pricing with free tier and x402 payment-required result, error/charging behavior, and an explicit 'pass is not a safety promise' caveat.

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

Conciseness4/5

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

Front-loaded with the core question and verdict, and every block (replay semantics, skip rules, routing, pricing, errors) carries real information. However it is one dense run-on paragraph where the skip-rule thresholds could be a list, which costs some scannability.

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?

An output schema exists, so return values need no explanation; the description instead covers what an agent needs to call it correctly and interpret a verdict: accuracy limits by chain age, heuristic caveat, cost model, and failure mode.

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 coverage is 100% and both params are documented with enum and address pattern, so the schema does the work. The description's chain list repeats what the enum already contains and adds no format or edge-case guidance beyond it – baseline 3.

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 question it answers ('Who bundled an EVM token launch') plus the evidence classes it returns (creation-tx airdrops, first-seconds buys, scripted cadence, dev/exchange holders, GoPlus flags) and a verdict. It is clearly distinct from the sibling contract-flags tool, which it names.

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?

Explicitly says when to use it ('Bundles and who holds an EVM token launch, Base/BSC first-class') and routes contract-only questions to evm_token_security with its server URL. It also gives the concrete skip thresholds, so the agent knows what a 'skip' means.

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