Skip to main content
Glama

DeFade — Multi-Chain Memecoin Analyzer

by org.defade
OverviewDiscussionsAdmin

Launch-window bundles

get_launch_bundles
Read-onlyIdempotent

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.

Input Schema

NameRequiredDescriptionDefault
chainNoChain the token is deployed on: solana (default), ethereum, base, bsc, robinhood, arc, hyperevm, monad. 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
addressYesThe 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.

Output Schema

NameRequiredDescriptionDefault
tokenNoThe address that was scanned (on get_token_scan, the full token metadata object instead).
bundlesNoEach bundle: its wallets, what they spent, what they still hold, how they were funded.
summaryNoTotals across detected bundles, accounted on peak net exposure. summary.transferredUnsoldPct is the transferred share the DeFade website prints (moved out and not sold since); transferredPct counts every transfer out, a token each time it moved, and is not a share to quote.
poweredByNoAlways "DeFade.org".
timestampNoISO time the response was assembled.
hiddenBundleCountNoBundles the shallow detector does not see.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / chain / description
      Previous value: -"Chain the token is deployed on: solana (default), ethereum, base, bsc, robinhood, arc, hyperevm. 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: +"Chain the token is deployed on: solana (default), ethereum, base, bsc, robinhood, arc, hyperevm, monad. 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."
    • changedInput schema / properties / chain / enum
      Previous value: -[
-  "solana",
-  "ethereum",
-  "base",
-  "bsc",
-  "robinhood",
-  "arc",
-  "hyperevm"
-]New value: +[
+  "solana",
+  "ethereum",
+  "base",
+  "bsc",
+  "robinhood",
+  "arc",
+  "hyperevm",
+  "monad"
+]
  2. Changed1 schema field changed
    • changedOutput schema / properties / summary / description
      Previous value: -"Totals across detected bundles, accounted on peak net exposure."New value: +"Totals across detected bundles, accounted on peak net exposure. summary.transferredUnsoldPct is the transferred share the DeFade website prints (moved out and not sold since); transferredPct counts every transfer out, a token each time it moved, and is not a share to quote."
  3. Changed2 schema fields changed
    • changedInput schema / properties / chain / description
      Previous 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: +"Chain the token is deployed on: solana (default), ethereum, base, bsc, robinhood, arc, hyperevm. 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."
    • changedInput schema / properties / chain / enum
      Previous value: -[
-  "solana",
-  "ethereum",
-  "base",
-  "robinhood"
-]New value: +[
+  "solana",
+  "ethereum",
+  "base",
+  "bsc",
+  "robinhood",
+  "arc",
+  "hyperevm"
+]
  4. Changed5 schema fields changed
    • changedOutput schema / properties / bundles / type
      Previous value: -"array"New value: +[
+  "array",
+  "null"
+]
    • changedOutput schema / properties / hiddenBundleCount / type
      Previous value: -"number"New value: +[
+  "number",
+  "null"
+]
    • changedOutput schema / properties / poweredBy / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / properties / summary / type
      Previous value: -"object"New value: +[
+  "object",
+  "null"
+]
    • changedOutput schema / properties / timestamp / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
  5. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the description spends its space on what annotations cannot say: the detection methodology, the interpretive warning that held bundling is a strong rug predictor, and the cost (one API unit on any chain). It does not mention latency or empty-result behavior, which keeps it just short of a 5.

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

Conciseness4/5

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

Front-loaded with the core definition, then usage, then exclusions, then arguments — a sensible order. It is a single dense paragraph with some redundancy in the caveat clauses, but no sentence is truly wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return values, and it does not try. Instead it covers the interpretive frame (why peak exposure accounting matters), the sibling boundaries, and the unit cost — everything an agent needs to select and call it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already explains the chain/address matching rules, formats, and rejection behavior in depth. The description's "Arguments: address and chain" plus the cost note add almost nothing beyond what the schema states, so this lands at the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (bundle detection for one token) and immediately qualifies the scope: coordinated buys in the launch window plus delayed sweeps. It even clarifies the accounting model (peak net exposure vs raw buy count), which is what makes this tool distinct from a naive buy-count scan.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the question it answers ("was this launch bundled") and then lists three exclusions mapped to named siblings: get_launch_snipers for lone fast buyers, get_lookalike_clusters for post-launch clusters, get_dev_tracker for creator selling. Nothing is left to inference about when to pick this over an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All DeFade — Multi-Chain Memecoin Analyzer toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources