Rug pull risk and on-chain forensics for tokens on Solana, Ethereum, Base and Robinhood.
Scored across 15 tools
Tools mostly target distinct forensic dimensions, and descriptions explicitly cross-reference the four 'who is behind this token' tools (get_wallet_links, get_lookalike_clusters, get_funding_sources, get_fee_fingerprint) as well as the two risk-verdict tools (get_token_scan vs get_rug_score). However, these families still share surface-level purpose (wallet attribution, risk scoring), so an agent must carefully read descriptions to avoid misselection. No two tools are identical, but ambiguity is present.
Every tool follows the same get_ + snake_case noun-phrase convention (e.g. get_dev_tracker, get_wallet_links, get_token_price). There are no deviations in case, verb style, or structure. The naming pattern is fully predictable.
15 tools sits at the upper end of the typical 3-15 range but remains well-scoped: each tool maps to a distinct analysis module (risk, holders, whales, dev activity, liquidity, launch forensics, wallet attribution, price, usage). No tool appears redundant or trivially included. The count fits a comprehensive multi-chain memecoin analyzer.
The surface covers core forensic workflows: token scan, rug score, dev tracker, holder and whale analysis, liquidity, price, launch bundles/snipers, wallet links, lookalike clusters, funding sources, fee fingerprint, smart money, and usage. Minor gaps exist: there is no token discovery/search by symbol or address, and no direct aggregate holder-count tool. These are workable-around limitations rather than critical failures.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. |
| Name | Required | Description |
|---|---|---|
| token | No | The address that was scanned (on get_token_scan, the full token metadata object instead). |
| status | No | One-line verdict: STILL HOLDING, PARTIAL EXIT, FULLY EXITED, TRANSFERRED OUT, SOLD & TRANSFERRED, DISTRIBUTED, LOCKED and similar. |
| poweredBy | No | Always "DeFade.org". |
| timestamp | No | ISO time the response was assembled. |
| recentSells | No | Transactions behind each bucket, newest first, capped. |
| statusColor | No | green, yellow, gray or red. A dev selling out is gray: the standard launch pattern, not a rug. |
| lastActivity | No | Unix seconds of the dev's most recent move of this token. |
| creatorSource | No | How the dev wallet was identified; creatorInferred is true when it may be a launchpad authority rather than a person. |
| totalMintedPct | No | Genesis allocation as percent of supply; totalBoughtPct, totalSoldPct, totalTransferredPct, totalLockedPct, totalLiquidityPct alongside. |
| currentHoldingPct | No | Percent of supply the dev holds now. |
| transferRecipients | No | Distinct wallets that received a transfer. |
| transferRecipientAnalysis | No | What large recipients did with the tokens: address, amountPct, stillHeldPct, verdict. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details behavior beyond annotations: it explains that pool/pair/wallet/deployer addresses return 'not found', that a 0x address alone cannot specify chain, and that invalid chain values are rejected pre-request. This adds operational transparency that complements the readOnlyHint and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not wasteful; every sentence contributes critical operational detail. There is minor redundancy between the chain and address parameter descriptions (both mention the inability of a 0x address to specify chain), but this repetition reinforces a key constraint without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary call context: expected input (address, chain), output meaning (share held, sales vs transfers, verdicts like 'gray' and 'red'), edge cases (invalid address types, chain mismatch), and semantics (creator identification, inferred vs actual). It fully enables correct usage without requiring external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context: address format examples, length ranges, case-insensitivity for EVM, and the requirement to set chain for 0x addresses. It also clarifies the default for chain and the consequence of providing a Solana mint with an EVM chain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('tracks') and a specific resource ('what the token's creator has done with their supply'). It distinguishes from siblings by explicitly referencing get_whales, get_wallet_links, and get_token_scan's creator block, making the tool's unique scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names alternatives and conditions: 'Not for wallets other than the creator' pointing to get_whales/get_wallet_links, and 'creator's earlier launches' pointing to get_token_scan. It also explains when to set chain for 0x addresses and that unsupported values are rejected before spending a request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 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 only as solana (or omitted) — the fee settings it reads exist only on Solana, so any other chain is refused before a request is spent. One API unit.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Only solana: this tool has no implementation on other chains, and any other value is refused before a request is spent. Omit it for solana. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. |
| Name | Required | Description |
|---|---|---|
| stats | No | Wallets seen, how many carried a readable fee setting, how many were linked, how many set none. |
| token | No | The address that was scanned (on get_token_scan, the full token metadata object instead). |
| groups | No | One entry per fee setting shared by two or more wallets, strongest first: wallets, supplyPct bought, confidence. |
| pending | No | True when no bundle scan has run for this token yet: nothing has looked, not nothing was found. |
| excluded | No | Fee values suppressed as client defaults, with the wallet count each covered. |
| poweredBy | No | Always "DeFade.org". |
| timestamp | No | ISO time the response was assembled. |
| computedAt | No | When this result was read. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully aligns with readOnlyHint, idempotentHint, and destructiveHint=false. It also discloses that non-Solana chains are refused before spending a request and that certain address types come back as not found, making side effects and error behavior transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but occasionally redundant — e.g., 'never proves bundling' and 'never as proof of coordinated buying' convey the same point. Still, each section (purpose, family, usage, output ordering, arguments) earns its place, so only minor trimming is needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to explain return structure, yet it still adds practical details like 'Groups are strongest first' and the meaning of 'pending true.' It also covers rejection and not-found cases, making it fully complete for an agent to decide and call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters, and the description enriches both address and chain semantics — explaining address formats, what is not accepted, the need to match chain to address, and that EVM with a Solana mint is rejected. This is valuable beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns wallets sharing identical fee settings (compute-unit price or Jito tip), and explicitly distinguishes it from siblings like get_wallet_links, get_funding_sources, and get_lookalike_clusters, while clarifying it is not a timing link. The purpose is unambiguous and differentiates well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use it (corroborate get_lookalike_clusters, catch operators who sold and re-entered with fresh wallets) and when not to (never proves bundling, never proof of coordinated buying). This actionable guidance goes beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. |
| Name | Required | Description |
|---|---|---|
| risk | No | Verdict with label and severity. |
| tiers | No | The same supply grouped by certainty tier, as { tier, share }. |
| token | No | The address that was scanned (on get_token_scan, the full token metadata object instead). |
| origins | No | Where holder supply was funded from, as { name, share }, biggest first. |
| poweredBy | No | Always "DeFade.org". |
| timestamp | No | ISO time the response was assembled. |
| computedAt | No | When this was computed; fromCache says whether it was served from a stored result. |
| coveragePct | No | Share of supply attributed to an origin; dexPct and bridgedPct are real states but not attribution. |
| walletCount | No | Wallets resolved, with resolvedCount and unknownCount. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, and non-destructive. The description adds valuable behavioral details: results are cached for 30 minutes with computedAt/fromCache, coveragePct indicates attribution share, unknownCount wallets are not evidence, and dexPct/bridgedPct are real states. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite being verbose, every sentence carries distinct, useful information: purpose, exclusions, coverage semantics, caching, cost, and parameter details. The structure flows logically from what it does, to when to use, to parameter requirements, to operational notes. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description still covers important context: attribution semantics, caching behavior, cost implications, and edge cases like address/chain mismatches. It provides enough detail for an agent to decide when and how to invoke, and what to expect, without needing external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover the address format, chain enum, and defaults. The description adds crucial nuances: 0x addresses need chain because they can exist on multiple EVM chains, unsupported chains are rejected before spending, EVM chains require an All-Chains plan, and invalid address types (pool, wallet) return not found. This enhances the schema meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool traces funding origins multi-hop, tiers sources by KYC'd exchange, and answers provenance questions. It explicitly distinguishes itself from siblings like get_wallet_links, get_lookalike_clusters, and get_fee_fingerprint, making its unique purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use (testing shared funding sources) and when not to use (not for creator's own activity or launch-window buying), naming alternative tools. It also provides cost guidance and a recommendation to check get_usage before bulk use, giving clear actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. |
| Name | Required | Description |
|---|---|---|
| token | No | The address that was scanned (on get_token_scan, the full token metadata object instead). |
| bundles | No | Shallow bundle detection over the real wallets: detected, bundlePct, groups. |
| poweredBy | No | Always "DeFade.org". |
| timestamp | No | ISO time the response was assembled. |
| topHolders | No | Top 20 accounts: rank, address, walletAddress, amount, percentage, solBalance, isProtocol, protocolLabel. |
| lockedSupply | No | pct plus a lockers array naming each escrow. |
| totalHolders | No | Holder count, estimated from the top accounts. |
| concentration | No | top5, top10, top20 as percent of supply, counting real wallets only. |
| deferredUnlock | No | Supply that unlocks back to the deployer later: pct, unlockDate, cancelablePct. Null when none. |
| protocolHoldings | No | What was excluded: count and totalPct. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already specify readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that it returns classified top holders and supply share, which is consistent. It doesn't contradict the annotations, though it could explicitly mention no side effects, but the annotations cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but every sentence adds useful detail, such as classification logic, usage examples, and parameter constraints. It is well-structured with a clear topic sentence and supporting details, without redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for an agent to decide when and how to call the tool, including what it returns (classified top holders and supply share). While an output schema exists, the description doesn't enumerate every field, but it's sufficient for typical usage and complements the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described with detailed explanations and examples. The 'address' parameter includes format specifics and excludes non-token addresses, while 'chain' explains when it's required and default behavior. Schema coverage is 100% and the description adds valuable edge-case information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it provides holder distribution with classifications to reflect actual holders. It also distinguishes itself from sibling tools by explicitly listing what it is not for, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use it (to answer supply concentration and potential chart collapse) and when not to use it (for large holder activity, hidden actors, or pool info), pointing to specific sibling tools. This gives clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. |
| Name | Required | Description |
|---|---|---|
| token | No | The address that was scanned (on get_token_scan, the full token metadata object instead). |
| bundles | No | Each bundle: its wallets, what they spent, what they still hold, how they were funded. |
| summary | No | Totals across detected bundles, accounted on peak net exposure. |
| poweredBy | No | Always "DeFade.org". |
| timestamp | No | ISO time the response was assembled. |
| hiddenBundleCount | No | Bundles the shallow detector does not see. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description goes further by disclosing cost (one API unit), that invalid chain values are rejected before spending a request, and that non-token addresses (pools, pairs, wallets) return not found. This exceeds the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds value. It uses semicolons and colons to pack conditions, examples, and exclusions efficiently. No redundant filler or vague marketing language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what the tool does, how it computes the metric, when to use it, when not to use it, and cost/error behavior. Since an output schema exists, no return-value explanation is needed. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions already cover chain enum, default, EVM ambiguity, Solana mint format, 0x format, and exclusions. The description largely restates this same information without adding new parameter-level meaning. Since schema coverage is 100%, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states a specific action (detect bundle activity) with a precise resource (one token) and a defining accounting method (peak net exposure). Explicitly distinguishes itself from three sibling tools by naming them and describing what they do instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases ('was this launch bundled' questions) and explicit non-use cases (snipers, lookalike clusters, dev selling), naming the alternative sibling tools. Also gives parameter-level guidance on when to omit chain and how address format determines validity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. |
| Name | Required | Description |
|---|---|---|
| stats | No | Cohort totals for the window. |
| token | No | The address that was scanned (on get_token_scan, the full token metadata object instead). |
| snipers | No | Wallets that bought inside the launch window, capped at 30 rows. |
| poweredBy | No | Always "DeFade.org". |
| terminals | No | Trading terminals the launch cohort came through; activeTerminals is who trades it now. |
| timestamp | No | ISO time the response was assembled. |
| reachedGenesis | No | Whether the walk reached the true first transaction. When false, partial is true and small snipers may be missing. |
| totalEarlyBuyers | No | How many were found in total; windowSeconds and firstTxTime describe the window. |
| migrationCrankersExcluded | No | Migration-crank MEV bots filtered out as infrastructure, named. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive behavior, and the description adds meaningful behavioral details: row limits, totalEarlyBuyers field, partial results on unreached genesis, cache duration, and API unit cost. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and details are logically ordered, but some redundancy exists (first block/first seconds vs. 120-second window). Overall it is still appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema is present, return values need not be explained. The description covers use cases, exclusions, caching behavior, limits, and parameter constraints, leaving nothing ambiguous for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are already comprehensive (100% coverage), so the baseline is 3. The description adds extra value by mentioning API unit cost and reinforcing the address/chain pairing requirement, pushing it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the resource (first-block snipers) and action (get), and explicitly differentiates from sibling tools by stating this is not for coordinated multi-wallet buying or deployer funding. The title and first sentence align perfectly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use it ('to tell an organic launch from a pre-arranged one') and when not to use it, naming the alternatives. Also provides concrete parameter guidance for address and chain, including pitfalls like using pool addresses and EVM chain disambiguation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. |
| Name | Required | Description |
|---|---|---|
| dex | No | Which DEX holds the deepest pool. |
| risk | No | Liquidity risk label; lpEvidence carries the on-chain evidence behind it. |
| token | No | The address that was scanned (on get_token_scan, the full token metadata object instead). |
| lpStatus | No | Headline pool verdict: LP BURNED, LP LOCKED, LP UNLOCKED, PARTIALLY BURNED, LP NOT LOCKABLE, BONDING CURVE, NO LP FOUND, or a spelled-out combination. |
| lpBurnPct | No | Percent of LP tokens burned; lpLockPct is the percent locked. |
| poolLocks | No | Per-pool lock detail with lpLockable and an lpNote in words. |
| poweredBy | No | Always "DeFade.org". |
| timestamp | No | ISO time the response was assembled. |
| totalLiquidityUsd | No | Combined USD depth across pools; pools lists them and poolCount counts them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: caching (~2 minutes), the empty-data-when-no-pool behavior and its warning interpretation, the per-chain isolation (Base pool not found under ethereum), and the semantics of the LP status verdicts including combinations spelled out. It does not contradict any annotation. It loses one point because it doesn't explicitly describe the output shape for the non-empty success case, though the output schema exists and covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: front-loaded purpose, then verdict definitions, then usage, then caching, then edge case, then exclusions, then argument guidance. Every sentence earns its place and the structure flows from what the tool does to when to use it to edge cases. It is long, but the length is justified by the complexity of the LP status taxonomy and the per-chain caveat; a 4 because it is slightly more verbose than the minimum needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analysis tool with a rich output schema, the description covers all critical operational context: LP status interpretation, empty data meaning, caching, chain matching pitfalls, and sibling routing. The annotations cover safety. The output schema exists to handle return-value details. Nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already thoroughly documents address and chain formats, examples, and enum values. The description adds meaning beyond the schema by explaining why chain matters ('pools live per chain', 'a Base pool is not found under ethereum'), warning that EVM keys require an All-Chains plan, and noting that pool/pair/wallet addresses come back as not found. This is real added value over the schema, but the schema already does most of the heavy lifting, so a 4 is appropriate rather than 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Liquidity pool analysis for one token') and immediately states what it answers: deepest DEX, depth in USD, and LP token status. It defines the lpStatus verdicts exhaustively and explicitly distinguishes itself from price, volume, market cap, and holder tools. An agent can tell exactly what this tool is for and what it is not for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('Use it to answer whether liquidity is locked, how deep it is, and whether the position could be pulled'), names sibling alternatives for price/volume (get_token_price), market cap (get_token_scan), and holder concentration (get_holders), and adds a practical warning: a token with no pool returns empty liquidity data, which is itself a signal. It also warns about per-chain matching and that LP UNLOCKED means the position can be pulled, which directly informs agent behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. |
| Name | Required | Description |
|---|---|---|
| risk | No | Verdict for the token with label and severity. |
| bands | No | Wallet clusters banded by how strongly they look like one operator. |
| stats | No | Totals across the bands: wallets clustered and the supply they hold. |
| token | No | The address that was scanned (on get_token_scan, the full token metadata object instead). |
| poweredBy | No | Always "DeFade.org". |
| timestamp | No | ISO time the response was assembled. |
| computedAt | No | When this was computed; fromCache says whether it was served from a stored result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it is a heuristic inference rather than a proven-link report, and EVM calls cost 5 API units instead of 1 because they run against paid indexers. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: definition, sibling differentiation, when-to-use, when-not-to-use with sibling alternatives, and cost/context. The core concept is front-loaded, and the exclusions are grouped clearly. Length is justified given the richness of routing and cost information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with a full output schema and safety-bearing annotations, the description covers all essential context: what the tool detects, how it differs from alternatives, when to use it, what it is not for, and an important cost caveat for EVM chains. Nothing needed for correct selection or invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameter descriptions, including chain enum semantics, address formats, validation rules, and default behavior, so the description carries no additional semantic burden. It only mentions 'address and chain' generically and notes the EVM cost difference. The baseline of 3 is appropriate because the description adds no parameter meaning beyond the schema, though it does not need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete definition: clusters of wallets around one token that behave as a single actor via buy sizing and timing, explicitly distinguishing this behavioral inference from get_wallet_links' proven links. The verb 'clusters' and the resource ('wallets around one token') make the tool's purpose unmistakable, and the explicit contrast with sibling tools removes ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: use it when supply looks distributed across small wallets and the insider graph comes back clean, and corroborate with get_fee_fingerprint on Solana. It also names exclusions with alternatives: not for proven transfer links (get_wallet_links), funding sources (get_funding_sources), or launch-window coordination (get_launch_bundles). This is exemplary usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. |
| Name | Required | Description |
|---|---|---|
| token | No | The address that was scanned (on get_token_scan, the full token metadata object instead). |
| fusion | No | Cross-signal wallet correlation; wallets list is empty on non-Pro keys. |
| signals | No | Each contributing signal: what fired, its weight and its explanation. |
| verdict | No | PROBABLY SAFE (<25), SOME RISK (25+), ELEVATED RISK (45+), HIGH RISK (60+), EXTREME RISK (75+); or a state that overrides the bands: RUGGED / DEAD, ABANDONED / DEAD, NEVER BONDED (a launchpad coin that never left its bonding curve — no pool ever existed; rugScore is still returned as a number). |
| coverage | No | "full" when the Pro signal set contributed, "free" when only the free signals did — a "free" score has seen less evidence. |
| rugScore | No | Rug probability 0 (safe) to 100 (critical). HIGHER IS MORE DANGEROUS. |
| poweredBy | No | Always "DeFade.org". |
| timestamp | No | ISO time the response was assembled. |
| scoreLabel | No | Null normally. "NEVER BONDED" when the human surfaces print that state instead of the percentage; rugScore is still the number. |
| bundleSubScore | No | The bundle component of the score. |
| proChecksLocked | No | How many Pro-only checks were withheld. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. Beyond that, the description adds the inverted score direction relative to get_token_scan, discloses the cost ('one API unit on any chain'), and states the boundary that it names signals but does not list wallets — useful context an agent cannot get from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the return semantics and the danger direction, then the usage gate, then the exclusions, then arguments. Every clause carries routing or safety information; nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 not be detailed, yet the description still summarizes the verdict/score/signals shape accurately. Combined with the routing rules, cost note and sibling pointers, an agent has everything needed to select and invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema's own descriptions already explain chain enum behavior, EVM ambiguity, address formats and rejection rules in depth. The description only restates 'Arguments: address and chain; one API unit on any chain', adding a cost note rather than new semantic meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (rug pull probability for one token) and immediately defines the output semantics: a 0-100 score where higher means more dangerous, plus a verdict label and driving signals. It explicitly distinguishes itself from the sibling get_token_scan by noting the opposite scoring direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger condition ('ONLY when the user explicitly asks for a rug probability or rug likelihood') and routes the adjacent case ('is this safe'/'should I buy') to get_token_scan. It also names get_wallet_links, get_dev_tracker and get_launch_bundles for the related question of who is behind the risk.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. |
| Name | Required | Description |
|---|---|---|
| token | No | The address that was scanned (on get_token_scan, the full token metadata object instead). |
| summary | No | analyzed, smartMoneyCount, verifiedCount, experiencedCount, activeTraderCount, retailCount, smartMoneyPct, avgWinRate, signal. |
| wallets | No | Profiled holders, each classified smart money, verified, experienced, active trader or retail, with win rate. |
| poweredBy | No | Always "DeFade.org". |
| timestamp | No | ISO time the response was assembled. |
| activeBuys | No | Other tokens the smart wallets are currently buying. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/idempotent annotations by disclosing that results are computed live from the current holder set, cached for ~5 minutes, classified by historical win rate, and cost one API unit. It also warns that a clean result is not a buy signal, which is useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: core definition, usage context, caveats, then arguments. Every sentence adds value, and none of the structured schema details are merely repeated at length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema, output schema, and annotations, the description provides all essential context: what the tool returns conceptually, how it behaves, when to use it, what it is not for, and cost. Nothing critical is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents address and chain thoroughly with formats, examples, and chain requirements. The description only adds 'one API unit on any chain,' which is cost information rather than parameter semantics, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (smart-money wallets holding/trading a token) and the specific purpose (showing who informed is in and when they got in). It also distinguishes itself from get_whales by explicitly saying it is not about wallet size.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('Use it for the bullish side of a scan') and when not to use it ('Not for risk assessment... not for wallet size'), and names the alternative get_whales. This gives clear selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. | |
| timeframe | No | Candle size, which also sets the window: 1m ≈ last 4 hours, 5m ≈ 20 hours, 15m ≈ 2.5 days (default), 30m ≈ 5 days, 1H ≈ 10 days, 4H ≈ 40 days, 1D ≈ up to 365 days. A token younger than the window returns candles from its first trade. Any other value is rejected before a request is spent. | 15m |
| Name | Required | Description |
|---|---|---|
| high | No | Window high as priceUsd plus ts; low is the same shape. |
| token | No | The address that was scanned (on get_token_scan, the full token metadata object instead). |
| candles | No | OHLCV candles, oldest first: ts (ms), open, high, low, close, volume and *Usd values. |
| current | No | Latest close as current.priceUsd. |
| poweredBy | No | Always "DeFade.org". |
| timestamp | No | ISO time the response was assembled. |
| priceChange | No | Percent change from the first candle to the last. Null when it cannot be computed. |
| totalCandles | No | Number of candles; a token with no chart data answers 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and non-destructive behavior, and the description adds substantial behavioral context: results are aggregated from DEX sources and cached for about a minute, intervals without trades are omitted, and a token with no liquidity pool returns empty candles rather than an error. This goes well beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well organized: core result first, then caching and candle behavior, then timeframe semantics, then usage examples, then exclusions, then argument notes. Every sentence adds information an agent needs to select and call the tool correctly, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return content, window determination, missing-data behavior, explicit usage alternatives, and argument caveats. With an output schema present and annotations covering the read-only safety profile, nothing an agent needs to correctly decide when and how to call this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description still adds meaningful parameter semantics by explaining that the timeframe argument fixes the window, that there is no start/end argument, and that a 0x address needs its chain. It also clarifies API unit cost and edge behavior for the address parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: '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.' It also clearly distinguishes itself from siblings by naming what it is not for, such as liquidity, market cap, and risk assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is present: '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.' It also names exclusions and alternative tools: 'not for pool depth or lock status (get_liquidity) or market cap (get_token_scan's token block).'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. |
| Name | Required | Description |
|---|---|---|
| risk | No | The SAFETY score: score (0-100, 100 is clean), rating, color, flags. Opposite direction from get_rug_score. |
| token | No | Token metadata: name, symbol, mint, supply, decimals, creator, mintAuthority, freezeAuthority, marketCap, liquidity. |
| creator | No | Deployer wallet: address, walletAgeDays, solBalance, totalTransactions, tokenCreations, recentTokens, riskLevel. |
| holders | No | Same body as get_holders: totalHolders, topHolders, concentration, protocolHoldings, lockedSupply, deferredUnlock, bundles. |
| success | No | Whether the scan completed. |
| poweredBy | No | Always "DeFade.org". |
| scanCount | No | How many times DeFade has scanned this token: the lifetime figure the rug database shows when the token has a row there (scanWindow "all"), otherwise the last 24h (scanWindow "24h"). |
| timestamp | No | ISO time the response was assembled. |
| analyzedAt | No | ISO time of the scan itself. |
| scanWindow | No | "all" when scanCount is the lifetime rug-database figure, "24h" when it is the last 24 hours only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the read-only, idempotent, non-destructive profile, so the description adds meaningful context beyond them: it explains the risk.score direction (100 = clean, low = dangerous), the rating label, that it returns a safety score, and that one API unit is consumed per call. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then succinctly covers usage, exclusions, and argument notes. Every sentence brings distinct value, and there is minimal redundancy with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, complete input schema, and existing output schema, the description covers all necessary selection and routing context. It explains when something, when not to use it, which sibling to use instead, and what the risk score means, leaving no important gap for a caller.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides strong parameter descriptions at 100% coverage, including address formats and chain rules. The description adds useful semantic context such as 'one API unit on any chain' and reinforces that address and chain must be paired, which slightly exceeds schema-only information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run a full DeFade scan on one token contract' and then enumerates the exact data categories returned. It also explicitly differentiates from siblings such as get_rug_score, get_token_price, and module-specific scanners, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says to start here for 'is this token safe', 'is this a rug pull', and 'should I buy this' questions, and explicitly directs the user to the inverse tool for rug-pull probability. It also lists concrete exclusions with alternative tools, giving agents clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tier | No | The tier this key is on. web_mcp is the connector key included with a DeFade Pro web subscription; its allowance is the plan's monthly scans, reported in plan/limits.perMonth. |
| units | No | How metering works: one request is one unit except the heaviest EVM modules, listed in heavyOnEvm with heavyCost. |
| usage | No | today, total, thisPeriod, remainingThisPeriod, periodResetsAt. |
| limits | No | perMinute, perDay, perMonth; perMonth is null on grandfathered keys. |
| credits | No | Overage: balance, overageEnabled, costPerRequest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context: the operation targets the calling key's own usage, requires no arguments, and is the right call for quota failures. No side effects are concealed, and nothing contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: what it reports, when to use it, and what it is not for. The information is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema, the description fully covers purpose, invocation context, scope, and exclusions. The output schema handles return-value details, leaving no meaningful gap for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. The description reinforces this by explicitly saying 'Takes no arguments,' which prevents an agent from trying to pass a token address despite the sibling tools all taking an address.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Report') and resource ('the calling API key's plan, rate limits and monthly allowance left'). It clearly distinguishes from sibling token-focused tools by stating this tool reports on the key itself, not a token or address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: on quota failure or when the user asks about their DeFade plan. It also provides an exclusion: not for anything about a token, and notes every other tool takes an address while this one takes none. This gives clear routing versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. |
| Name | Required | Description |
|---|---|---|
| nodes | No | Graph nodes; clusters groups them. |
| token | No | The address that was scanned (on get_token_scan, the full token metadata object instead). |
| locked | No | True on non-Pro keys, in which case only reason, upgradeUrl and message are present. |
| poweredBy | No | Always "DeFade.org". |
| timestamp | No | ISO time the response was assembled. |
| connections | No | Wallet-to-wallet transfers that tie the cohort together; connectionsTotal is the count before truncation. |
| insiderCount | No | Wallets in the connected cohort; insiderHoldingPct is the supply they hold. |
| totalTransfers | No | Transfers behind the graph, moving transferredPct of supply. |
| walletConnections | No | Per-wallet connection counts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly, idempotent, and non-destructive, and the description adds substantial behavioral context beyond that: links count only when on-chain evidence exists, top 25 real holders are traced with pools/lockers/exchanges excluded, connections is capped at 50 rows, and an empty graph does not prove independence. It also notes the API unit cost. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Though lengthy, every sentence earns its place: definition, use case, sibling differentiation, scope limits, exclusions, and cost are each addressed once. The structure front-loads the core concept, then moves to guidance, then limitations, and ends with parameter/cost notes, making the density useful rather than redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has significant nuance—scope exclusions, row caps, empty-graph semantics, and sibling tool boundaries—and the description covers all of it. The output schema exists to explain return values, so the absence of return-format detail is not a gap. An agent has everything needed to select and call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed parameter descriptions for address and chain, including validation rules and examples. The description adds only a terse 'Arguments: address and chain' summary and the API unit cost, neither of which meaningfully extends parameter semantics beyond what the schema already communicates. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: it returns a graph of proven on-chain links between wallets around a token, including funded/transferred relationships and coordinated timing. It clearly differentiates itself from sibling tools by naming get_lookalike_clusters, get_funding_sources, and get_fee_fingerprint, so an agent can distinguish it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('when the holder list looks distributed and you want to know whether it really is') and provides direct exclusions: not for the creator wallet's own sales (get_dev_tracker) and not for market data. It even instructs follow-up with get_lookalike_clusters when the graph is empty, which is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan. | solana |
| address | Yes | The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected. |
| Name | Required | Description |
|---|---|---|
| token | No | The address that was scanned (on get_token_scan, the full token metadata object instead). |
| whales | No | Each whale: address, balance, percentage of supply, attribution label (notable wallet, dev-linked, exchange), txCount24h, recent buys and sells. |
| summary | No | totalWhales, totalWhalePct, dangerWhales, activeWhales, whaleRisk, whaleThreshold, largestHumanPct, protocol and Streamflow-lock totals. |
| poweredBy | No | Always "DeFade.org". |
| timestamp | No | ISO time the response was assembled. |
| terminalUsage | No | Which trading terminals the whale cohort trades through (Pro keys). |
| protocolAccounts | No | Pools, lockers, treasuries and custodial accounts held out of the whale list, named. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld, and the description adds genuinely non-structured behavior: no pagination, a 15-minute cache that can lag activity figures, a one-API-unit cost, and a defined empty state (empty list plus largestHumanPct) so the agent can interpret a null result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the threshold definition, then row contents, then operational caveats, then routing — a sensible order with no filler sentences. The single dense paragraph is long and packs several ideas without visual separation, which slightly hurts scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool with full schema coverage, annotations and an output schema, this covers everything an agent needs: cost, caching, pagination, empty-state semantics, prerequisites (run after get_holders) and sibling routing. No material gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself documents chain semantics, defaults, address formats and rejection behavior in detail. The description only adds 'Arguments: address and chain; one API unit on any chain', which is marginal over the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (whale wallets for a token) and defines the exact inclusion threshold: at least 1% of supply after removing pools, lockers, treasuries and custodial accounts. It also enumerates the row content, distinguishing it precisely from the sibling holder and smart-money tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions itself in a workflow ('use it after get_holders when the question is about who can dump') and names three exclusions with the alternative for each: get_holders for the full ranked list, get_smart_money for historically profitable wallets, get_dev_tracker for the creator's wallet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_rug_score2 fields changedOutput schema / properties / scoreLabelAdded value: +{
+ "description": "Null normally. \"NEVER BONDED\" when the human surfaces print that state instead of the percentage; rugScore is still the number.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / verdict / descriptionPrevious value: -"PROBABLY SAFE (<25), SOME RISK (25+), ELEVATED RISK (45+), HIGH RISK (60+), EXTREME RISK (75+), or RUGGED."New value: +"PROBABLY SAFE (<25), SOME RISK (25+), ELEVATED RISK (45+), HIGH RISK (60+), EXTREME RISK (75+); or a state that overrides the bands: RUGGED / DEAD, ABANDONED / DEAD, NEVER BONDED (a launchpad coin that never left its bonding curve — no pool ever existed; rugScore is still returned as a number)."get_whales1 field changedOutput schema / properties / whales / descriptionPrevious value: -"Each whale: address, balance, percentage of supply, attribution label (KOL, dev-linked, exchange), txCount24h, recent buys and sells."New value: +"Each whale: address, balance, percentage of supply, attribution label (notable wallet, dev-linked, exchange), txCount24h, recent buys and sells."get_token_scan2 fields changedOutput schema / properties / scanCount / descriptionPrevious value: -"Scans of this token in the last 24h."New value: +"How many times DeFade has scanned this token: the lifetime figure the rug database shows when the token has a row there (scanWindow \"all\"), otherwise the last 24h (scanWindow \"24h\")."Output schema / properties / scanWindowAdded value: +{
+ "description": "\"all\" when scanCount is the lifetime rug-database figure, \"24h\" when it is the last 24 hours only.",
+ "type": [
+ "string",
+ "null"
+ ]
+}get_liquidity1 field changedOutput schema / properties / lpStatus / descriptionPrevious value: -"Headline pool verdict: BURNED, LOCKED, UNLOCKED, NO LP FOUND."New value: +"Headline pool verdict: LP BURNED, LP LOCKED, LP UNLOCKED, PARTIALLY BURNED, LP NOT LOCKABLE, BONDING CURVE, NO LP FOUND, or a spelled-out combination."get_fee_fingerprint2 fields changedInput schema / properties / chain / descriptionPrevious value: -"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."New value: +"Only solana: this tool has no implementation on other chains, and any other value is refused before a request is spent. Omit it for solana."Input schema / properties / chain / enumPrevious value: -[
- "solana",
- "ethereum",
- "base",
- "robinhood"
-]New value: +[
+ "solana"
+]get_token_price1 field changedInput schema / properties / timeframeAdded value: +{
+ "default": "15m",
+ "description": "Candle size, which also sets the window: 1m ≈ last 4 hours, 5m ≈ 20 hours, 15m ≈ 2.5 days (default), 30m ≈ 5 days, 1H ≈ 10 days, 4H ≈ 40 days, 1D ≈ up to 365 days. A token younger than the window returns candles from its first trade. Any other value is rejected before a request is spent.",
+ "enum": [
+ "1m",
+ "5m",
+ "15m",
+ "30m",
+ "1H",
+ "4H",
+ "1D"
+ ],
+ "type": "string"
+}get_usage1 field changedOutput schema / properties / tier / descriptionPrevious value: -"The tier this key is on."New value: +"The tier this key is on. web_mcp is the connector key included with a DeFade Pro web subscription; its allowance is the plan's monthly scans, reported in plan/limits.perMonth."get_rug_score3 fields changedOutput schema / properties / coverage / additionalPropertiesRemoved value: -trueOutput schema / properties / coverage / descriptionPrevious value: -"Which inputs were available; a score without liquidity or holder data is weaker and says so."New value: +"\"full\" when the Pro signal set contributed, \"free\" when only the free signals did — a \"free\" score has seen less evidence."Output schema / properties / coverage / typePrevious value: -[
- "object",
- "null"
-]New value: +[
+ "string",
+ "null"
+]get_dev_tracker11 fields changedOutput schema / properties / creatorSource / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / currentHoldingPct / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / lastActivity / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / recentSells / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / status / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / statusColor / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / totalMintedPct / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / transferRecipientAnalysis / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / transferRecipients / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]get_fee_fingerprint7 fields changedOutput schema / properties / computedAt / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / excluded / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / groups / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / pending / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / stats / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]get_funding_sources8 fields changedOutput schema / properties / computedAt / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / coveragePct / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / origins / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / risk / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / tiers / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / walletCount / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]get_holders9 fields changedOutput schema / properties / bundles / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / concentration / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / deferredUnlock / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / lockedSupply / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / protocolHoldings / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / topHolders / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / totalHolders / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]get_launch_bundles5 fields changedOutput schema / properties / bundles / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / hiddenBundleCount / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / summary / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]get_launch_snipers8 fields changedOutput schema / properties / migrationCrankersExcluded / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / reachedGenesis / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / snipers / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / stats / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / terminals / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / totalEarlyBuyers / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]get_liquidity8 fields changedOutput schema / properties / dex / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / lpBurnPct / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / lpStatus / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / poolLocks / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / risk / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / totalLiquidityUsd / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]get_lookalike_clusters6 fields changedOutput schema / properties / bands / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / computedAt / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / risk / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / stats / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]get_rug_score9 fields changedOutput schema / properties / bundleSubScore / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / coverage / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / fusion / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / proChecksLocked / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / rugScore / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / signals / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / verdict / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]get_smart_money5 fields changedOutput schema / properties / activeBuys / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / summary / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / wallets / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]get_token_price7 fields changedOutput schema / properties / candles / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / current / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / high / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / priceChange / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / totalCandles / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]get_token_scan9 fields changedOutput schema / properties / analyzedAt / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / creator / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / holders / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / risk / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / scanCount / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / success / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / token / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]get_usage5 fields changedOutput schema / properties / credits / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / limits / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / tier / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / units / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / usage / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]get_wallet_links8 fields changedOutput schema / properties / connections / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / insiderCount / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / locked / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / nodes / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / totalTransfers / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / walletConnections / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]get_whales6 fields changedOutput schema / properties / poweredBy / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / protocolAccounts / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]Output schema / properties / summary / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / terminalUsage / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / timestamp / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / whales / typePrevious value: -"array"New value: +[
+ "array",
+ "null"
+]get_bundlesget_funding_originget_funding_sourcesget_insider_networkget_launch_bundlesget_launch_snipersget_lookalike_clustersget_snipersget_sybil_clusterget_wallet_linksget_bundles1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "bundles": {
+ "description": "Each bundle: its wallets, what they spent, what they still hold, how they were funded.",
+ "type": "array"
+ },
+ "hiddenBundleCount": {
+ "description": "Bundles the shallow detector does not see.",
+ "type": "number"
+ },
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "summary": {
+ "additionalProperties": true,
+ "description": "Totals across detected bundles, accounted on peak net exposure.",
+ "type": "object"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+ }
+ },
+ "type": "object"
+}get_dev_tracker1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "creatorSource": {
+ "description": "How the dev wallet was identified; creatorInferred is true when it may be a launchpad authority rather than a person.",
+ "type": "string"
+ },
+ "currentHoldingPct": {
+ "description": "Percent of supply the dev holds now.",
+ "type": "number"
+ },
+ "lastActivity": {
+ "description": "Unix seconds of the dev's most recent move of this token.",
+ "type": "number"
+ },
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "recentSells": {
+ "description": "Transactions behind each bucket, newest first, capped.",
+ "type": "array"
+ },
+ "status": {
+ "description": "One-line verdict: STILL HOLDING, PARTIAL EXIT, FULLY EXITED, TRANSFERRED OUT, SOLD & TRANSFERRED, DISTRIBUTED, LOCKED and similar.",
+ "type": "string"
+ },
+ "statusColor": {
+ "description": "green, yellow, gray or red. A dev selling out is gray: the standard launch pattern, not a rug.",
+ "type": "string"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+ },
+ "totalMintedPct": {
+ "description": "Genesis allocation as percent of supply; totalBoughtPct, totalSoldPct, totalTransferredPct, totalLockedPct, totalLiquidityPct alongside.",
+ "type": "number"
+ },
+ "transferRecipientAnalysis": {
+ "description": "What large recipients did with the tokens: address, amountPct, stillHeldPct, verdict.",
+ "type": "array"
+ },
+ "transferRecipients": {
+ "description": "Distinct wallets that received a transfer.",
+ "type": "number"
+ }
+ },
+ "type": "object"
+}get_fee_fingerprint1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "computedAt": {
+ "description": "When this result was read.",
+ "type": "string"
+ },
+ "excluded": {
+ "description": "Fee values suppressed as client defaults, with the wallet count each covered.",
+ "type": "array"
+ },
+ "groups": {
+ "description": "One entry per fee setting shared by two or more wallets, strongest first: wallets, supplyPct bought, confidence.",
+ "type": "array"
+ },
+ "pending": {
+ "description": "True when no bundle scan has run for this token yet: nothing has looked, not nothing was found.",
+ "type": "boolean"
+ },
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "stats": {
+ "additionalProperties": true,
+ "description": "Wallets seen, how many carried a readable fee setting, how many were linked, how many set none.",
+ "type": "object"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+ }
+ },
+ "type": "object"
+}get_funding_origin1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "computedAt": {
+ "description": "When this was computed; fromCache says whether it was served from a stored result.",
+ "type": "string"
+ },
+ "coveragePct": {
+ "description": "Share of supply attributed to an origin; dexPct and bridgedPct are real states but not attribution.",
+ "type": "number"
+ },
+ "origins": {
+ "description": "Where holder supply was funded from, as { name, share }, biggest first.",
+ "type": "array"
+ },
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "risk": {
+ "additionalProperties": true,
+ "description": "Verdict with label and severity.",
+ "type": "object"
+ },
+ "tiers": {
+ "description": "The same supply grouped by certainty tier, as { tier, share }.",
+ "type": "array"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+ },
+ "walletCount": {
+ "description": "Wallets resolved, with resolvedCount and unknownCount.",
+ "type": "number"
+ }
+ },
+ "type": "object"
+}get_holders1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "bundles": {
+ "additionalProperties": true,
+ "description": "Shallow bundle detection over the real wallets: detected, bundlePct, groups.",
+ "type": "object"
+ },
+ "concentration": {
+ "additionalProperties": true,
+ "description": "top5, top10, top20 as percent of supply, counting real wallets only.",
+ "type": "object"
+ },
+ "deferredUnlock": {
+ "additionalProperties": true,
+ "description": "Supply that unlocks back to the deployer later: pct, unlockDate, cancelablePct. Null when none.",
+ "type": "object"
+ },
+ "lockedSupply": {
+ "additionalProperties": true,
+ "description": "pct plus a lockers array naming each escrow.",
+ "type": "object"
+ },
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "protocolHoldings": {
+ "additionalProperties": true,
+ "description": "What was excluded: count and totalPct.",
+ "type": "object"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+ },
+ "topHolders": {
+ "description": "Top 20 accounts: rank, address, walletAddress, amount, percentage, solBalance, isProtocol, protocolLabel.",
+ "type": "array"
+ },
+ "totalHolders": {
+ "description": "Holder count, estimated from the top accounts.",
+ "type": "number"
+ }
+ },
+ "type": "object"
+}get_insider_network1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "connections": {
+ "description": "Wallet-to-wallet transfers that tie the cohort together; connectionsTotal is the count before truncation.",
+ "type": "array"
+ },
+ "insiderCount": {
+ "description": "Wallets in the connected cohort; insiderHoldingPct is the supply they hold.",
+ "type": "number"
+ },
+ "locked": {
+ "description": "True on non-Pro keys, in which case only reason, upgradeUrl and message are present.",
+ "type": "boolean"
+ },
+ "nodes": {
+ "description": "Graph nodes; clusters groups them.",
+ "type": "array"
+ },
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+ },
+ "totalTransfers": {
+ "description": "Transfers behind the graph, moving transferredPct of supply.",
+ "type": "number"
+ },
+ "walletConnections": {
+ "additionalProperties": true,
+ "description": "Per-wallet connection counts.",
+ "type": "object"
+ }
+ },
+ "type": "object"
+}get_liquidity1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "dex": {
+ "description": "Which DEX holds the deepest pool.",
+ "type": "string"
+ },
+ "lpBurnPct": {
+ "description": "Percent of LP tokens burned; lpLockPct is the percent locked.",
+ "type": "number"
+ },
+ "lpStatus": {
+ "description": "Headline pool verdict: BURNED, LOCKED, UNLOCKED, NO LP FOUND.",
+ "type": "string"
+ },
+ "poolLocks": {
+ "description": "Per-pool lock detail with lpLockable and an lpNote in words.",
+ "type": "array"
+ },
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "risk": {
+ "description": "Liquidity risk label; lpEvidence carries the on-chain evidence behind it.",
+ "type": "string"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+ },
+ "totalLiquidityUsd": {
+ "description": "Combined USD depth across pools; pools lists them and poolCount counts them.",
+ "type": "number"
+ }
+ },
+ "type": "object"
+}get_rug_score1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "bundleSubScore": {
+ "description": "The bundle component of the score.",
+ "type": "number"
+ },
+ "coverage": {
+ "additionalProperties": true,
+ "description": "Which inputs were available; a score without liquidity or holder data is weaker and says so.",
+ "type": "object"
+ },
+ "fusion": {
+ "additionalProperties": true,
+ "description": "Cross-signal wallet correlation; wallets list is empty on non-Pro keys.",
+ "type": "object"
+ },
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "proChecksLocked": {
+ "description": "How many Pro-only checks were withheld.",
+ "type": "number"
+ },
+ "rugScore": {
+ "description": "Rug probability 0 (safe) to 100 (critical). HIGHER IS MORE DANGEROUS.",
+ "type": "number"
+ },
+ "signals": {
+ "description": "Each contributing signal: what fired, its weight and its explanation.",
+ "type": "array"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+ },
+ "verdict": {
+ "description": "PROBABLY SAFE (<25), SOME RISK (25+), ELEVATED RISK (45+), HIGH RISK (60+), EXTREME RISK (75+), or RUGGED.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}get_smart_money1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "activeBuys": {
+ "description": "Other tokens the smart wallets are currently buying.",
+ "type": "array"
+ },
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "summary": {
+ "additionalProperties": true,
+ "description": "analyzed, smartMoneyCount, verifiedCount, experiencedCount, activeTraderCount, retailCount, smartMoneyPct, avgWinRate, signal.",
+ "type": "object"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+ },
+ "wallets": {
+ "description": "Profiled holders, each classified smart money, verified, experienced, active trader or retail, with win rate.",
+ "type": "array"
+ }
+ },
+ "type": "object"
+}get_snipers1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "migrationCrankersExcluded": {
+ "description": "Migration-crank MEV bots filtered out as infrastructure, named.",
+ "type": "array"
+ },
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "reachedGenesis": {
+ "description": "Whether the walk reached the true first transaction. When false, partial is true and small snipers may be missing.",
+ "type": "boolean"
+ },
+ "snipers": {
+ "description": "Wallets that bought inside the launch window, capped at 30 rows.",
+ "type": "array"
+ },
+ "stats": {
+ "additionalProperties": true,
+ "description": "Cohort totals for the window.",
+ "type": "object"
+ },
+ "terminals": {
+ "additionalProperties": true,
+ "description": "Trading terminals the launch cohort came through; activeTerminals is who trades it now.",
+ "type": "object"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+ },
+ "totalEarlyBuyers": {
+ "description": "How many were found in total; windowSeconds and firstTxTime describe the window.",
+ "type": "number"
+ }
+ },
+ "type": "object"
+}get_sybil_cluster1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "bands": {
+ "description": "Wallet clusters banded by how strongly they look like one operator.",
+ "type": "array"
+ },
+ "computedAt": {
+ "description": "When this was computed; fromCache says whether it was served from a stored result.",
+ "type": "string"
+ },
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "risk": {
+ "additionalProperties": true,
+ "description": "Verdict for the token with label and severity.",
+ "type": "object"
+ },
+ "stats": {
+ "additionalProperties": true,
+ "description": "Totals across the bands: wallets clustered and the supply they hold.",
+ "type": "object"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+ }
+ },
+ "type": "object"
+}get_token_price1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "candles": {
+ "description": "OHLCV candles, oldest first: ts (ms), open, high, low, close, volume and *Usd values.",
+ "type": "array"
+ },
+ "current": {
+ "additionalProperties": true,
+ "description": "Latest close as current.priceUsd.",
+ "type": "object"
+ },
+ "high": {
+ "additionalProperties": true,
+ "description": "Window high as priceUsd plus ts; low is the same shape.",
+ "type": "object"
+ },
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "priceChange": {
+ "description": "Percent change from the first candle to the last. Null when it cannot be computed.",
+ "type": "number"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+ },
+ "totalCandles": {
+ "description": "Number of candles; a token with no chart data answers 0.",
+ "type": "number"
+ }
+ },
+ "type": "object"
+}get_token_scan1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "analyzedAt": {
+ "description": "ISO time of the scan itself.",
+ "type": "string"
+ },
+ "creator": {
+ "additionalProperties": true,
+ "description": "Deployer wallet: address, walletAgeDays, solBalance, totalTransactions, tokenCreations, recentTokens, riskLevel.",
+ "type": "object"
+ },
+ "holders": {
+ "additionalProperties": true,
+ "description": "Same body as get_holders: totalHolders, topHolders, concentration, protocolHoldings, lockedSupply, deferredUnlock, bundles.",
+ "type": "object"
+ },
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "risk": {
+ "additionalProperties": true,
+ "description": "The SAFETY score: score (0-100, 100 is clean), rating, color, flags. Opposite direction from get_rug_score.",
+ "type": "object"
+ },
+ "scanCount": {
+ "description": "Scans of this token in the last 24h.",
+ "type": "number"
+ },
+ "success": {
+ "description": "Whether the scan completed.",
+ "type": "boolean"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "additionalProperties": true,
+ "description": "Token metadata: name, symbol, mint, supply, decimals, creator, mintAuthority, freezeAuthority, marketCap, liquidity.",
+ "type": "object"
+ }
+ },
+ "type": "object"
+}get_usage1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "credits": {
+ "additionalProperties": true,
+ "description": "Overage: balance, overageEnabled, costPerRequest.",
+ "type": "object"
+ },
+ "limits": {
+ "additionalProperties": true,
+ "description": "perMinute, perDay, perMonth; perMonth is null on grandfathered keys.",
+ "type": "object"
+ },
+ "tier": {
+ "description": "The tier this key is on.",
+ "type": "string"
+ },
+ "units": {
+ "additionalProperties": true,
+ "description": "How metering works: one request is one unit except the heaviest EVM modules, listed in heavyOnEvm with heavyCost.",
+ "type": "object"
+ },
+ "usage": {
+ "additionalProperties": true,
+ "description": "today, total, thisPeriod, remainingThisPeriod, periodResetsAt.",
+ "type": "object"
+ }
+ },
+ "type": "object"
+}get_whales1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "poweredBy": {
+ "description": "Always \"DeFade.org\".",
+ "type": "string"
+ },
+ "protocolAccounts": {
+ "description": "Pools, lockers, treasuries and custodial accounts held out of the whale list, named.",
+ "type": "array"
+ },
+ "summary": {
+ "additionalProperties": true,
+ "description": "totalWhales, totalWhalePct, dangerWhales, activeWhales, whaleRisk, whaleThreshold, largestHumanPct, protocol and Streamflow-lock totals.",
+ "type": "object"
+ },
+ "terminalUsage": {
+ "additionalProperties": true,
+ "description": "Which trading terminals the whale cohort trades through (Pro keys).",
+ "type": "object"
+ },
+ "timestamp": {
+ "description": "ISO time the response was assembled.",
+ "type": "string"
+ },
+ "token": {
+ "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+ },
+ "whales": {
+ "description": "Each whale: address, balance, percentage of supply, attribution label (KOL, dev-linked, exchange), txCount24h, recent buys and sells.",
+ "type": "array"
+ }
+ },
+ "type": "object"
+}get_bundles2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_dev_tracker2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_fee_fingerprint2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_funding_origin2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_holders2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_insider_network2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_liquidity2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_rug_score2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_smart_money2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_snipers2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_sybil_cluster2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_token_price2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_token_scan2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_whales2 fields changedInput schema / properties / address / descriptionPrevious value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."Input schema / properties / chain / descriptionPrevious value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."get_api_usageget_token_scanget_usagescan_tokencheck_api_usageget_api_usageget_bundlesget_bundles_procompare_holder_overlapget_bundlesget_socialsget_trendingcheck_api_usagecompare_holder_overlapget_bundlesget_bundles_proget_dev_trackerget_fee_fingerprintget_funding_originget_holdersget_insider_networkget_liquidityget_rug_scoreget_smart_moneyget_snipersget_socialsget_sybil_clusterget_token_priceget_trendingget_whalesscan_tokenInstant rug-check for any EVM or Solana token, distilled to one clear 0-10 risk verdict.
Honeypot detection & token risk scan for ERC-20s. Risk score 0-100, tax, source verification.
Solana token safety for AI agents — rug-pull, honeypot & Token-2022 trap detection before you buy.
Token Risk — rug-pull / honeypot screening for crypto tokens.
Add one secure layer between your agents and this server.
