How to connect DeFade MCP with TypeScript

Run a full DeFade scan on one token contract: token metadata, holder distribution, creator history (wallet age, previous token launches) and the headline risk verdict. Start here for any "is this token safe", "is this a rug pull" or "should I buy this" question. Returns risk.score as a SAFETY score where 100 is clean and low numbers are dangerous, with a rating label. For the inverse — a rug pull probability where high means dangerous — call get_rug_score. Not for a single module in isolation (call that module's tool directly), price or market-cap questions (get_token_price), or checking the caller's own quota (get_usage). Arguments: address and chain; one API unit on any chain.

Rug pull probability for one token: a 0-100 score where HIGHER MEANS MORE DANGEROUS, a verdict label, and the individual signals that drove it. This is the opposite direction from get_token_scan's safety score. Call this tool ONLY when the user explicitly asks for a rug probability or rug likelihood; every general "is this safe" or "should I buy" question goes to get_token_scan instead. Not for the evidence behind the number — it names the signals but does not list the wallets; for who is behind the risk call get_wallet_links, get_dev_tracker or get_launch_bundles. Arguments: address and chain; one API unit on any chain.

Holder distribution for one token, with liquidity pools, burn addresses, lockers, exchange wallets and contracts classified out, so the top-holder list reflects actual holders. Returns the classified top holders with each wallet's supply share in a single response — no pagination. Use it to answer how concentrated the supply is and whether a few wallets could collapse the chart. Not for what large holders are doing right now (get_whales), whether holders are secretly one actor (get_wallet_links or get_lookalike_clusters), or pool depth and locks (get_liquidity). Arguments: address and chain; one API unit on any chain.

Wallets holding at least 1% of supply once pools, lockers, treasuries and custodial accounts are removed. Each row carries the balance, share of supply, any attribution label (known KOL, dev-linked stash, exchange), the 24-hour transaction count and recent buys and sells; the summary counts dangerous and active whales and gives a whale-risk verdict. One response, no pagination; cached for 15 minutes, so activity figures can lag by that much. A token with nothing above the threshold returns an empty list and largestHumanPct, so the empty state is explainable rather than silent. Use it after get_holders when the question is about who can dump and whether they are already dumping. Not for the full ranked holder list (get_holders), historically profitable wallets (get_smart_money), or the creator's own wallet (get_dev_tracker). Arguments: address and chain; one API unit on any chain.

Liquidity pool analysis for one token: which DEX holds the deepest pool, its depth in USD, and whether the LP tokens are burned, locked or still in someone's hands. lpStatus is the verdict — LP BURNED, LP LOCKED, LP UNLOCKED, PARTIALLY BURNED, LP NOT LOCKABLE, BONDING CURVE (still on a launchpad curve, no pool yet) or NO LP FOUND, with combinations spelled out — and lpBurnPct, lpLockPct and poolLocks carry the evidence. Use it to answer whether liquidity is locked, how deep it is, and whether the position could be pulled: LP UNLOCKED means it can be pulled at any time. Cached for about two minutes. A token with no pool returns empty liquidity data, which is itself a warning on a token that is trading. Not for price or volume (get_token_price), market cap (get_token_scan) or holder concentration (get_holders). Arguments: address and chain — pools live per chain, so a 0x address needs the chain it trades on, and a Base pool is not found under ethereum; one API unit on any chain.

Bundle detection for one token: coordinated buys in the launch window plus delayed sweeps, accounted on peak net exposure rather than raw buy count, so wallets that bought and flipped are not counted as holders. Heavy bundling that is still held is one of the strongest rug predictors. Use it for any "was this launch bundled" question. Not for lone fast buyers with no coordination (get_launch_snipers), clusters that formed after launch (get_lookalike_clusters), or the creator's own selling (get_dev_tracker). Arguments: address and chain; one API unit on any chain.

Bots that bought in the first block or first seconds of this token's launch, and whether they are connected to the deployer. The window is the first 120 seconds after the first transaction; at most 30 rows are returned and totalEarlyBuyers carries the full count. Migration-crank MEV bots are excluded and named rather than silently dropped. Check reachedGenesis: when false the walk did not reach the true first transaction, the result is partial, and it is cached for only 10 minutes instead of 2 hours. Use it to tell an organic launch from a pre-arranged one. Not for coordinated multi-wallet launch buying (get_launch_bundles) or the deployer's funding of other wallets (get_wallet_links). Arguments: address and chain; one API unit on any chain.

The graph of proven on-chain links between wallets around one token — who funded whom, who transferred to whom, and coordinated timing — typically the deployer's supply fanned out to look like organic demand. Use it when the holder list looks distributed and you want to know whether it really is. This is the hard-evidence member of the four "who is really behind this token" tools — a link counts only when a transfer or a shared funder is on chain: wallets that merely behave alike are get_lookalike_clusters, where the money first entered the chain is get_funding_sources, and identical bot fee settings are get_fee_fingerprint. Scope: the top 25 real holders are traced (pools, lockers and exchanges excluded), connections is capped at 50 rows with connectionsTotal as the full count, and an empty graph means no on-chain link was found among them — not proof they are independent, so follow up with get_lookalike_clusters. Not for the creator wallet's own sales and transfers (get_dev_tracker) or for market data of any kind. Arguments: address and chain; one API unit on any chain.

Wallets with a track record of profitable entries that are holding or trading this token, classified from their historical trade win rates — a "verified" smart-money tag requires a known win rate of 50% or better. Computed live from the current holder set and cached for about five minutes. Use it for the bullish side of a scan: who informed is in, and when they got in. Not for risk assessment — informed wallets present never offsets a rug signal, and a clean result is not a buy signal — and not for wallet size (get_whales). Arguments: address and chain; one API unit on any chain.

What the token's creator has done with their supply: the share they still hold, what left through sales versus transfers, and where the transfers went. Read the state carefully: still holding is neutral, a dev who simply sold out is statusColor gray — the standard launch pattern, not a rug — fully exited on a fresh token is a warning, and transferred out to fresh wallets (red) is the single strongest rug signal DeFade tracks. The creator is the wallet that created the mint on Solana and the contract deployer on EVM chains; creatorSource says how it was identified, and creatorInferred true means it may be a launchpad authority rather than a person, so weigh the verdict accordingly. Not for wallets other than the creator (get_whales, get_wallet_links); the creator's earlier launches are already served by get_token_scan's creator block (tokenCreations, recentTokens). Arguments: address and chain — the deployer is read from the contract creation on that chain, so a 0x address needs its chain; one API unit on any chain.

Multi-hop tracing of where the money behind this token's key wallets actually came from, walking each funding chain back and tiering the source by whether it is a KYC'd exchange. Use it to test whether several "unrelated" holders share one funding source. It answers provenance only — money in, one dimension: it does not build the wallet-to-wallet transfer graph (get_wallet_links), group look-alike behaviour (get_lookalike_clusters), or match shared bot fee settings (get_fee_fingerprint). Read coveragePct before the origins: it is the share of supply that could be attributed, the remainder (unknownCount wallets) could not be traced and is not evidence either way, and dexPct and bridgedPct are real states rather than attributions. Results are cached for 30 minutes (computedAt, fromCache). Not for the creator's own activity (get_dev_tracker) or launch-window buying (get_launch_bundles, get_launch_snipers). Arguments: address and chain — a 0x address needs its chain; on an EVM chain this call costs 5 API units instead of 1, because the trace runs against paid indexers, so check get_usage before running it across many tokens.

Clusters of wallets around one token that behave as a single actor — buys sized and timed alike so demand looks organic — even when no transfer or funding trail connects them. That behavioural inference is what separates it from get_wallet_links, which only reports proven links. Use it when supply looks distributed across many small wallets and the insider graph comes back clean; corroborate with get_fee_fingerprint. Not for proven transfer links (get_wallet_links), the funding source behind the wallets (get_funding_sources), or launch-window coordination (get_launch_bundles). Arguments: address and chain; on an EVM chain this call costs 5 API units instead of 1, because the trace runs against paid indexers.

Wallets whose transactions pin an identical fee setting — compute-unit price or Jito tip on Solana, priority fee or legacy gas price on EVM chains — one operator's bot settings showing up across every wallet it drives. This is the shared-CONFIGURATION member of the "who is really behind this token" family (proven transfers: get_wallet_links; funding origin: get_funding_sources; behavioural twins: get_lookalike_clusters), not a timing link: it never proves bundling, and two wallets can match days apart. Use it to corroborate get_lookalike_clusters, and to catch the operator who sold their launch wallets and re-entered through fresh ones; read a match as corroboration, never as proof of coordinated buying. Groups are strongest first; pending true means no bundle scan has run for this token yet, so nothing has looked rather than nothing was found. Arguments: address and chain; one API unit on any chain, because it reads what the bundle scan already computed.

Price history for one token as OHLCV candles, plus the latest price, the window's high and low with their timestamps, and the percent change across the window — prices in USD (the *Usd fields), volume as the market source quotes it. Aggregated from DEX market sources and cached for about a minute. Intervals with no trades are omitted rather than zero-filled, so consecutive candles can sit more than one step apart. The optional timeframe argument sets the candle size and with it how far back the window reaches: 15m (the default) covers about the last 2.5 days, 1H about 10 days, 4H about 40 days and 1D up to a year of daily candles, back to the token's first trade if it is younger; there is no start or end argument, the size fixes the window. Use 1D for "what did it peak at", "how far is it down from the top" or any price history question; use the default for the market context around a risk verdict. A token with no liquidity pool returns candles: [] and totalCandles: 0 rather than an error. Not for risk of any kind — market data carries no forensic signal — and not for pool depth or lock status (get_liquidity) or market cap (get_token_scan's token block). Arguments: address, chain and timeframe — a 0x address needs its chain; one API unit on any chain regardless of timeframe.

Report the calling API key's plan, rate limits and how much of its monthly allowance is left. Takes no arguments. Use it when a call fails on quota, or when the user asks what their DeFade plan includes. Not for anything about a token — every other tool takes an address; this one reports on the key itself.