DeFade
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEFADE_API_KEY | No | DeFade API key (starts with df_). Keyless runs still handshake and list tools; scan tools then reply with instructions to get a key. | |
| DEFADE_MCP_URL | No | Overrides the upstream MCP endpoint for testing. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_token_scanA | Run a full DeFade scan on one token contract: token metadata, holder distribution, creator info 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. |
| get_rug_scoreA | 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. |
| get_holdersA | 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. |
| get_whalesA | 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. 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. |
| get_liquidityA | Liquidity pool analysis for one token, including burn and lock verification and pool depth. Use it to answer whether liquidity is locked, how deep it is, and whether the position could be pulled. Not for price, market cap or volume (get_token_price) or holder concentration (get_holders). A token with no pool returns empty liquidity data, which is itself a warning on a token that is trading. Arguments: address and chain; one API unit on any chain. |
| get_launch_bundlesA | 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. |
| get_launch_snipersA | 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. |
| get_wallet_linksA | 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 tool of the forensic family: for wallets that merely behave alike with no provable link, call get_lookalike_clusters; for where the money entered the chain, get_funding_sources. 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. |
| get_smart_moneyA | 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. |
| get_dev_trackerA | 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, fully exited on a fresh token is a warning, and transferred out to fresh wallets is the single strongest rug signal DeFade tracks. Not for wallets other than the creator (get_whales, get_wallet_links) or for the creator's earlier tokens. Arguments: address and chain; one API unit on any chain. |
| get_funding_sourcesA | 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 graph (that is get_wallet_links) or group look-alike behaviour (get_lookalike_clusters). Not for the creator's own activity (get_dev_tracker) or launch-window buying (get_launch_bundles, get_launch_snipers). Arguments: address and chain; on an EVM chain this call costs 5 API units instead of 1, because the trace runs against paid indexers. |
| get_lookalike_clustersA | 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 on Solana. Not for proven transfer or funding links (get_wallet_links) 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. |
| get_fee_fingerprintA | Wallets whose transactions pin an identical compute-unit price or Jito tip — one operator's bot settings showing up across every wallet it drives. This is a shared-CONFIGURATION link, not a timing one: 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. Solana only. Do not call it for EVM addresses — pass chain solana or omit chain — and do not read a match as proof of coordinated buying; it is corroboration only. Arguments: address only in practice — chain must be solana or omitted, and an EVM chain is rejected with an error before any request is spent. One API unit. |
| get_token_priceA | Current market data for one token — price, market cap, liquidity, volume and recent OHLCV candles — aggregated from DEX market sources and cached for about a minute, so figures are near-live but not a tick-by-tick trading feed. A token with no liquidity pool returns empty market data rather than an error. Use it for the market context around a risk verdict. Not for risk of any kind — market data carries no forensic signal — and not for long price history beyond the recent candles. Arguments: address and chain; one API unit on any chain. |
| get_usageA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DeFadeLtd/defade-sdk'
If you have feedback or need assistance with the MCP directory API, please join our Discord server