DeFade — Multi-Chain Memecoin Analyzer

Shared fee-setting fingerprint

get_fee_fingerprint

Read-onlyIdempotent

Wallets whose transactions pin an identical fee setting — compute-unit price or Jito tip on Solana, priority fee or legacy gas price on EVM chains — one operator's bot settings showing up across every wallet it drives. This is the shared-CONFIGURATION member of the "who is really behind this token" family (proven transfers: get_wallet_links; funding origin: get_funding_sources; behavioural twins: get_lookalike_clusters), not a timing link: it never proves bundling, and two wallets can match days apart. Use it to corroborate get_lookalike_clusters, and to catch the operator who sold their launch wallets and re-entered through fresh ones; read a match as corroboration, never as proof of coordinated buying. Groups are strongest first; pending true means no bundle scan has run for this token yet, so nothing has looked rather than nothing was found. Arguments: address and chain; one API unit on any chain, because it reads what the bundle scan already computed.

Input Schema

Name	Required	Description	Default
`chain`	No	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.	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

Name	Required	Description
`stats`	No	Wallets seen, how many carried a readable fee setting, how many were linked, how many set none.
`token`	No	The address that was scanned (on get_token_scan, the full token metadata object instead).
`groups`	No	One entry per fee setting shared by two or more wallets, strongest first: wallets, supplyPct bought, confidence. Only a confidence of 60 or more is evidence of one operator; below it, strangers can share the value. router names the app the group came through (an EVM public router, a Solana terminal) when the value is that app's preset or automatic fee.
`pending`	No	True when no bundle scan has run for this token yet: nothing has looked, not nothing was found.
`excluded`	No	Fee values too common to link anyone, with the wallet count each covered and a reason: generic_default (a value most of the launch used) or, on EVM, round_preset (a round tip an app or wallet sets for every user).
`poweredBy`	No	Always "DeFade.org".
`timestamp`	No	ISO time the response was assembled.
`computedAt`	No	When this result was read.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 28, 2026

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

Changed1 schema field changedOct 20, 2026

changedOutput schema / properties / groups / description

Previous value: -"One entry per fee setting shared by two or more wallets, strongest first: wallets, supplyPct bought, confidence. Only a confidence of 60 or more is evidence of one operator; below it, strangers can share the value. On EVM, router names the public router whose buyers mostly paid the group's tip, when that explains it."New value: +"One entry per fee setting shared by two or more wallets, strongest first: wallets, supplyPct bought, confidence. Only a confidence of 60 or more is evidence of one operator; below it, strangers can share the value. router names the app the group came through (an EVM public router, a Solana terminal) when the value is that app's preset or automatic fee."

Changed1 schema field changedOct 20, 2026

changedOutput schema / properties / groups / description

Previous value: -"One entry per fee setting shared by two or more wallets, strongest first: wallets, supplyPct bought, confidence. Only a confidence of 60 or more is evidence of one operator; below it, strangers can share the value."New value: +"One entry per fee setting shared by two or more wallets, strongest first: wallets, supplyPct bought, confidence. Only a confidence of 60 or more is evidence of one operator; below it, strangers can share the value. On EVM, router names the public router whose buyers mostly paid the group's tip, when that explains it."

Changed2 schema fields changedOct 20, 2026

changedOutput schema / properties / excluded / description

Previous value: -"Fee values suppressed as client defaults, with the wallet count each covered."New value: +"Fee values too common to link anyone, with the wallet count each covered and a reason: generic_default (a value most of the launch used) or, on EVM, round_preset (a round tip an app or wallet sets for every user)."

changedOutput schema / properties / groups / description

Previous value: -"One entry per fee setting shared by two or more wallets, strongest first: wallets, supplyPct bought, confidence."New value: +"One entry per fee setting shared by two or more wallets, strongest first: wallets, supplyPct bought, confidence. Only a confidence of 60 or more is evidence of one operator; below it, strangers can share the value."

Changed2 schema fields changedOct 10, 2026

changedInput schema / properties / chain / description

Previous value: -"Only solana: this tool has no implementation on other chains, and any other value is refused before a request is spent. Omit it for solana."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"
-]New value: +[
+  "solana",
+  "ethereum",
+  "base",
+  "bsc",
+  "robinhood",
+  "arc",
+  "hyperevm"
+]

Changed2 schema fields changedSep 6, 2026

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: +"Only solana: this tool has no implementation on other chains, and any other value is refused before a request is spent. Omit it for solana."

changedInput schema / properties / chain / enum

Previous value: -[
-  "solana",
-  "ethereum",
-  "base",
-  "robinhood"
-]New value: +[
+  "solana"
+]

Changed7 schema fields changedSep 5, 2026

changedOutput schema / properties / computedAt / type

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

changedOutput schema / properties / excluded / type

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

changedOutput schema / properties / groups / type

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

changedOutput schema / properties / pending / type

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

changedOutput schema / properties / poweredBy / type

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

changedOutput schema / properties / stats / type

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

changedOutput schema / properties / timestamp / type

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

Changed1 schema field changedSep 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "computedAt": {
+      "description": "When this result was read.",
+      "type": "string"
+    },
+    "excluded": {
+      "description": "Fee values suppressed as client defaults, with the wallet count each covered.",
+      "type": "array"
+    },
+    "groups": {
+      "description": "One entry per fee setting shared by two or more wallets, strongest first: wallets, supplyPct bought, confidence.",
+      "type": "array"
+    },
+    "pending": {
+      "description": "True when no bundle scan has run for this token yet: nothing has looked, not nothing was found.",
+      "type": "boolean"
+    },
+    "poweredBy": {
+      "description": "Always \"DeFade.org\".",
+      "type": "string"
+    },
+    "stats": {
+      "additionalProperties": true,
+      "description": "Wallets seen, how many carried a readable fee setting, how many were linked, how many set none.",
+      "type": "object"
+    },
+    "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)."
+    }
+  },
+  "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.8/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/open-world, but the description adds substantive behavior beyond them: cost ('one API unit on any chain, because it reads what the bundle scan already computed'), the semantics of the 'pending' flag ('nothing has looked rather than nothing was found'), and an explicit epistemic limit ('two wallets can match days apart'). That is real interpretive context, not restated 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?

Front-loaded with the definition, then the family/anti-confusion clause, then usage, then argument cost — a sensible order with no filler. It is a dense, dash-heavy single block that takes effort to parse, which costs it a point on readability.

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?

For a read-only lookup with a full schema and an output schema, everything an agent needs is present: what it computes, how it differs from adjacent tools, how much it costs, how to read a match, and how to interpret the pending state. Return-value shape is rightly left to the output schema.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description adds a small amount on top by framing the two arguments and explaining that cost is flat across chains because results are derived from a prior scan. It does not add syntax or format detail beyond the schema, so it stops short of 5.

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?

Names a specific resource and mechanism: wallets whose transactions pin an identical fee setting, with the concrete signals per chain (compute-unit price / Jito tip on Solana, priority fee / legacy gas price on EVM). It also explicitly places itself in the family and names the sibling it is not (not a timing link like the bundle tools), so an agent can discriminate 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?

Gives explicit when-to-use ('corroborate get_lookalike_clusters', catch operators who re-entered through fresh wallets) and when-not ('never proves bundling', 'read a match as corroboration, never as proof of coordinated buying'). It even names the three sibling tools covering the other evidence types (get_wallet_links, get_funding_sources, get_lookalike_clusters), which is exactly the routing information an agent needs.

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

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

Need Help?