DeFade

Official

by DeFadeLtd

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Dev wallet tracking

get_dev_tracker

Read-onlyIdempotent

Analyze a token creator's holdings and transfers to detect rug pull risk. See if the dev still holds, sold out, or moved funds to fresh wallets—key warning signals.

Instructions

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.

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.

Changed11 schema fields changedv0.2.3Sep 7, 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"
+]

First observedv0.1.0Sep 5, 2026

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server