Which integrations are available for this server?

Provides token whale activity, smart-money radar, insider cluster/cabal audits, and wallet copy-trade profiling for Ethereum. Provides token whale activity, smart-money radar, insider cluster/cabal audits, and wallet copy-trade profiling for Polygon. Provides token whale activity, smart-money radar, insider cluster/cabal audits, and wallet copy-trade profiling for Solana.

Whale402

by monsterbyurbed11

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

🐋 Whale402 — Smart Money Whale Radar, Insider Cabal Audits & Copy-Trade Profiler MCP

Glama MCP Server npm version License: MIT

Real-time Smart Money Whale Radar, Insider Sybil Cluster & Cabal Bundling Audits, and Wallet Copy-Trading Performance Profiler for autonomous AI Agents, Trading Bots, Claude Desktop, and Cursor across Base, Solana, Ethereum, Arbitrum, BSC, and Polygon.

🎁 Zero-Config Free Tier (3 Free Calls / Day): Run immediately in Claude Desktop, Cursor, Glama, or Smithery with no wallet setup required for your first 3 queries every day.
⚡ Instant Prepaid Base USDC Credits ($1.00 = 50 Whale Scans / 33 Cabal Audits / 100 Wallet Profiles): Send $1.00 USDC once on Base to 0x8a8c238ed2b46908Ff6C6922a3870984f20f8913 and pass your transaction hash (0x...) for sub-15ms credit deduction with zero RPC confirmation lag.
🪙 Official Coinbase x402 Standard (x402Version: 1): Compatible out-of-the-box with x402-fetch, x402-axios, and Coinbase CDP AgentKit.
🛡️ Fail-Closed High-Stakes Security: Never provides false-safe reports on low-liquidity or unverified pools.

🌐 Production Gateway: https://whale402.acter.workers.dev
📊 Live Funnel & Revenue Analytics: https://whale402.acter.workers.dev/v1/analytics

📦 Quick Start: MCP Server (Claude Desktop, Cursor, Cline, Windsurf, Glama)

Run directly via npx (first 3 calls/day are 100% free; optionally add WHALE402_TX_HASH for unlimited prepaid calls):

{
  "mcpServers": {
    "whale402": {
      "command": "npx",
      "args": ["-y", "whale402-mcp"],
      "env": {
        "WHALE402_TX_HASH": "0x_OPTIONAL_PREPAID_BASE_USDC_TX_HASH"
      }
    }
  }
}

Available MCP Tools & REST Endpoints

Tool / Endpoint	Free Tier	Unlimited Price	Description
`get_token_whale_activity` / `GET /v1/token-whales`	3 Free / Day	$0.02 USDC	Inspects top holders, Smart Money net inflow ($), whale dominance %, and computes `WhaleAccumulationScore` (0-100).
`get_smart_money_radar` / `GET /v1/smart-money-radar`	3 Free / Day	$0.02 USDC	Scans newly active & trending tokens on Base/Solana/ETH currently accumulated by verified high-win-rate (>70%) wallets.
`detect_insider_clusters` / `GET /v1/insider-cluster`	3 Free / Day	$0.03 USDC	Graph analysis on top holders detecting shared gas funding roots, Sybil bundling, and dev cabal distribution.
`profile_wallet_smart_money` / `GET /v1/wallet-profiler`	3 Free / Day	$0.01 USDC	Profiles historical trade history, Win Rate %, realized PnL, 30-day ROI, hold duration, and assigns a `CopyTradeGrade` (`A+` to `F`).
`get_credits_and_payment_info` / `GET /v1/credits`	Always Free	$0.00 (Free)	Check remaining prepaid USDC credit balance for any `0x...` txHash or get deposit instructions.

Related MCP server: CabalSpy Wallet Tracker MCP

⚡ Instant Multi-Call Prepaid Credits (Built for High-Speed Trading Bots)

Per-request on-chain transfers are too slow for automated trading agents. Whale402 solves this automatically:

Send any amount $\ge $0.01$ USDC on Base to 0x8a8c238ed2b46908Ff6C6922a3870984f20f8913 (e.g., $1.00 USDC = 1,000,000 units).
Pass paymentProof: "0x<your_tx_hash>" in any MCP tool call or Authorization: x402 0x<your_tx_hash> on REST requests.
Call #1 verifies the receipt on Base RPC and initializes your credit balance ($0.98 remaining = 49 more whale scans or 98 wallet profiles).
Subsequent Calls skip Base RPC completely and deduct credits in < 15ms, returning X-402-Credits-Remaining-USDC and X-402-Calls-Remaining headers on every response!

💡 Example API Usage

1. Check Smart Money Accumulation on a Token

curl "https://whale402.acter.workers.dev/v1/token-whales?network=base&tokenAddress=0x0578d8a44db98b23bf096a382e016e29a5ce0ffe"

Response:

{
  "success": true,
  "data": {
    "tokenAddress": "0x0578d8a44db98b23bf096a382e016e29a5ce0ffe",
    "network": "base",
    "symbol": "HIGHER",
    "whaleAccumulationScore": 84,
    "signal": "STRONG_ACCUMULATION",
    "smartMoneyNetInflow24hUsd": 42180,
    "whaleDominancePct": 38.4,
    "totalWhalesTracking": 8,
    "topHolders": [
      {
        "address": "0x4b2...8f1",
        "tier": "APEX_WHALE",
        "historicalWinRatePct": 82,
        "realizedPnlUsd": 412000,
        "supplyPct": 9.2
      }
    ]
  }
}

2. Audit Sybil Bundling & Dev Cabal Risk

curl "https://whale402.acter.workers.dev/v1/insider-cluster?network=base&tokenAddress=0x0578d8a44db98b23bf096a382e016e29a5ce0ffe"

Response:

{
  "success": true,
  "data": {
    "clusterRisk": "LOW",
    "bundledSupplyPct": 4.2,
    "totalInsidersDetected": 0,
    "cabalScore": 14,
    "verdict": "PASSED: Organic decentralized distribution. No significant shared funding sources or coordinated Sybil bundling detected among top holders."
  }
}

🤖 ElizaOS / Python Agent Integration

import requests

GATEWAY = "https://whale402.acter.workers.dev"
TX_HASH = "0x<your_prepaid_tx_hash>"

headers = {
    "Authorization": f"x402 {TX_HASH}"
}

# Scan radar for early high-conviction whale accumulation
res = requests.get(f"{GATEWAY}/v1/smart-money-radar?network=base&limit=5", headers=headers)
radar = res.json()

for token in radar["data"]:
    if token["whaleAccumulationScore"] >= 80 and token["signal"] == "STRONG_ACCUMULATION":
        print(f"🚨 Alpha Alert: {token['symbol']} ({token['tokenAddress']}) accumulated by {token['smartMoneyWalletsInvolved']} smart wallets!")

📄 License

Available Tools

5 tools

detect_insider_clustersC

Performs deep Sybil bundling and dev cabal graph analysis on top token holders to detect shared gas funding sources and rug pull risks.

Name	Required	Description
`network`	Yes	Blockchain network (e.g. base, solana)
`paymentProof`	No	Optional Base USDC txHash (0x...) or x402 payment proof for unlimited calls
`tokenAddress`	Yes	Contract address of the token (0x... or Solana base58)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It implies a heavy computation ('deep ... graph analysis') but never states cost, latency, rate limits, or that the operation is read-only, and it says nothing about the payment/credit model despite a paymentProof parameter existing for 'unlimited calls'.

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?

A single front-loaded sentence with no filler; the action and detection targets come first. The jargon density ('Sybil bundling', 'dev cabal') is efficient for a domain-aware reader but borders on opaque.

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

Completeness3/5

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

For a three-parameter tool with a fully described schema but no output schema and no annotations, the description identifies the detection targets (shared gas funding, rug pull risk) but omits return structure, cost/payment expectations, and latency. Adequate to call correctly, not adequate to set expectations.

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 description coverage is 100%, so network, tokenAddress, and paymentProof are already documented in the schema. The description only adds the scoping hint that analysis is limited to 'top token holders' rather than all holders, which is marginally useful but not compensating detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific analysis (Sybil bundling and dev cabal graph analysis) on a specific resource (top token holders) and states the goal (detecting shared gas funding sources and rug pull risks). It is clear what the tool does, but it does not differentiate itself from siblings such as get_token_whale_activity or get_smart_money_radar, which overlap in the holder-analysis space.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives. An agent must infer from the phrase 'rug pull risks' that this is a token-risk-due-diligence tool rather than a general holder or smart-money lookup, leaving the choice among four sibling tools to guesswork.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_credits_and_payment_infoA

Returns remaining prepaid USDC balance for a txHash, free daily trial status, and deposit instructions.

Name	Required	Description	Default
`txHash`	No	Optional Base USDC transaction hash to check balance for

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. 'Returns' implies a read-only lookup and the description lists its key outputs, but it omits authentication requirements, rate limits, side effects, and whether the optional txHash changes the response scope.

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?

The description is a single front-loaded sentence that lists the three returned items with no filler. Every phrase contributes directly to understanding the tool's output.

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

Completeness4/5

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

For a simple one-parameter lookup with no output schema, the description identifies the important return components clearly. Minor gaps remain around auth/prerequisites and what happens when txHash is omitted, but the schema covers the parameter semantics.

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%, so the parameter is already fully documented as an optional Base USDC transaction hash. The description only repeats 'for a txHash' and adds no extra meaning about format, optionality, or behavior when omitted.

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 uses a specific verb and names three concrete outputs: remaining prepaid USDC balance, free daily trial status, and deposit instructions. It is clearly a billing/credits lookup tool, immediately distinguishable from the analytics-focused sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the purpose: check balance, trial status, or deposit instructions. However, the description does not explicitly state when to use this tool versus alternatives, nor whether txHash is required or optional.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_smart_money_radarB

Scans for top trending tokens currently being aggressively accumulated by verified high-win-rate (>70%) whale wallets.

Name	Required	Description
`limit`	No	Number of results to return (default: 10, max: 25)
`network`	No	Optional network filter (leave blank to scan all supported chains)
`paymentProof`	No	Optional Base USDC txHash (0x...) or x402 payment proof for unlimited calls

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose meaningful selection behavior, including the >70% win-rate threshold and aggressive accumulation by verified whale wallets, but it omits rate-limit, access/payment, freshness, and return-format behavior.

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?

The definition is a single front-loaded sentence with no boilerplate or repetition. Every phrase contributes to the core scan criteria.

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

Completeness2/5

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

For a tool with no annotations and no output schema, the description should do more to explain what the scan returns, how results are ranked, and how paymentProof affects access. The parameter schema covers inputs, but the description does not complete the picture of output or operational limits.

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 description coverage is 100%, so the schema already explains limit, network, and paymentProof. The description adds no parameter-level meaning beyond what the schema provides, which is the correct baseline for a fully documented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (scans), resource (top trending tokens), and selection criterion (aggressively accumulated by verified >70% win-rate whale wallets). It is clear what the tool does, but it does not explicitly differentiate itself from siblings such as get_token_whale_activity or detect_insider_clusters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies a use case by saying it scans for trending smart-money accumulation, but it gives no explicit when-to-use guidance, exclusions, or alternatives. An agent is left to infer whether this is for discovery, confirmation, or comparison against the sibling whale-activity tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_token_whale_activityC

Analyzes a token across Base, Solana, Ethereum, BSC, or Arbitrum to measure Smart Money net inflow, whale holding dominance, and whale accumulation score (0-100).

Name	Required	Description
`network`	Yes	Blockchain network (e.g., base, solana, ethereum)
`paymentProof`	No	Optional Base USDC txHash (0x...) or x402 payment proof for unlimited calls
`tokenAddress`	Yes	Contract address of the token (0x... or Solana base58)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden. It implies a read-only analysis but says nothing about cost, rate limits, or the payment/credit model that the optional 'paymentProof' parameter clearly signals — a material omission for a paid-tier data tool.

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?

A single front-loaded sentence that leads with the action and then the measured outputs, with no filler. It could be tightened only slightly by folding in the tool's relationship to its siblings.

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

Completeness3/5

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

With no annotations and no output schema, the description should explain the shape of the returned analysis and the cost/payment implications of 'paymentProof'. It conveys the metric names but leaves return structure, units (beyond the 0-100 score), and pricing behavior unaddressed.

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%, so the baseline is 3 and the schema already explains network, tokenAddress, and paymentProof. The description adds nothing about parameters and actually under-reports the supported networks by listing five of the six enum values, leaving 'polygon' undocumented in prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource ('Analyzes a token') and enumerates the concrete outputs (Smart Money net inflow, whale holding dominance, accumulation score 0-100), which distinguishes it from wallet-level siblings like profile_wallet_smart_money. However, it never contrasts itself with get_smart_money_radar or detect_insider_clusters, and its network list omits 'polygon' which the schema enum supports.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says what is measured but never states when to reach for this tool versus the sibling analytics tools, nor any prerequisites or exclusions. An agent must infer the use case from the metric names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

profile_wallet_smart_moneyB

Analyzes a trader or whale wallet track record: win rate %, realized PnL, 30-day ROI, hold duration, and assigns a CopyTradeGrade (A+ to F).

Name	Required	Description
`network`	Yes	Blockchain network (e.g. base, solana)
`paymentProof`	No	Optional Base USDC txHash (0x...) or x402 payment proof for unlimited calls
`walletAddress`	Yes	Wallet address to profile (0x... or Solana base58)

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the concrete analytics computed and that a letter grade (A+ to F) is assigned, which goes beyond the name. However, it omits notable behavioral facts implied by the schema: that a paymentProof unlocks unlimited calls (i.e. there is a metered/paywalled tier), and what happens for wallets with thin or no history.

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?

A single dense sentence that front-loads the resource and output list with no filler. It is well-sized for the tool, though it spends words enumerating metrics while leaving the payment behavior unaddressed.

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

Completeness3/5

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

There is no output schema, so enumerating the returned metrics and the grade scale is genuinely necessary and mostly covers the return shape. Gaps remain around the payment/credits model exposed by the paymentProof parameter and around grading criteria or failure modes for unknown wallets.

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 description coverage is 100%, including an enum for network and format hints for walletAddress ('0x... or Solana base58'), so the schema already does the heavy lifting and a baseline 3 applies. The description adds no parameter-level meaning beyond the schema, notably leaving the paymentProof paywall semantics unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (analyzes) and a specific resource (a wallet's trading track record), then enumerates the exact metrics returned (win rate, realized PnL, 30-day ROI, hold duration) plus the CopyTradeGrade. It is clearly a per-wallet tool as opposed to the token-level and cluster-level siblings, but it never names those siblings or states the distinction explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to call this versus get_smart_money_radar, get_token_whale_activity, or detect_insider_clusters, and no prerequisites or exclusions. The agent must infer from the name and the word 'wallet' that this is the per-address profiling entry point.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Oct 29, 2026
- First observeddetect_insider_clusters
- First observedget_credits_and_payment_info
- First observedget_smart_money_radar
- First observedget_token_whale_activity
- First observedprofile_wallet_smart_money

Deploy Server

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

TDQS

A3.5/5.0

Scored 2026-10-29 12:10 across 5 tools

Disambiguation4/5

Each tool targets a fairly distinct object: token-holder clusters, billing status, trend radar, token activity, and wallet profiling. There is minor potential overlap between get_smart_money_radar and get_token_whale_activity since both involve whale accumulation, but the descriptions distinguish broad scanning from token-specific analysis.

Naming Consistency4/5

All names use snake_case and mostly follow a verb_noun pattern with get_, detect_, and profile_. The convention is predictable overall, though the verbs are not perfectly uniform.

Tool Count5/5

Five tools is a well-scoped set for a focused crypto whale analytics server. Each tool appears to cover a necessary capability without excessive surface area.

Completeness4/5

The surface covers key analytics workflows: wallet profiling, token-level whale activity, smart-money trends, insider cluster detection, and billing/credits. Some adjacent operations such as alerting or broader historical queries are absent, but core usage paths are covered.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

smartmoneyoracle A
io.tooloracle
Whale & Institutional Flow MCP — 8 tools: TVL flows, alpha signals, stablecoin supply.
Finance Search Research & Data
82
https://tooloracle.io/smart/mcp/
cryptopulse A
io.github.vip0123
Live whale movements, wallet intel and Alpha-bot signals across 17 EVM chains, over MCP.
Blockchain Cryptocurrency Web3 & Decentralized Tech
71
https://cryptopulse.uno/api/mcp
whale-data A
com.coinlobster
Real-time whale trades, Smart Money Radar, market snapshots, news sentiment, signal outcomes.
Finance Cryptocurrency Blockchain
211
https://coinlobster.com/mcp
Nansen A
io.github.pipeworx-io
Nansen Smart Money MCP — on-chain smart-money labels & flows (nansen.ai)
Blockchain Cryptocurrency Web3 & Decentralized Tech
4711
https://gateway.pipeworx.io/nansen/mcp

Related MCP Servers

SmartMoneyOracle
Finance Blockchain Web3 & Decentralized Tech
ToolOracle
F
license
Not graded
quality
C
maintenance
Whale & Institutional Flow MCP Server — 8 tools for protocol TVL flows, alpha signals, stablecoin supply tracking. Part of ToolOracle (tooloracle.io).
Updated 6 months ago (2026-05-09 17:49 UTC)
-
CabalSpy Wallet Tracker MCPofficial
Cryptocurrency Blockchain Finance
CabalSpy
A
license
Not graded
quality
A
maintenance
KOL, smart money & whale wallets API on Solana, BNB, Base, ETH: Wallet tracker, Leaderboard
Updated 14 days ago (2026-10-15 13:08 UTC)
MIT
mcp-midasflowofficial
Cryptocurrency Finance
midasflowai-lab
A
license
Not graded
quality
D
maintenance
MidasFlow Flow API - Cross-exchange order flow, whale detection, liquidations, funding rates, squeeze alerts for AI agents. Native MCP server.
Updated 4 months ago (2026-06-29 12:59 UTC)
MIT
BotIndex MCP Server
Cryptocurrency Blockchain AI & Machine Learning
Cyberweasel777
A
license
Not graded
quality
D
maintenance
Provides predictive crypto market intelligence synthesized from whale positions, developer activity, and behavioral demand signals. Enables convergence scoring, whale divergence detection, and risk radar through MCP tools.
Updated 7 months ago (2026-03-18 17:04 UTC)
171 npm
MIT

🐋 Whale402 — Smart Money Whale Radar, Insider Cabal Audits & Copy-Trade Profiler MCP

📦 Quick Start: MCP Server (Claude Desktop, Cursor, Cline, Windsurf, Glama)

Available MCP Tools & REST Endpoints

⚡ Instant Multi-Call Prepaid Credits (Built for High-Speed Trading Bots)

💡 Example API Usage

1. Check Smart Money Accumulation on a Token

2. Audit Sybil Bundling & Dev Cabal Risk

🤖 ElizaOS / Python Agent Integration

📄 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

CabalSpy Wallet Tracker MCPofficial

mcp-midasflowofficial