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

TableJSON Schema
NameRequiredDescriptionDefault
chainNoChain 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
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

TableJSON 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. 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"
+]
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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