Nansen
REMOTE · MCP.NANSEN.AI · SCANNED SEP 20
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security63
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one. See how to fix → View diagnostics → Partial
- HTTPS enforcement could not be verified: the plaintext port answered with HTTP 405, which proves neither a plaintext path nor enforcement. View diagnostics → Unverified
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability51
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 15938 tokens (~318/item across 50 items; 50 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage79
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 28% of tool parameters carry a description.Partial
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 50 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 51 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the Nansen MCP server?
Nansen is a hosted endpoint at https://mcp.nansen.ai/ra/mcp/, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · mcp.nansen.ai
claude mcp add --transport http nansen-ai-nansen-mcp 'https://mcp.nansen.ai/ra/mcp/'
{
"mcpServers": {
"nansen-ai-nansen-mcp": {
"url": "https://mcp.nansen.ai/ra/mcp/"
}
}
} {
"servers": {
"nansen-ai-nansen-mcp": {
"type": "http",
"url": "https://mcp.nansen.ai/ra/mcp/"
}
}
} [mcp_servers.nansen-ai-nansen-mcp] url = "https://mcp.nansen.ai/ra/mcp/"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"nansen-ai-nansen-mcp": {
"type": "remote",
"url": "https://mcp.nansen.ai/ra/mcp/",
"enabled": true
}
}
} openclaw mcp add nansen-ai-nansen-mcp --url 'https://mcp.nansen.ai/ra/mcp/' --transport streamable-http
mcp_servers:
nansen-ai-nansen-mcp:
url: "https://mcp.nansen.ai/ra/mcp/" {
"McpServers": {
"nansen-ai-nansen-mcp": {
"Transport": "http",
"Url": "https://mcp.nansen.ai/ra/mcp/"
}
}
} assistant mcp add nansen-ai-nansen-mcp -t streamable-http -u 'https://mcp.nansen.ai/ra/mcp/'
{
"mcpServers": {
"nansen-ai-nansen-mcp": {
"type": "http",
"url": "https://mcp.nansen.ai/ra/mcp/"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 19 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
- 18 Sept 26 +1
- The server rewrote its instructions, which are the text every model session reads security
- New tool “address_counterparties_batch” functional
- New tool “address_first_funder” functional
- New tool “entity_name_search” functional
- New tool “token_jup_dca” functional
- 17 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
- 16 Sept 26 +6
- Authorization: unverified → partial ▲ security
- The server rewrote its instructions, which are the text every model session reads security
- 15 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Tool “prediction_market_address_pnl” rewrote its description, which is the text the model reads security
- Tool “prediction_market_address_summary” rewrote its description, which is the text the model reads security
- Tool “prediction_market_pnl_leaderboard” rewrote its description, which is the text the model reads security
- Tool “prediction_market_position_detail” rewrote its description, which is the text the model reads security
- 14 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
- 13 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
- 12 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Sept 2026 · Probed https://mcp.nansen.ai/ra/mcp/
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=mcp.nansen.ai | CN=WR3,O=Google Trust Services,C=US | 13 Sept 2026 | 12 Dec 2026 | RSA 2048 | SHA256-RSA | 2155a5ee509bbab6120e0b7e3ad20e82 |
| SANs: mcp.nansen.ai | ||||||
| CN=WR3,O=Google Trust Services,C=US (CA) | CN=GTS Root R1,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | RSA 2048 | SHA256-RSA | 7ff005a91568d63abc22861684aa4b5a |
| CN=GTS Root R1,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 19 Jun 2020 | 28 Jan 2028 | RSA 4096 | SHA256-RSA | 77bd0d6cdb36f91aea210fc4f058d30d |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of mcp.nansen.ai. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| ai. | present | 3799 | 8 | Verified |
| nansen.ai. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.nansen.ai/ra/mcp/ | Verified | 200 | |
| http (plaintext) | http://mcp.nansen.ai/ra/mcp/ | Inconclusive | 405 |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
address_counterparties Analyzing wallet connections ~329
Get 25 (per page) addresses or entities with the most common interactions with input addresses Default sort is net value transferred between them. Also returns the top 3 tokens transferred by count for each counterparty Note: To get related wallets: - Focus on direct value transfers to get most likely addresses. - Include CEX deposit addresses (not withdrawal addresses!) as well. - Also go one level deeper: - Find addresses that interacted with the most likely addresses. - Find addresses that deposited to the same CEX deposit (NOT withdrawal!) addresses. - Address structure / string is not important, but the relationship is! Sorting Options (all fields support "ASC"/"DESC"): Available for sorting: total_volume_usd, volume_in_usd, volume_out_usd, interaction_count Examples: # Query by single address { "address": "0x123...", "sourceInput": "Combined", "groupBy": "wallet", "chain": "ethereum", "timeRange": {"from": "30D_AGO", "to": "NOW"}, "order_by": "total_volume_usd", "order_by_direction": "desc" } # Query by entity { "entity_id": "Binance", "sourceInput": "Combined", "groupBy": "entity", "chain": "all", "timeRange": {"from": "7D_AGO", "to": "NOW"} }
| Name | Type | Req | Description |
|---|---|---|---|
| request | object | yes | Complete request for address counterparties (flattened). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
address_counterparties_batch Comparing wallet connections ~481
Get the top counterparties of up to 10 wallet addresses in one call. Every wallet gets its own counterparty list. The lists are NOT added together: the answer has one table for each wallet. Use this tool to compare wallets — counterparties that two wallets share, a group of wallets that sends to the same CEX deposit address, or one fund with many wallets. For one wallet, or for an entity name, use address_counterparties. Limits: - Maximum 10 distinct wallet addresses for each call. Repeated addresses are removed. - Maximum 90 days for the date range. A wider range is rejected — make more than one call. - One chain family for each call: every address must be EVM, or every address must be Solana, and so on. Do not mix families. Name a `chain` (for example ethereum) to read that chain only. Leave `chain` out to read every chain of the addresses' family at one time — then a counterparty met on more than one chain gets one row for each chain, so do not add those rows together. Sorting Options (all fields support "ASC"/"DESC"): Available for sorting: total_volume_usd, volume_in_usd, volume_out_usd, interaction_count. The sort is applied inside each wallet's block. Example (every key below is the name the request accepts, and the addresses are real — copy this shape as it stands): { "walletAddresses": [ "0x28c6c06298d514db089934071355e5743bf21d60", "0xd8da6bf26964af9d7eed9e03e53415d37aa96045" ], "chain": "ethereum", "timeRange": {"from": "30D_AGO", "to": "NOW"}, "sourceInput": "Combined", "orderBy": "total_volume_usd", "orderByDirection": "DESC", "perPage": 100 }
| Name | Type | Req | Description |
|---|---|---|---|
| request | object | yes | Complete request for batch address counterparties (flattened). Wallet addresses only. Use AddressCounterpartiesRequest for one wallet or for an entity name. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
address_dex_trades Checking wallet DEX trades ~321
Get a wallet's individual trades on a single chain — DEX swaps (spot) or Hyperliquid perpetual trades, newest first. Wallet-centric companion to `token_dex_trades` (which is token-centric). Chain: one per call ('all'/'evm' unsupported). EVM wallets MUST pass `chain` explicitly (e.g. ethereum, base, arbitrum); non-EVM (e.g. Solana) is auto-detected. Use 'hyperliquid' for Hyperliquid perpetual trades (requires an EVM address). Call once per chain to span multiple networks. Spot columns: Time, Bought / Bought Amount, Sold / Sold Amount, Value USD, Tx Hash. Perp columns: Time, Token, Side, Action, Size, Price, Value USD, Fee USD, Closed PnL, Tx Hash. Sort (`order_by`, asc/desc): timestamp, value. Filter by `valueUsd`, `tokenAddressBought`, or `tokenAddressSold`. On spot chains the token fields take contract addresses. On Hyperliquid they take perp symbols and select Long or Short trades respectively; only one token field is allowed. Example: { "address": "0x1f2f10d1c40777ae1da742455c65828ff36df387", "chain": "ethereum", "dateRange": {"from": "7D_AGO", "to": "NOW"} }
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
address_first_funder Finding the first funder ~86
Get the first address that ever funded an EVM wallet, with the funding transaction hash, chain and timestamp. Use this to attribute an unlabelled wallet to a known entity — the first funder is often a CEX withdrawal or a wallet the same owner already controls. The funder is resolved across all chains, so no chain argument is needed.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
address_historical_balances Checking balance history ~37
Get historical native coin & token balances of address.
| Name | Type | Req | Description |
|---|---|---|---|
| request | object | yes | Complete request for address historical balances (flattened). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
address_labels Looking up address labels ~52
Get the standard labels for one wallet address. This tool returns identity, behavioural, and protocol labels. It does not return premium labels.
| Name | Type | Req | Description |
|---|---|---|---|
| request | object | yes | Request for the standard labels of one wallet address. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
address_perp_positions Getting wallet Hyperliquid positions and liquidation risk ~45
Get a wallet's Hyperliquid positions and liquidation risk without a portfolio lookup.
| Name | Type | Req | Description |
|---|---|---|---|
| request | object | yes | Complete request for a wallet's open Hyperliquid perpetual positions. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
address_portfolio Loading portfolio data ~438
Get comprehensive portfolio overview for a wallet address or entity. Hyperliquid perpetual positions include liquidation prices to support risk analysis workflows. For wallet addresses, supports different modes: - 'fast-mode-default': Wallet balances + Hyperliquid positions (skip defi, for fast mode only) - 'all': Wallet balances + DeFi positions + Hyperliquid positions - 'wallet_balances': Only token balances (tokens and native coins across all chains) - 'defi': Only DeFi positions (lending, staking, LP tokens, etc., excluding Hyperliquid) - 'hyperliquid': Only Hyperliquid data — perp positions (with liquidation prices and margin summary) plus HL spot wallet balances For entities (e.g., "Binance", "Paradigm Fund"), only on-chain token balances are returned, aggregated across all addresses associated with the entity. This tool provides flexible portfolio analysis in a single request, allowing users to focus on specific aspects of their holdings. The output is pre-formatted markdown that should be presented exactly as returned, preserving all tables, sections, and formatting without reinterpretation. Example Usage: Get full comprehensive portfolio for a wallet: ``` { "walletAddress": "0x28c6c06298d514db089934071355e5743bf21d60", "mode": "all" } ``` Get only DeFi positions (returns raw JSON): ``` { "walletAddress": "0x28c6c06298d514db089934071355e5743bf21d60", "mode": "defi" } ``` Get only Hyperliquid positions (returns raw JSON): ``` { "walletAddress": "0x28c6c06298d514db089934071355e5743bf21d60", "mode": "hyperliquid" } ``` Get token balances for an entity: ``` { "entity_id": "Binance" } ```
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
address_related_addresses Finding related wallets ~142
Get information about related addresses of an input address. Note: This only includes the the "special" connections 'First Funder', 'Signer', 'Previous Signer', 'Multisig Signer of', 'Previous Multisig Signer of', 'Deployed via', 'Deployed by', 'Deployed Contract', 'Created Contract', 'Created by'. To get related wallets, also check address counterparties. First funder exchange withdrawal address does usually NOT belong to the same entity as the address, only deposit addresses. Only information is that it has been funded by the exchange.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | AddressRelatedAddressesRequest containing parameters and pagination settings |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
address_transactions Fetching transaction history ~42
Get list of 20 MOST RECENT transactions made by an address (per page). Only the latest transactions according to the date range are returned.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
entity_name_search Searching entity names ~120
Search Nansen's entity names by a partial name and get back the exact entity names that match. Use this when a tool needs an exact entity name and the user gave an approximate one (e.g. "binance" -> "Binance 14"). Matching is case-insensitive and matches anywhere in the name. For tokens or addresses use `general_search` instead.
| Name | Type | Req | Description |
|---|---|---|---|
| max_results | integer | – | Maximum number of entity names to return (default 25) |
| search_query | string | yes | Partial entity name, at least 2 characters |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
general_search Searching tokens, companies, and addresses ~392
General search tool. This is your FIRST entry point to look up for possible tokens, entities, and addresses related to a query. Do NOT use this tool for prediction markets. For Polymarket names, topics, event slugs, or URLs, use `prediction_market_lookup` instead. Nansen MCP does not support NFTs, however check using this tool if the query relates to a token. Regular tokens and NFTs can have the same name. This tool allows you to: - Check if a (fungible) token exists by name, symbol, or contract address - Search information about a token - Current price in USD - Trading volume - Contract address and chain information - Market cap and supply data when available - Search information about an entity - Find the address behind a Nansen label (public figure, fund, exchange wallet) - Find Nansen labels of an address (EOA) or resolve a domain (.eth, .sol)
| Name | Type | Req | Description |
|---|---|---|---|
| chain | – | – | Optional chain filter to narrow down token results to specific blockchain. If not further specified, leave it as None. If a chain is specified, ALWAYS use this parameter instead of adding chain name… |
| max_results | integer | – | Maximum number of results (default: 25, max: 25) |
| query | string | yes | The search term - token symbol, name, or address. In stock mode, pass only the company name or exchange ticker. Do not add words such as "stock", "ticker", or a chain name. |
| result_type | string | – | Type filter - "token", "entity", "wallet", "eoa", "stock", or "any" |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
growth_chain_rank Checking blockchain rankings ~42
Get chain growth rankings by active addresses, transactions, gas fees and DEX volume.
| Name | Type | Req | Description |
|---|---|---|---|
| request | object | yes | GrowthChainRankRequest containing parameters and pagination settings |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
hyperliquid_leaderboard Checking Hyperliquid leaderboard ~478
Get Hyperliquid perpetual futures trader leaderboard with performance metrics. Returns: Trader performance rankings as markdown. Columns returned: - **Address** / **Label**: trader wallet, and its Nansen label if any - **Total PnL** (USD): realized + unrealized over the date range - **Realized PnL** (USD): net, from positions closed in the range. Being a net total it shows no per-trade outcome, so no win rate can be derived from it or any other column here - **Unrealized PnL** (USD): on positions still open, at the current mark price - **ROI** (%): Total PnL / (traded notional + open notional) — PnL per dollar traded, not return on capital - **Volume** (USD): traded notional; both fills of a position count - **Trades**: number of fills - **Account Value** (USD): only available for the top 500K traders This is an overview of top traders and their headline stats. For a trader's open positions, call `address_portfolio` with `mode='hyperliquid'`. **Sorting**: total_pnl, realized_pnl_usd, unrealized_pnl_usd, roi, volume_usd, total_trades, account_value **Filtering** (from/to): totalPnl (USD), accountValue (USD), roi (a fractional ratio, not the percent shown — pass 0.1 for "10% or better", not 10) Example: ``` { "date": {"from": "7D_AGO", "to": "NOW"}, "accountValue": {"from": 100000, "to": 1000000}, "totalPnl": {"from": 10000}, "order_by": "total_pnl", "orderByDirection": "DESC" } ``` Rank by traded volume instead: `"order_by": "volume_usd"` Notes: - Hyperliquid perpetual futures only - Null/empty means data is not available — do not read it as zero
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
nansen_score_top_tokens Ranking top tokens by Nansen Score ~433
Discover and filter a daily list of attractive tokens using Nansen Score Indicators weighted by coefficients (= Performance Score). Use this tool when you don't know which tokens to buy and need recommendations based on backtested indicators. For specific token analysis (e.g., "should I buy AAVE?"), use token_quant_scores instead. **When to use this tool vs token_discovery_screener**: - Use **this tool** when you want **pre-scored buying recommendations** without specifying criteria. It answers "what should I buy?" by returning tokens that already meet a quantitative buying threshold (Performance Score ≥15) based on alpha indicators like price momentum, chain fees, and protocol fees. Data is updated in batches. - Use **token_discovery_screener** when you want **live data** or to **explore tokens by specific criteria** like sectors (e.g., "AI memecoins"), token age (e.g., "new launches"), smart money activity, or custom volume/liquidity thresholds. It's a filtering tool with real-time metrics where you define what you're looking for. Returns tokens pre-filtered by: performance_score >= 15 (buying threshold). **Example queries**: "what tokens should I buy?", "which tokens look good?", "best tokens to buy today" **Scoring:** - **Performance Score** (range -60 to +75): Higher = better alpha opportunity. **Buy threshold: ≥15** - **Risk Score** (range -60 to +80): Higher = safer token. >0 indicates low to medium risk. Every time you give the Performance Score to the user, explain the scoring thresholds above. Same for the Risk Score. Every time quote the underlying indicators that contributed the most to the Performance/ Risk score and recall their definition to the user. Returns: A list of tokens with the highest Performance Score as markdown. Core fields: Token Address, Token Symbol, Chain, Performance Score, Risk Score. Indicator columns are included dynamically based on data availability (columns with all zeros are excluded).
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
prediction_market_address_pnl Checking prediction market address PnL ~227
Prediction market PnL breakdown for a Polygon wallet, market by market. **When to use:** - Wallet-level Polymarket track record with per-market cost and proceeds. **Key fields:** - `Total PnL USD` = redemption + unrealized value + sell proceeds − buy cost, for that market only. - `Net Buy Cost USD` is what the wallet paid for shares. - `Net Sell Proceeds USD` is what it received for shares sold before resolution. - `Redemption Value USD` is the payout collected after the market settled. - `Unrealized Value USD` is the marked value of shares still held. - `Resolved` says whether the market has settled. **Pitfalls:** - Each row covers one market. Sum the rows for a wallet total, or use `prediction_market_address_summary` for the aggregate. - The API gives no ROI or share count here. Do not state them. - Blank PnL fields mean unavailable data, not zero.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
prediction_market_address_summary Summarizing prediction market address ~205
Prediction market summary metrics for a Polygon wallet. **When to use:** - First wallet-level Polymarket tool for a quick trader overview. - Use before detailed address trades/PnL when the user asks for a general wallet profile, activity summary, or whether a wallet is active on Polymarket. **Key fields:** - `Markets Traded` and `Markets Won` are lifetime counts; `Win Rate` is won / traded. - `Total PnL USD` = realized + unrealized. - `First Seen` and `Wallet Age (Days)` show how long the wallet has been active on Polymarket. **Pitfalls:** - The API gives no trade count, volume, or ROI here. Do not state them. For per-market cost and proceeds use `prediction_market_address_pnl`. - Blank PnL fields mean unavailable data, not zero.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
prediction_market_address_trades Checking prediction market address trades ~76
Prediction market trade history for a Polygon wallet. **Key fields:** - `Share Size` is quantity traded in the displayed outcome side. - `Value USD` applies to that row only, not the whole transaction. **Pitfalls:** - Use this for wallet trade activity, not profitability.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
prediction_market_lookup Looking up prediction market ~337
Search Polymarket for events and markets by name, topic, URL, or slug. **PM building blocks:** - An **event** is a grouped prediction topic containing many child markets. - A **market** is one tradable outcome with its own `marketId`. - Example: `2026 NCAA Tournament Winner` is an event; `Will Duke win the 2026 NCAA Tournament?` is a market. Detail tools require `marketId`, not `eventId`. **When to use:** - First tool when the user asks about a specific PM topic, event, slug, or Polymarket URL but does not provide `marketId`. - Optionally provide `queryVariant` as a cleaner short keyword version. - Set `includeEventMarkets` to true to also return child markets for the best-matching event. - Do NOT use `general_search` for prediction markets. - Results include current outcome prices, last trade price, and bid/ask inline — for a quick probability check you may not need `prediction_market_ohlcv`. For price *history* or dated moves, still use `prediction_market_ohlcv`. **Query tips:** - Uses Polymarket's search API — natural language queries work well. - Prefer short 1–3 keyword queries for best results. - Avoid broad multi-topic queries like `bitcoin ethereum politics`. **Output rules:** - If lookup returns no suitable market or a mismatched timeframe, say so explicitly — do not silently substitute a nearby market.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
prediction_market_ohlcv Loading prediction market prices ~164
Historical odds/volume candles for a Polymarket market. **When to use:** - Current odds / implied probability, price history, and recent probability changes on a specific market. **Key fields:** - `Close` is the share price for the displayed outcome side. - In binary markets, Yes and No shares are complementary and sum to about $1. **Pitfalls:** - Each response is for one exact `marketId` — do not mix dates or prices across different markets. - If no candles are returned for the requested window, say so directly — do not estimate. **Prerequisites:** If `marketId` is unknown, call `prediction_market_lookup` first.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
prediction_market_orderbook Checking prediction market orderbook ~263
Live orderbook for a Polymarket market. **When to use:** - Bid/ask depth, liquidity, and yes-share / no-share order structure. **Key fields:** - `Order Size` is share quantity, not USD. Do not describe share size as dollar depth unless you calculate `shares × price`. **Yes/No price relationship:** - Yes and No are complementary (Yes + No ≈ $1). A No bid at price $X means willingness to buy No when Yes is near $(1−X). - A cluster of No bids at low prices (e.g. $0.20) is resistance for Yes rallying to ~$0.80, NOT a support floor for the current Yes price. - When comparing OHLCV odds against orderbook depth, convert No-side prices to Yes-equivalent (1 − No price) before drawing divergence conclusions. **Pitfalls:** - Do not treat raw no-share prices as bearish yes-share odds — prefer `prediction_market_ohlcv` for current odds / implied probability. **Prerequisites:** If `marketId` is unknown, call `prediction_market_lookup` first.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
prediction_market_pnl_leaderboard Checking prediction market PnL leaders ~227
PnL leaderboard for a Polymarket market. **When to use:** - Only for profitability claims. **Key fields:** - `Total PnL USD` = redemption + unrealized value + sell proceeds − buy cost, for this market only. - `Net Buy Cost USD` is what the wallet paid for shares. - `Net Sell Proceeds USD` is what it received for shares sold before resolution. - `Redemption Value USD` is the payout collected after the market settled. - `Unrealized Value USD` is the marked value of shares still held. - `Side Held` reflects current side exposure where the API provides it. **Pitfalls:** - The API gives no ROI, volume, or trade count here. Do not state them. - If PnL fields are blank, say profitability is unavailable — do not substitute top holders or position size. **Prerequisites:** If `marketId` is unknown, call `prediction_market_lookup` first.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
prediction_market_position_detail Loading prediction market position ~173
Detailed position breakdown for a Polymarket market. **Key fields:** - `Position Size (Shares)` is the share quantity still held. - `Buy Cost USD` and `Sell Proceeds USD` are the cash paid and received for this outcome token. - `Unrealized Value USD` is the marked value of shares still held; `Redemption Value USD` is the payout collected after settlement. - `Position PnL USD` applies to the displayed row only — not the wallet's total PM activity. **Pitfalls:** - Each row is one outcome token of one wallet. A wallet holding both sides appears twice. **Prerequisites:** If `marketId` is unknown, call `prediction_market_lookup` first.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
prediction_market_screener Screening prediction markets ~232
Browse and sort Polymarket markets, events, or categories. **When to use:** - Broad discovery, screening, and ranked browsing across many markets. - Do NOT use this to resolve one named market/event/slug/URL — use `prediction_market_lookup` instead. **Query tips:** - Literal-style matching on text and slugs, not fuzzy web search. - Prefer one short topic or slug fragment (e.g. `fed cuts`, `zelensky`, `ncaa tournament`). - Do not bundle unrelated topics (e.g. `bitcoin ethereum politics weather`). If a broad question spans several topics, run separate screener queries for each. - If a query returns no rows, do not invent a nearest match — try a narrower topic or say no data was returned. **Output rules:** - Superlatives (highest, leading, biggest, top, trending) must match the shown metric exactly. - Do not infer end dates, rankings, or category leadership from titles alone.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
prediction_market_top_holders Finding prediction market top holders ~175
Largest current holders for a Polymarket market. **Key fields:** - Positions are share balances, not USD notional. - `Position Value USD` is current marked value, not payout at resolution. - `Side Held` is the share side currently held. **Pitfalls:** - The visible holder table is the source of truth for holder-side concentration — do not infer risk, max loss, or potential profit unless the tool output explicitly provides it. - Output summary is based only on shown rows, not the entire holder table. - Large visible positions or labels do not by themselves identify smart money unless Nansen smart-money-labelled data supports it. **Prerequisites:** If `marketId` is unknown, call `prediction_market_lookup` first.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
prediction_market_trades Checking prediction market trades ~146
Recent trades for a Polymarket market. **When to use:** - Source of truth for recent fills and latest trade-tape pricing. - Do not overwrite recent trade prices with older OHLCV candles. **Key fields:** - `Share Size` is quantity; `Value USD` is dollar value. - Each row is one visible trade leg — `Value USD` applies to that row, not the whole transaction hash. **Pitfalls:** - Large visible trades do not by themselves identify smart money or institutions. **Prerequisites:** If `marketId` is unknown, call `prediction_market_lookup` first.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
smart_traders_and_funds_dcas Checking Smart Money DCA orders ~77
Get Jupiter DCA (dollar-cost-averaging) orders opened by smart traders and funds on Solana, including deposit size, amount spent so far and order status. Use this for scheduled accumulation intent; use smart_traders_and_funds_dex_trades for one-off swaps.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
smart_traders_and_funds_dex_trades Tracking Smart Money DEX trades ~91
Get individual (per wallet, per transaction) DEX trades made by smart traders and funds (EXCLUDES whales, large holders, influencers, etc.) across all chains (default is ['all']) or specific chain(s). Use this to see exactly which wallet bought or sold what; use smart_traders_and_funds_netflow for the aggregated view.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
smart_traders_and_funds_historical_token_balances Reviewing Smart Money holdings history ~96
Get the day-by-day history of aggregated smart trader and fund token balances (EXCLUDES whales, large holders, influencers, etc.) for a date range on base, bnb, ethereum, monad, robinhood or solana. Use this to see how smart money holdings changed over time; use smart_traders_and_funds_token_balances for the current snapshot.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
smart_traders_and_funds_netflow Checking Smart Money netflows ~105
Get aggregated (not per wallet) smart trader and fund (EXCLUDES whales, large holders, influencers, etc.) net USD flow per token over 1h/24h/7d/30d, per chain for all chains (default is ['all']) or specific chain(s). Use this for what smart money is buying or selling right now; use smart_traders_and_funds_token_balances for what they hold.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
smart_traders_and_funds_perp_trades Tracking Smart Money perp trades ~347
Get recent Hyperliquid perpetual futures trades from Smart Money addresses across all tokens. Optional labels narrow this cohort; they do not search all addresses with that label. For a broad view of Smart Money activity across all tokens, use token_discovery_screener with traderType="sm". **Note:** This endpoint is Hyperliquid-only (perpetual futures data). It returns recent trades only (no date filtering available). Columns returned: - **Time**: Timestamp when the trade occurred (datetime: YYYY-MM-DD HH:MM:SS) - **Side**: Position direction - Long or Short - **Action**: Order action - Add, Reduce, Open, Close - **Token**: Symbol of the perpetual contract - **Size**: Quantity of the perpetual contract (numeric) - **Price USD**: Price per token at time of trade (price formatted) - **Value USD**: Total USD value of the trade (currency formatted) - **Trader**: Nansen label of the trading address - **Address**: Full trading wallet address - **Tx Hash**: Blockchain transaction hash for verification Sorting Options (all fields support "asc"/"desc"): Available for sorting: timestamp, amount, price_usd Examples: # Get recent smart money perp trades (sorted by amount) ``` { "orderBy": "amount", "order_by_direction": "desc" } ``` # Filter by action and side ``` { "action": "Open", "side": "Long" } ```
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
smart_traders_and_funds_pnl_leaderboard Ranking Smart Money by PnL ~102
Rank smart trader and fund addresses (EXCLUDES whales, large holders, influencers, etc.) by realized, unrealized and total USD PnL over a 1/7/30/90/180 day window, with ROI, win rate and trade counts. Use this to find the best performing smart money wallets; use token_pnl_leaderboard for the best performers on one specific token.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
smart_traders_and_funds_token_balances Checking Smart Money positions ~80
Get aggregated (not per wallet) smart trader and fund (EXCLUDES whales, large holders, influencers, etc.) token balances and 24h change per chain for all chains (default is ['all'], which queries all supported chains) or specific chain(s). Use filters to narrow down the results.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_current_top_holders Finding top token holders ~1,269
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,…
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_dex_trades Checking latest DEX trades ~119
Get DEX trades for a specific token. **Modes:** - `onchain_tokens` (default): Analyze on-chain tokens by contract address - `perps`: Analyze Hyperliquid perpetual futures by symbol (chain auto-set to "hyperliquid") **NOTE:** In onchain_tokens mode, only ETH is supported among native tokens. For other native tokens (SOL, BTC, BNB, etc.), use perps mode instead.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | TokenDexTradesRequest containing parameters, pagination settings, and optional sorting |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_discovery_screener Discovering trending tokens ~1,983
Get comprehensive token screening data across multiple blockchain networks with advanced filtering. A maximum of 25 results per page are returned out of 1000s of tokens. Use the sorting and filtering options to narrow down the results. In a mixed spot + hyperliquid request, `page` applies to both the spot and perps sections. A maximum of 5 chains can be specified per request (excess chains are automatically trimmed). This tool helps with token discovery and finding trending tokens by combining different metrics: volume, liquidity, market cap, smart money activity, and token age. **IMPORTANT - Hyperliquid Special Case:** - Hyperliquid chain queries perpetual futures (perps), not spot tokens - When hyperliquid is mixed with other chains, two sections of up to 25 results each are returned - one for spot tokens and one for perps. - For perps, only these filters are supported: volume, buyVolume, sellVolume, openInterest, netflow, nofTraders, traderType - Additional orderBy fields for perps: open_interest, funding (e.g. orderBy 'funding' ascending finds perps that pay longs) - Unsupported filters/orderBy will fallback to defaults INPUT EXAMPLES: # Find tokens which are going up in price. # Added some liquidity filter to remove spam and low quality tokens. ``` { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "24h", "liquidity": {"from": 100000}, "nofTraders": {"from": 10}, "orderBy": "price_change", "orderByDirection": "desc" } ``` # Find top stablecoins by market cap ``` { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "7d", "sectors": ["Stablecoin"], "orderBy": "market_cap_usd", "orderByDirection": "desc" } ``` # Find AI memecoins with high trading activity { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "7d", "sectors": ["AI Meme"], "liquidity": {"from": 100000}, "volume": {"from": 1000000} } # Find DeFi lending tokens { "chains": ["ethereum", "solana",…
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_flows Tracking token movements ~273
Get hourly token-flow history for ONE holder segment over a date range. Use `token_recent_flows_summary` instead for an on-chain snapshot across ALL wallet categories. **Note:** Using `holder_segment: 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. This is a **more granular** tool than `token_recent_flows_summary` and provides the TOTAL flows over the entire time frame broken down by segment. **Modes:** - `onchain_tokens` (default): Analyze on-chain tokens by contract address - `perps`: Analyze Hyperliquid perpetual futures by symbol (chain auto-set to "hyperliquid") — supports native tokens **NOTE:** Native tokens (0xeee…, So111…) cannot be queried in `onchain_tokens` mode. If a native placeholder address is supplied, this tool returns Hyperliquid perpetual-futures flows for that chain's native coin instead (e.g. hyperevm → HYPE, bnb → BNB, base → ETH) and prepends a prominent data-source warning. For native-token wallet-category flows on-chain, use `token_recent_flows_summary`.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | TokenFlowsRequest containing parameters and pagination settings |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_info Loading token info ~530
Get token information — spot on-chain details or Hyperliquid perpetual futures stats. On-chain tokens mode (default): Returns token details (name, symbol, market cap, FDV, supply, deployment date, socials) and spot trading metrics (volume, buys/sells, buyers/sellers, holders, liquidity). Perps mode: Returns Hyperliquid perp stats — mark price, funding, open interest, buy/sell pressure, trader participation. Returns: Token information as markdown. On-chain tokens fields: - **Market Cap / FDV**: Market capitalization and fully diluted valuation - **Circulating / Total Supply**: Token supply metrics - **Deployed**: When the token was deployed - **Volume (Total / Buy / Sell)**: Trading volume in USD - **Buys / Sells**: Number of buy/sell transactions - **Unique Buyers / Sellers**: Distinct trading addresses - **Total Holders**: Number of token holders - **Liquidity**: Available liquidity in USD Perps fields: - **Mark Price**: Current perp mark price - **Price Change**: Change vs previous price - **Max Leverage**: Maximum leverage offered for the perp on Hyperliquid (e.g. "40x") - **Funding Rate (hourly/annualized)**: Current funding rate - **Open Interest**: Total current open interest in USD - **Volume (Total / Buy / Sell)**: Perp volume in USD - **Net Flow (Buy - Sell)**: Buy/sell pressure in USD - **Traders**: Number of traders Example: On-chain tokens (default mode): ``` { "mode": "onchain_tokens", "chain": "ethereum", "tokenAddress": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab", "timeframe": "1d" } ``` Hyperliquid perps: ``` { "mode": "perps", "tokenAddress": "BTC", "timeframe": "7d" } ``` Notes: - On-chain tokens mode uses contract addresses - Perps mode uses token symbols (e.g. BTC, ETH, HYPE) - Both modes use the same `timeframe` parameter
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_jup_dca Checking Jupiter DCA orders ~84
Get Jupiter DCA (dollar-cost-averaging) orders opened against a Solana token, with deposit size, amount spent so far, amount accumulated and order status. Use this to see scheduled buying or selling pressure that has not hit the market yet; use token_dex_trades for trades already executed. Solana tokens only.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_ohlcv Loading price data ~726
Get OHLCV (Open, High, Low, Close, Volume) price data for a token with automatic interval resolution. Supports EVM chains and Solana for on-chain tokens, AND Hyperliquid perpetual futures. For Hyperliquid perps, pass `chain="hyperliquid"` and use the perp symbol as `tokenAddress` (e.g. "BTC", "HYPE" for native perps; "XYZ:ORDI" for XYZ-namespaced perps — prefix is normalized automatically). **YOU MUST USE THIS** over `general_search` to get prices. **`general_search` prices are delayed and often incorrect.** To get **LATEST** price set from to '5MIN_AGO' and to to 'NOW'. Resolution is automatically calculated based on the date range - < 6 hours: 5 minutes - 6 hours - 1 day: 15 minutes - 1-3 days: 30 minutes - 3-7 days: 60 minutes (1 hour) - 7-90 days: Daily - 90+ days: Weekly Columns returned: - **Interval Start**: Timestamp of the start of the interval (datetime: YYYY-MM-DD HH:MM:SS) - **Open**: Opening price of the interval - **High**: Highest price of the interval - **Low**: Lowest price of the interval - **Close**: Closing price of the interval - **Volume USD**: Volume in USD of the interval Additional columns (when includeMarketCap=true): - **Open Market Cap**: Opening market cap in USD - **Close Market Cap**: Closing market cap in USD - **High Market Cap**: Highest market cap in USD - **Low Market Cap**: Lowest market cap in USD Example Usage: Get OHLCV for WETH over the past week (auto-resolution): ``` { "chain": "ethereum", "tokenAddress": "0xba5ddd1f9d7f570dc94a51479a000e3bce967196", "date": { "from": "7D_AGO", "to": "NOW" } } ``` Get OHLCV for WETH over 30 days (will use daily resolution): ``` { "chain": "ethereum", "tokenAddress": "0xba5ddd1f9d7f570dc94a51479a000e3bce967196", "date": { "from": "30D_AGO", "to": "NOW" } } ``` Get OHLCV for WETH for last 20 minutes (will use 5 minute resolution):…
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_pnl_leaderboard Finding top performers ~1,093
Upto 25 results (per page) of trader PnL for a token. Use the sorting and filtering options to narrow down the results. **Modes:** - `onchain_tokens` (default): Analyze on-chain tokens by contract address - `perps`: Analyze Hyperliquid perpetual futures by symbol (chain auto-set to "hyperliquid") — supports native tokens **NOTE:** This tool does not support native tokens (so11111111111111111111111111111111111111112, 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee) in `onchain_tokens` mode. Native tokens (by symbol - SOL, ETH, ARB etc) ARE fully supported in `perps` mode. Returns: Trader performance rankings as markdown. Returns empty string if no trading data found. Columns returned: - **Address**: Trader's wallet address - **Label**: Nansen label of the trader - **Total PnL**: Combined realized and unrealized PnL (currency formatted, can be negative) - **Total ROI**: Total return on investment as percentage (percentage formatted) - **Realized PnL**: Profit/loss from completed trades (currency formatted, can be negative) - **Realized ROI**: Return on investment from realized trades only (percentage formatted) - **Unrealized PnL**: Current profit/loss on open positions (currency formatted, can be negative) - **Unrealized ROI**: Return on investment from unrealized positions only (percentage formatted) - **Token Holdings**: Current token quantity held (numeric formatted) - **Holdings USD**: Current USD value of token holdings (currency formatted) - **Token Price**: Current price per token (price formatted) - **Peak Token Holdings**: Maximum token quantity ever held in the date range (numeric formatted) - **Peak Holdings USD**: Maximum USD value ever held in the date range (currency formatted) - **Still Holding %**: Percentage of peak holdings still held (percentage formatted) - **Total Trades**: Number of trades executed by this address - **Net Flow**: Net money flow - negative means net seller (c…
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_quant_scores Analyzing token quant scores ~334
Get Nansen Score Indicators for a token - quantitative risk and reward signals. Use this tool when assessing a token's risk/reward profile, evaluating buy/sell decisions, or when the user needs quantitative data to make trading decisions. Returns: Token risk/reward indicators as markdown with interpretation guidance. Token info: - **Market Cap**: Current market cap in USD - **Market Cap Group**: largecap (>$1B), midcap ($100M-$1B), or lowcap (<$100M) - **Is Stablecoin**: Whether token is a stablecoin (some indicators don't apply to stablecoins) Fields returned per indicator: - **Score**: Signal classification (bullish/neutral/bearish for reward; low/medium/high for risk) - **Signal**: Raw numeric value of the indicator - **Percentile**: Rank vs same market cap group (0-100%) - **Last Trigger**: Date when signal was last calculated Indicator types: - **Reward Indicators**: price-momentum, funding-rate, chain-fees, chain-tvl, protocol-fees, trading-range - **Risk Indicators**: btc-reflexivity, liquidity-risk, token-supply-inflation, concentration-risk, cex-flows Notes: - Not all indicators available for every token/chain combination - Percentile compares against same market cap group (largecap >$1B, midcap $100M-$1B, lowcap <$100M)
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_recent_flows_summary Analyzing recent activity ~414
Get an on-chain flow snapshot across **ALL** wallet categories in one call. This tool supports native ETH on Ethereum and native SOL on Solana, and is the correct choice for standard lookbacks such as 1d. Returns **TOTAL** token flows per segment: 1. Public Figures 2. Top PnL Traders 3. Whales 4. Smart Traders 5. Exchanges 6. Fresh Wallets Inflow and outflow of tokens between the segments is CRITICAL in identifying token price trends. The values provided are **aggregated over the specific lookback period (last 5min, 1d, 7d etc) specified**. If you have SPECIFIC date ranges in mind, use `token_flows` instead. **NOTE** Use `token_flows` for more granular data as it can filter between exact dates and provides HOURLY breakdowns. Returns: Categorized token flow analysis as markdown. For each segment, returns: - Flow amount in USD - Ratio compared to average flow - Number of wallets Format: "{Segment} wallet flow of {amount} ({ratio}x average, from {count} wallets)" Notes: - Positive flow = net buying, negative flow = net selling - For Exchange Flow, positive means more inflow to exchanges, negative means more outflow from exchanges - Categorizes market participants by their historical behavior and characteristics NOTE: Bitcoin is not supported. DO NOT use this tool for bitcoin. **Modes:** - `onchain_tokens` (default): On-chain token flow intelligence across cohorts - `perps`: Hyperliquid perpetual futures — returns position intelligence (current aggregate long/short/total USD by cohort: Smart Money, Whales, Public Figures). Native tokens (SOL, ETH, BTC etc) are fully supported in perps mode.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_sectors Listing token sectors ~18
List valid token sectors for token discovery filters.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_technical_indicators Loading technical indicators ~657
Get a technical-analysis snapshot for a token: SMA(20/50/200), EMA(12/26), RSI(14), MACD(12,26,9), Bollinger Bands(20, 2σ), ATR(14), and rolling VWAP(20), computed from the last 260 closed candles at an explicit timeframe. Supports EVM chains and Solana for on-chain tokens, AND Hyperliquid perpetual futures. For Hyperliquid perps, pass `chain="hyperliquid"` and use the perp symbol as `tokenAddress` (e.g. "BTC", "HYPE" for native perps; "XYZ:ORDI" for XYZ-namespaced perps — prefix is normalized automatically). **YOU MUST USE THIS** for technical analysis instead of computing indicators from raw `token_ohlcv` candles — it uses far more history (260 closed candles) and charting-platform conventions (SMA-seeded EMA, Wilder RSI/ATR, population-σ Bollinger). Timeframes (explicit, no auto-resolution): - 5m / 15m / 30m / 1h / 4h: intraday and short-horizon analysis - 1d (default): swing/position horizon - 1w: long-term trend Output: a snapshot header (candles used, date range, last close, 5-candle price change) plus one row per indicator, each with a 5-candle trend delta so you can read direction, not just level: - **SMA 20/50/200**: values, price vs each, MA slopes - **EMA 12/26**: values, spread %, widening/narrowing - **RSI(14)**: level, prior candle, 5-candle change - **MACD(12,26,9)**: line/signal/histogram, rising/falling, candles since signal cross - **Bollinger(20,2σ)**: bands, %B, bandwidth and its change - **ATR(14)**: value and % of price (volatility), rising/falling - **VWAP(20)**: value, price vs VWAP Indicators without enough closed-candle history render as n/a (e.g. SMA200 on young tokens); the candle count used is always reported. VWAP is n/a on Hyperliquid 5m-1h timeframes (volume is NULL in those views) — use 4h or 1d for Hyperliquid VWAP. Example Usage: Daily technical snapshot for WETH: ``` { "chain": "ethereum", "tokenAddress": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2", "timeframe": "1d" } ``` 4…
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_transfers Tracking token transfers ~1,251
Get 25 token transfers (per page) for a specific token based on the sort order. Default is most recent transfers first. **NOTE:** This tool does not support native tokens (so11111111111111111111111111111111111111112, 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee). Columns returned: - **Time**: Timestamp when the transfer occurred (block_timestamp: ISO 8601 format) - **From Label**: Source address label (from_address_label: sender of tokens) - **To Label**: Destination address label (to_address_label: receiver of tokens) - **From Address**: Raw source address (from_address: hex address) - **To Address**: Raw destination address (to_address: hex address) - **Amount**: Quantity of tokens transferred (transfer_amount: numeric) - **Value USD**: USD value of the transfer at time of transaction (transfer_value_usd: currency formatted) - **Type**: Transfer category (transaction_type: DEX, CEX, transfer, etc.) - **Tx Hash**: Blockchain transaction hash for verification (transaction_hash) Sorting Options (all fields support "asc"/"desc"): Available for sorting: timestamp, amount Examples: # Basic request (most recent transfers first) ``` { "chain": "ethereum", "tokenAddress": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab", "dateRange": {"from": "24H_AGO", "to": "NOW"}, "orderBy": "timestamp", "order_by_direction": "desc" } ``` # Smart money only filter (largest transfers first) ``` { "chain": "ethereum", "tokenAddress": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab", "dateRange": {"from": "7D_AGO", "to": "NOW"}, "transferOriginCategories": ["all_transfers"], "onlySmartTradersAndFunds": true, "orderBy": "amount", "order_by_direction": "desc" } ``` # Filter by DEX only with minimum transfer value (USD) ``` { "chain": "ethereum", "tokenAddress": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab", "dateRange": {"from": "24H_AGO", "to": "NOW"}…
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
token_who_bought_sold Finding recent traders ~270
Get TOTAL amount of tokens bought/sold by address for a token on DEX (Decentralised Exchanges) ONLY. Use this tool to find out WHO is buying or selling a token (on DEX) AND then you can check if they are liquidating profits or accumulating more. Returns: Aggregated buyer/seller activity as markdown. Returns empty string if no trading data found. Columns returned: - **Address**: Trader's wallet address - **Label**: Nansen label of the address - **Bought Token Volume**: Total quantity of tokens purchased - **Sold Token Volume**: Total quantity of tokens sold - **Gross Token Volume**: Combined buy and sell volume in tokens - **Bought Volume USD**: USD value of all token purchases - **Sold Volume USD**: USD value of all token sales - **Gross Volume USD**: Combined USD trading volume Sorting Options: You can sort asc or desc by bought_volume_usd or sold_volume_usd Notes: - buy_or_sell parameter filters for "BUY" (net buyers) or "SELL" (net sellers) - Aggregates all trading activity within the specified time range
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
transaction_lookup Looking up transaction details ~31
Get comprehensive transaction details including token transfers.
| Name | Type | Req | Description |
|---|---|---|---|
| chain | string | – | – |
| transaction_hash | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
wallet_pnl_for_token Calculating token performance ~110
Get PnL stats for a specific token traded by the input address during a specific date range. Use this tool for analysing the performance of the wallet for the specific token over a time period. Chain: pass 'hyperliquid' for a perp coin — there `tokenAddress` is the perp SYMBOL (e.g. 'BTC', 'HYPE', 'xyz:CL'), not a contract address. Every other chain expects a token contract address.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
wallet_pnl_summary Analyzing wallet performance ~123
Get aggregate stats of overall realized PnL for the input address. For Hyperliquid perp traders (chain='hyperliquid'), includes realized PnL from fills plus a current unrealized snapshot of open positions. For chain='all'/'evm' on an EVM address, reports spot/on-chain and Hyperliquid perp results as separate sections (never summed). For a single named chain, this tool covers realized PnL only. Use this tool for analysing the performance of the wallet over a time period.
| Name | Type | Req | Description |
|---|---|---|---|
| request | – | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
What is the Nansen MCP server?
Nansen is an MCP server listed in the public MCP registry as io.github.nansen-ai/nansen-mcp. Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics. This page covers its hosted endpoint (https://mcp.nansen.ai/ra/mcp/).
Is the Nansen MCP server safe to use?
Nansen scores 75 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Nansen MCP server expose?
Nansen exposes 50 tools: smart_traders_and_funds_token_balances, smart_traders_and_funds_perp_trades, smart_traders_and_funds_netflow, smart_traders_and_funds_dex_trades, smart_traders_and_funds_dcas, and 45 more. Their descriptions and schemas cost roughly 15,846 tokens of context every time the server is loaded.
Does the Nansen MCP server require authentication?
No. We connected to Nansen without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the Nansen MCP server still maintained?
Nansen is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.