Skip to main content
Glama

DeFade — Multi-Chain Memecoin Analyzer

by org.defade
OverviewDiscussionsAdmin

Proven insider links

get_wallet_links
Read-onlyIdempotent

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.

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
nodesNoGraph nodes; clusters groups them.
tokenNoThe address that was scanned (on get_token_scan, the full token metadata object instead).
lockedNoTrue on non-Pro keys, in which case only reason, upgradeUrl and message are present.
poweredByNoAlways "DeFade.org".
timestampNoISO time the response was assembled.
connectionsNoWallet-to-wallet transfers that tie the cohort together; connectionsTotal is the count before truncation.
insiderCountNoWallets in the connected cohort; insiderHoldingPct is the supply they hold.
totalTransfersNoTransfers behind the graph, moving transferredPct of supply.
walletConnectionsNoPer-wallet connection counts.

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. 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"
+]
  3. Changed8 schema fields changed
    • changedOutput schema / properties / connections / type
      Previous value: -"array"New value: +[
+  "array",
+  "null"
+]
    • changedOutput schema / properties / insiderCount / type
      Previous value: -"number"New value: +[
+  "number",
+  "null"
+]
    • changedOutput schema / properties / locked / type
      Previous value: -"boolean"New value: +[
+  "boolean",
+  "null"
+]
    • changedOutput schema / properties / nodes / type
      Previous value: -"array"New value: +[
+  "array",
+  "null"
+]
    • changedOutput schema / properties / poweredBy / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / properties / timestamp / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / properties / totalTransfers / type
      Previous value: -"number"New value: +[
+  "number",
+  "null"
+]
    • changedOutput schema / properties / walletConnections / type
      Previous value: -"object"New value: +[
+  "object",
+  "null"
+]
  4. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely non-obvious behavior: scope is the top 25 real holders with pools/lockers/exchanges excluded, results capped at 50 rows with connectionsTotal as the true count, and an empty graph means 'no link found' rather than independence. It also discloses cost (one API unit on any chain). This is beyond what any structured field conveys.

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 concept and the routing comparison, which is the right order. It is dense — the sibling enumeration runs long — but nearly every clause carries decision-relevant information; only the four-way sibling sweep is slightly heavier than needed.

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

Completeness5/5

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

An output schema exists, so return shape needn't be explained, and the description still covers the interpretation trap (empty graph ≠ independent) and the connections/connectionsTotal relationship. For a graph tool with two params, nothing an agent needs to call or interpret it is missing.

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

Parameters3/5

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

Schema coverage is 100% and the chain enum plus address format rules are already fully documented in the schema, including the 0x-needs-chain rule. The description's 'Arguments: address and chain' restates rather than adds. Baseline 3 is appropriate when the schema does all the work.

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 (the graph of proven on-chain links between wallets around one token) and immediately names the mechanism — funding, transfers, coordinated timing. It explicitly distinguishes itself from three named siblings, so an agent can route without opening any schema.

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?

Gives an explicit trigger ('when the holder list looks distributed and you want to know whether it really is'), names the alternative for each adjacent case (get_lookalike_clusters for behavioral similarity, get_funding_sources for first money on chain, get_fee_fingerprint for bot fee settings), and states exclusions (not get_dev_tracker, not market data).

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