Nansen

Finding top token holders

token_current_top_holders

Get upto 25 (per page) top holders information for a specific token.

Note: Using labelType: smart_money is not a good proxy for an overall market view. Use it only if user explicitly requests it, or to combine it with other non smart money data.

Modes:

onchain_tokens (default): Analyze on-chain tokens by contract address
perps: Analyze Hyperliquid perpetual futures by symbol (chain auto-set to "hyperliquid")

Columns returned (onchain_tokens mode):

Address: Wallet/contract address of the token holder
Label: Nansen label (e.g., exchange, whale, etc.)
Balance: Current balance held (numeric with K/M/B formatting)
Balance USD: USD value of token holdings (currency formatted)
Ownership %: Percentage of total token supply owned (percentage, 2 decimal places)
Sent: Total tokens sent from this address historically (numeric)
Received: Total tokens received by this address historically (numeric)
24h Change: Balance change in last 24 hours (numeric, can be negative)
7d Change: Balance change in last 7 days (numeric, can be negative)
30d Change: Balance change in last 30 days (numeric, can be negative)

Columns returned (perps mode):

Trader Address: Address of the trader
Trader Label: Nansen label for the trader
Side: Position direction (Long/Short)
Position Value USD: Total USD value of the position (currency formatted)
Position Size: Size of the position in tokens (numeric)
Leverage: Leverage multiplier (e.g., "20X")
Leverage Type: Type of leverage (cross/isolated)
Entry Price: Average entry price (price formatted)
Mark Price: Current mark price (price formatted)
Liquidation Price: Liquidation price (price formatted)
Funding USD: Cumulative funding payments (currency formatted)
Unrealized PnL USD: Unrealized profit/loss (currency formatted)

Sorting Options (default: holding_size desc): onchain_tokens mode: holding_size, total_outflow, total_inflow, balance_change_24h, balance_change_7d, balance_change_30d perps mode: holding_size, side, entry_price, leverage, liquidation_price, funding_usd, upnl_usd Use only a value listed for the selected mode. A value from the wrong mode is not an error: the call falls back to holding_size and the output notes the changed sort.

Examples: # On-chain tokens (default mode) { "mode": "onchain_tokens", "chain": "ethereum", "token_address": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab", "label_type": "top_100_holders" }

# Hyperliquid perpetual futures
```
{
  "mode": "perps",
  "token_address": "PENGU",
  "label_type": "smart_money"
}
```

# Find most active senders using filters
```
{
  "mode": "onchain_tokens",
  "chain": "ethereum",
  "token_address": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab",
  "label_type": "smart_money",
  "includeSmartMoneyLabels": ["All Time Smart Trader", "Fund"],
  "orderBy": "total_outflow",
  "order_by_direction": "desc"
}
```

# Find biggest accumulators (who received most tokens)
```
{
  "mode": "onchain_tokens",
  "chain": "ethereum",
  "token_address": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab",
  "label_type": "whale",
  "orderBy": "total_inflow",
  "order_by_direction": "desc"
}
```

# Perps mode with filters
```
{
  "mode": "perps",
  "token_address": "ETH",
  "label_type": "smart_money",
  "side": "Long",
  "upnlUsd": {"from": 10000},
  "positionValueUsd": {"from": 100000},
  "orderBy": "holding_size",
  "order_by_direction": "desc"
}
```

**Native-token / stablecoin `orderBy` restriction:**
With `labelType='top_100_holders'` (the default), native tokens
(`0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee` and native SUI) and
stablecoins/pegged tokens support `orderBy='holding_size'` only. To
sort such a token by another onchain field, use `labelType='whale'`,
`smart_money`, `exchange` or `public_figure` instead. An unsupported
combination is not an error: the call falls back to `holding_size`
and the output notes the changed sort.

**Other `top_100_holders` limits for native tokens:** limited filters
(holding_size, total_outflow, total_inflow, address, smart money
labels). For advanced filters use a different `labelType` or set
`aggregateByEntity=true`.

**Does not** work for SOL in onchain_tokens mode (tokenAddress So11111111111111111111111111111111111111112). For SOL analysis, use perps mode instead.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A5/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses fallback behavior for unsupported orderBy combinations, limitations for native tokens/stablecoins, page size, and that unsupported combinations silently fall back to holding_size. These are key behavioral traits that annotations would not cover, and they are described in detail.

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 long but extremely well-structured, using headings, bullet lists, and examples. Every section serves a purpose: column lists clarify return values, sorting lists inform valid inputs, and notes prevent misuse. The front-loaded main action gives immediate clarity, and the formatting makes complex details scannable.

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 exceptionally complete for a complex tool: it covers both modes, output columns, sorting options, filters, edge cases (SOL, native tokens, stablecoins), fallback behaviors, and four real-world examples. Since an output schema exists, the description does not need to explain return structure, but it effectively covers all operational contexts needed to invoke the tool correctly.

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?

Although the top-level schema coverage is 0%, the description compensates by fully explaining every parameter through examples and explicit notes. It covers mode, tokenAddress, chain, labelType, orderBy, order_by_direction, side, upnlUsd, positionValueUsd, entryPrice, includeSmartMoneyLabels, and aggregateByEntity. The examples show exact JSON structures, making parameter usage unambiguous.

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 clear action ('Get up to 25 top holders information for a specific token') and specifies the two modes (onchain_tokens and perps). This definitively distinguishes it from sibling tools like token_dex_trades or token_flows by focusing on holder rankings. The scope is precisely stated, making it easy to know what resource is being accessed.

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?

Explicit usage guidance is abundant: it warns that 'smart_money' labels are not a good proxy for market view and should only be used when explicitly requested. It states that SOL in onchain_tokens mode does NOT work and instructs to use perps mode instead. It also provides mode-specific sorting restrictions and fallback behavior, clearly covering when/when-not and alternatives.

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

All Nansen 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

A3.8/5.0

Disambiguation5/5

Each tool has a clearly defined purpose, and overlapping tools (e.g., token_flows vs token_recent_flows_summary, nansen_score_top_tokens vs token_discovery_screener) include explicit guidance on when to use them. Even with similar names like prediction_market_trades and prediction_market_address_trades, the descriptions and parameters make the distinction unambiguous.

Naming Consistency4/5

Most tools follow a domain_prefix_noun pattern (address_, token_, prediction_market_), making them predictable within families. However, outliers like general_search, growth_chain_rank, hyperliquid_leaderboard, and transaction_lookup break the pattern, and some names are long or inconsistently formatted (e.g., smart_traders_and_funds_perp_trades vs smart_traders_and_funds_token_balances).

Tool Count3/5

With 38 tools, the server is far above the typical 3-15 range, making it heavy for agents to navigate. However, Nansen is a broad analytics platform covering wallets, tokens, prediction markets, and smart money activity, so the high count is justifiable as each tool serves a distinct function.

Completeness5/5

The tool set provides comprehensive coverage across token analysis (ohlcv, trading, holders, flows, PnL, technicals), wallet analysis (portfolio, transactions, counterparties), prediction markets (lookup, orderbook, trades, PnL), and discovery. The only obvious omission is NFT support, but it is explicitly documented as out of scope, so no critical dead ends exist.

Resources

Need Help?