DeFade — Multi-Chain Memecoin Analyzer

Dev wallet tracking

get_dev_tracker

Read-onlyIdempotent

What the token's creator has done with their supply: the share they still hold, what left through sales versus transfers, and where the transfers went. Read the state carefully: still holding is neutral, fully exited on a fresh token is a warning, and transferred out to fresh wallets is the single strongest rug signal DeFade tracks. Not for wallets other than the creator (get_whales, get_wallet_links); the creator's earlier launches are already served by get_token_scan's creator block (tokenCreations, recentTokens). Arguments: address and chain; one API unit on any chain.

Input Schema

TableJSON Schema

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.

Output Schema

TableJSON Schema

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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed11 schema fields changedSep 5, 2026

changedOutput schema / properties / creatorSource / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / currentHoldingPct / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

changedOutput schema / properties / lastActivity / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

changedOutput schema / properties / poweredBy / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / recentSells / type

Previous value: -"array"New value: +[
+  "array",
+  "null"
+]

changedOutput schema / properties / status / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / statusColor / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / timestamp / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / totalMintedPct / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

changedOutput schema / properties / transferRecipientAnalysis / type
```
Previous value: -"array"New value: +[
+  "array",
+  "null"
+]
```

changedOutput schema / properties / transferRecipients / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

Changed1 schema field changedSep 3, 2026

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"
+}

Changed2 schema fields changedSep 3, 2026

changedInput schema / properties / address / description

Previous 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."

changedInput schema / properties / chain / description

Previous 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."

First observedSep 1, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond annotations by disclosing the API-unit cost and explaining how to interpret the output states, including which pattern is the strongest rug signal. This is meaningful behavioral context without contradicting 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.

Conciseness5/5

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

Four sentences, each earning its place: the first defines the output, the second provides interpretive guidance, the third routes to siblings, and the fourth covers arguments and cost. It is front-loaded with the core purpose and contains no filler or repetition.

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 description is complete given the rich schema and annotations: it explains what the tool returns, how to interpret the result, when not to use it, which alternatives exist, and what the API call costs. The presence of an output schema and read-only/idempotent annotations means no critical behavioral or return-format information 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?

The input schema covers both parameters at 100% and includes rich detail such as address formats, chain enum values, defaults, and rejection behavior. The description only briefly mentions 'address and chain; one API unit on any chain,' adding little beyond the schema, so the baseline score of 3 applies.

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 states a specific verb and resource: it reports what a token's creator did with their supply, including share still held, sales versus transfers, and transfer destinations. It also distinguishes itself from sibling tools by explicitly stating it is not for arbitrary wallets and that creator launch history is covered by get_token_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?

The description gives explicit when-not-to-use guidance: it is not for wallets other than the creator, and get_whales/get_wallet_links are named as the alternatives for those cases. It also routes adjacent needs (earlier launches) to get_token_scan's creator block, leaving no ambiguity about which tool to choose.

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 tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Every tool targets a distinct forensic question — creator behavior, launch coordination, lone snipers, proven wallet links, behavioral similarity, config matching — and each description explicitly names which sibling tools it is NOT for. Even the near-inverse pair get_rug_score (danger probability) and get_token_scan (safety score) is handled with explicit call-routing rules. No two tools have unclear boundaries.

Naming Consistency5/5

All 15 tools follow the identical get_<noun> pattern with snake_case throughout: get_holders, get_whales, get_token_scan, get_usage. The verb is uniform and the noun precisely names the resource or analysis domain, making the surface trivially predictable.

Tool Count5/5

15 tools sits at the upper edge of the well-scoped range, and each tool earns its place as a distinct analysis module for the broad multi-chain memecoin forensics domain. Nothing feels redundant — the count reflects the genuine breadth of the domain: launch, holders, liquidity, forensics, market data, and quota.

Completeness4/5

The token risk-assessment lifecycle is thoroughly covered: scan → rug score → holders → whales → dev tracker → launch → liquidity → forensics → price → usage form a complete investigation pathway with no dead ends. Minor gaps exist: no long historical price data (get_token_price only returns recent candles) and no token discovery/search — the server assumes you already have an address. These are work-aroundable but arguably core for a full analyzer.

Resources

Need Help?