Nansen

Server Details

Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 54 days
Last Tested: 2026-10-10 18:12
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.6/5.0

Scored 2026-10-07 13:40 across 50 tools

Disambiguation4/5

Tools are largely distinguished by scope prefixes (address_, token_, entity_, prediction_market_, smart_traders_and_funds_, wallet_), and descriptions explicitly cross-reference siblings (e.g. token_dex_trades vs address_dex_trades, token_flows vs token_recent_flows_summary). There are a few families with many similar-sounding members (four PnL leaderboards, three flow tools, several PnL/portfolio tools), but the descriptions provide clear disambiguation guidance.

Naming Consistency4/5

Nearly all names are snake_case with a predictable domain_prefix_object pattern (address_counterparties, token_ohlcv, prediction_market_lookup, smart_traders_and_funds_netflow). A few names break the noun_action rhythm (general_search, entity_name_search, growth_chain_rank, nansen_score_top_tokens, transaction_lookup), but the overall convention is stable and readable.

Tool Count2/5

50 tools is well into the heavy range, exceeding the 25+ threshold for a score of 2. While Nansen's breadth (addresses, tokens, entities, perps, prediction markets, smart money) partially justifies this, the surface is large enough that an agent must reason carefully across many near-sibling tools.

Completeness4/5

The surface covers a very broad domain: address activity, labels, portfolios, PnL, netflows, token info/OHLCV/technical indicators/holders/transfers, smart-money cohorts, Hyperliquid perps, and full Polymarket lifecycle. Coverage is strong with few obvious dead ends, though the sheer scale means some niche operations (e.g. mutation/export operations) are naturally absent.

Available Tools

50 tools

address_counterpartiesAnalyzing wallet connections

Read-only

Inspect

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"} }

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes	Complete request for address counterparties (flattened).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

address_counterparties_batchComparing wallet connections

Read-only

Inspect

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 }

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes	Complete request for batch address counterparties (flattened). Wallet addresses only. Use AddressCounterpartiesRequest for one wallet or for an entity name.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

address_dex_tradesChecking wallet DEX trades

Read-only

Inspect

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"} }

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

address_first_funderFinding the first funderA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the read-only, non-destructive, open-world nature. The description adds behavioral context beyond that by explaining the result is resolved across all chains and that no chain argument is required. This is meaningful and consistent with the annotations.

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?

Three sentences, all substantive: the core behavior, the intended use case, and the cross-chain parameter clarification. There is no filler, and the most important information is front-loaded.

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

Completeness5/5

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

For a single-parameter, read-only lookup with an output schema and safety annotations, the description is complete. It covers what the tool returns, why to use it, and the key behavioral nuance about chain resolution. Nothing essential is missing for an agent to invoke it correctly.

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 0%, so the description must compensate for parameter meaning. It does clarify that the lookup target is an EVM wallet and explicitly says no chain argument is needed, which adds value. However, it does not explain the request wrapper structure or address format, leaving the generic 'request' parameter and its anyOf schema somewhat ambiguous.

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 specific verb and resource: 'Get the first address that ever funded an EVM wallet,' and also names the returned fields (transaction hash, chain, timestamp). This clearly distinguishes it from sibling address_* tools, especially with the explicit note that no chain argument is needed because resolution is cross-chain.

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

Usage Guidelines4/5

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

It gives a concrete use case: attribute an unlabelled wallet to a known entity, since the first funder is often a CEX withdrawal or another wallet the same owner controls. It does not explicitly name alternatives or state when not to use it, but the context is clear enough to guide selection among the many sibling tools.

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

address_historical_balancesChecking balance historyC

Read-only

Inspect

Get historical native coin & token balances of address.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes	Complete request for address historical balances (flattened).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no note on granularity of 'historical' data, sampling, pagination, or whether 'all' chains is expensive/open-world heavy despite openWorldHint=true.

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 zero waste. It is appropriately terse, though terseness here edges toward under-specification rather than tightness.

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?

An output schema exists, so return values need not be explained, and the nested schema fully documents inputs. Still, for a tool with entity-vs-address branching and a chain='all' default, the description is thin enough that an agent lacks orienting context on scope and cost.

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%, with clear documentation of the address/entity_id mutual exclusivity, lookbackDays enum, and suspiciousFilter. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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 and resource ('Get historical native coin & token balances of address'), which is clearly distinct from fetching transactions or counterparties. However, it never differentiates itself from close siblings like address_portfolio (presumably current) or smart_traders_and_funds_historical_token_balances, so the agent must guess.

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?

No when-to-use guidance, no prerequisites, and no named alternatives despite a crowded address_* and historical-balance family. The agent gets no signal on when this beats address_portfolio or the smart_traders historical-token-balances sibling.

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

address_labelsLooking up address labelsA

Read-only

Inspect

Get the standard labels for one wallet address.

This tool returns identity, behavioural, and protocol labels. It does not return premium labels.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes	Request for the standard labels of one wallet address.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare the tool read-only and non-destructive. The description adds meaningful behavioral context by disclosing the exact label categories returned and the notable limitation that premium labels are not returned, which goes beyond the structured annotations.

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 two compact sentences with no filler. It front-loads the core action in the first sentence and adds the key exclusion in the second, making it easy for an agent to parse quickly.

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?

Given the rich nested input schema, presence of an output schema, and safety annotations, the description is nearly complete. It clearly defines the tool's scope and key exclusion, though it could briefly mention an alternative for premium labels or define 'standard labels' more precisely.

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 every parameter is already documented in the input schema. The description adds little parameter-level meaning beyond confirming the tool targets a single wallet address, so the baseline score of 3 is appropriate.

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 resource: 'Get the standard labels for one wallet address.' It further specifies the label categories returned (identity, behavioural, protocol) and explicitly excludes premium labels, which distinguishes it from other address-related 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?

The description conveys when to use the tool—when standard labels for a wallet are needed—and clarifies that premium labels are not included. However, it does not name an alternative tool or provide explicit when-not-to-use guidance, leaving some routing to inference from the sibling list.

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

address_perp_positionsGetting wallet Hyperliquid positions and liquidation riskA

Read-only

Inspect

Get a wallet's Hyperliquid positions and liquidation risk without a portfolio lookup.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes	Complete request for a wallet's open Hyperliquid perpetual positions.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'without a portfolio lookup' scoping detail, which clarifies behavior. However, it doesn't disclose what the output contains beyond positions and liquidation risk, nor any rate limits or data freshness. With annotations covering the main behavioral traits, a 3 is appropriate.

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?

One sentence with zero waste. The core action and the key differentiator ('without a portfolio lookup') are front-loaded. Every word earns its place.

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?

The tool has a rich output schema and 100% parameter schema coverage, so the description doesn't need to explain return values or parameters. The only minor gap is that it doesn't mention the optional filters/sorting capabilities, but those are fully documented in the schema. For a read-only lookup tool with strong structured metadata, this is nearly complete.

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 documents the address and all filter/orderBy fields thoroughly. The description adds no parameter-level meaning beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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

Purpose5/5

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

The description states a specific verb ('Get'), a specific resource ('a wallet's Hyperliquid positions and liquidation risk'), and a distinguishing constraint ('without a portfolio lookup'). This clearly differentiates it from sibling tools like address_portfolio and address_historical_balances. The title reinforces the purpose.

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

Usage Guidelines4/5

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

The description implies when to use this tool: when you need positions and liquidation risk specifically, and explicitly excludes the portfolio lookup path. However, it doesn't name sibling alternatives or state when NOT to use it (e.g., use address_portfolio for full portfolio context). The 'without a portfolio lookup' phrase gives some exclusion guidance but not a full routing rule.

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

address_portfolioLoading portfolio dataA

Read-only

Inspect

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"
}
```

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail beyond that: it states that Hyperliquid positions include liquidation prices, that entity queries return only on-chain balances, and that the output is pre-formatted markdown to be presented verbatim. These are operational traits an agent must know and are not in the annotations. This exceeds the baseline for annotation-covered tools.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but each section earns its place: purpose, mode list, entity behavior, output-format instruction, and four examples. It is front-loaded with the purpose and uses bullet lists for readability. A small redundancy ('This tool provides flexible portfolio analysis...') could be trimmed, but overall it is well-structured and not bloated.

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?

Given the tool's complexity (multiple modes, wallet vs entity, output format), the description covers all necessary details. It explains mode semantics, entity limitations, output formatting, and provides working examples. Since an output schema exists, return-value explanation is not required. No critical information is missing for an agent to call 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?

Schema description coverage is 0% for the top-level 'request' parameter, so the description must fully compensate. It does so admirably by defining each mode, providing concrete JSON examples for wallet (all, defi, hyperliquid) and entity queries, and clarifying the mutual exclusivity of walletAddress and entity_id. This is far more informative than the bare schema.

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 specific verb+resource: 'Get comprehensive portfolio overview for a wallet address or entity.' It clearly enumerates the modes and the entity behavior, making it easy to distinguish from focused siblings like address_perp_positions or address_historical_balances. The purpose is unambiguous and action-oriented.

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

Usage Guidelines4/5

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

The description explains the modes and when to use each, and explicitly notes that entities return only token balances. However, it does not explicitly state when to prefer a sibling tool (e.g., address_perp_positions for only perp positions) or provide exclusion criteria. The mode guidance is strong but lacks explicit alternatives, so a 4 is appropriate.

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

address_related_addressesFinding related walletsA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes	AddressRelatedAddressesRequest containing parameters and pagination settings

Output Schema

ParametersJSON Schema

Name	Required	Description
`rows`	No
`chains`	No	Chains that were queried.
`address`	No
`message`	No	Notice or error text when the tool returns no data rows.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already mark this as read-only and non-destructive, but the description adds meaningful behavioral detail: it narrows the result scope to a specific list of connection types, cross-references another sibling tool, and warns about a common misinterpretation around exchange withdrawal addresses. This goes well beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by focused caveats and cross-references. All sentences earn their place, though the minor typo 'the the' and slightly awkward wording in the final caveat keep it from being perfectly polished.

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?

Given the tool has only one parameter, a fully covered schema, an output schema, and clarifying annotations, this description is complete. It tells the agent what the tool returns, what it excludes, which sibling to use for broader results, and how to interpret a specific edge case.

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 documents the address and chain parameters. The description does not add parameter-level detail, but it does clarify that the input is an address and that the output is about its related addresses. This meets the baseline for a fully-covered schema.

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

Purpose5/5

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

The description states a clear verb and resource: 'Get information about related addresses of an input address.' It also distinguishes itself from siblings by explicitly listing the special connection types included and telling the agent to check address counterparties for related wallets, so there is no confusion with address_counterparties or address_first_funder.

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

Usage Guidelines5/5

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

The description explicitly says this tool only includes special connections and that to get related wallets the agent should also check 'address counterparties.' It also provides a domain-specific caveat about exchange withdrawal addresses not belonging to the same entity, which clarifies when the data should be interpreted cautiously.

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

address_transactionsFetching transaction history

Read-only

Inspect

Get list of 20 MOST RECENT transactions made by an address (per page). Only the latest transactions according to the date range are returned.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

entity_name_searchSearching entity namesA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`max_results`	No	Maximum number of entity names to return (default 25)
`search_query`	Yes	Partial entity name, at least 2 characters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already mark this as read-only and non-destructive, and the description adds matching behavior beyond that: case-insensitive matching, matching anywhere in the name, and returning exact entity names. This gives the agent useful expectations without contradicting the annotations.

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?

Three sentences carry the purpose, use case, example, and routing rule with no filler. The main behavior is front-loaded before the alternative guidance.

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 tool is simple, has full schema coverage, annotations, and an output schema, so the description does not need to explain return formats. It covers purpose, usage timing, matching semantics, and alternatives, making it complete for an agent to invoke correctly.

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

Parameters4/5

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

The input schema already documents both parameters with 100% coverage, so the baseline is a 3. The description adds value by explaining how search_query is interpreted (case-insensitive, partial, matches anywhere) beyond the schema's 'Partial entity name' phrasing.

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 clearly states a specific verb and resource: search Nansen entity names by partial name and return exact matching names. It also distinguishes itself from general_search, which is for tokens or addresses, so an agent can tell sibling tools apart.

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?

It gives an explicit when-to-use rule: when a downstream tool needs an exact entity name but the user provided an approximate one, with a concrete example. It also states the alternative for tokens/addresses, making the routing decision unambiguous.

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

general_searchSearching tokens, companies, and addressesA

Read-only

Inspect

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)

ParametersJSON Schema

Name	Required	Description	Default
`chain`	No	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 to the query string. Valid values: "ethereum", "solana", "base", "bnb", "polygon", "arbitrum", "avalanche", "optimism", etc.
`query`	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.
`max_results`	No	Maximum number of results (default: 25, max: 25)
`result_type`	No	Type filter - "token", "entity", "wallet", "eoa", "stock", or "any"	any

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond annotations: it is the entry point, it does not support NFTs, it resolves labels and domains, and it reports price, volume, contract address, chain, market cap, and supply 'when available.' This gives the agent useful expectations without repeating annotation data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the most important guidance ('FIRST entry point' and the prediction-market exclusion) before a well-organized bullet list of capabilities. It is somewhat long, but each bullet communicates a distinct lookup capability and the NFT caveat earns its place. No redundant sentences dilute the message.

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?

Given the output schema, the 100% parameter schema coverage, and the read-only/open-world annotations, the description is nearly complete. It covers the main search categories, return-style information, exclusions, and label/domain resolution. A small gap is that the title mentions 'companies' while the description only implies them through 'entities' and the schema's stock mode, but this is minor given the schema already clarifies stock search.

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

Parameters4/5

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

The input schema fully documents all four parameters, so the baseline is 3. The description adds value by expanding the meaning of `query` beyond the schema: it can be a token name, symbol, contract address, Nansen label, or a domain such as .eth/.sol. It also clarifies that entity search is part of the tool's scope, complementing the schema's stock-mode note.

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 'General search tool' and explicitly frames it as the 'FIRST entry point to look up for possible tokens, entities, and addresses related to a query.' It then lists concrete use cases, including token existence checks, token details, entity lookup, Nansen-label resolution, and domain resolution. It also distinguishes itself from prediction_market_lookup by explicitly saying not to use it for prediction markets.

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?

It gives explicit when-to-use guidance ('FIRST entry point'), an explicit when-not-to-use rule ('Do NOT use this tool for prediction markets'), and names the alternative tool ('use prediction_market_lookup instead'). It also adds a useful caveat about NFTs and name collisions, telling the agent to still check this tool when a query relates to a token even though Nansen MCP does not support NFTs.

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

growth_chain_rankChecking blockchain rankingsA

Read-only

Inspect

Get chain growth rankings by active addresses, transactions, gas fees and DEX volume.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes	GrowthChainRankRequest containing parameters and pagination settings

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description need not restate that. It adds that results are rankings segmented by several metrics, but it does not reveal behavior like aggregation method, data coverage limits, or pagination. This is acceptable given the annotations, but adds no strong behavioral 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?

A single, focused sentence that state the purpose and the key output dimensions without filler or redundancy. The core action and resource are front-loaded for quick parsing.

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?

With a full input schema, an output schema, and clear read-only annotations, the description covers what an agent needs to invoke the tool. It does not explain how to interpret the rankings or pagination, but for a straightforward read-only ranking query the provided context is sufficient.

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?

The schema descriptions cover the request, chain_type, and time_frame parameters fully, so the schema does the heavy lifting. The tool description adds no additional meaning to the parameters, such as how chain_type or time_frame affect the rankings, so the baseline score of 3 is appropriate.

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 names a specific verb ('Get'), a clear resource ('chain growth rankings'), and the exact dimensions being ranked (active addresses, transactions, gas fees, DEX volume). This clearly differentiates it from the many address-, token-, and prediction-market-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 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 use this tool versus alternatives, and no exclusions or prerequisites are stated. An agent must infer from the name and metrics that it is for chain-level growth analysis rather than address-, token-, or market-specific queries.

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

hyperliquid_leaderboardChecking Hyperliquid leaderboard

Read-only

Inspect

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 - Dates use UTC calendar boundaries, not rolling timestamps. Calendar end dates retain the next-day API boundary. - Null/empty means data is not available — do not read it as zero

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

nansen_score_top_tokensRanking top tokens by Nansen ScoreA

Read-only

Inspect

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).

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and non-destructive behavior. The description adds valuable behavioral context beyond that: daily batch updates, the performance_score >= 15 pre-filter, score ranges, dynamic indicator columns, and markdown output. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well organized with bold section headers, bullets, and example queries. Some redundancy exists (the performance_score >= 15 threshold appears twice, and the output format is stated more than once), but the structure keeps it skimmable.

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?

The description covers scoring semantics, return fields, dynamic columns, update cadence, and sibling-tool alternatives. It misses concrete guidance on how to pass the request payload and any pagination/result limits, but the output schema and annotations fill some gaps.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate, but it never explains the required 'request' object or the optional marketCapGroup parameter. The only hint is the generic word 'filter', which does not tell an agent how to structure input.

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 specific verb and resource: 'Discover and filter a daily list of attractive tokens using Nansen Score Indicators.' It clearly differentiates itself from token_quant_scores and token_discovery_screener, and states the core output: pre-filtered buy recommendations with Performance Score >= 15.

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

Usage Guidelines5/5

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

The description has an explicit 'When to use this tool vs token_discovery_screener' section with concrete conditions: use this for pre-scored recommendations without criteria, use the screener for live data or custom filters. It also tells agents to use token_quant_scores for specific token analysis and provides example queries.

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

prediction_market_address_pnlChecking prediction market address PnLA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses important behavioral nuances: 'The API gives no ROI or share count here. Do not state them.' and 'Blank PnL fields mean unavailable data, not zero.' These prevent the agent from making false inferences and add real value beyond the structured annotations.

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 well-structured with clear headings ('When to use', 'Key fields', 'Pitfalls') and front-loaded purpose. Every sentence adds meaningful information, and the format makes it easy to scan. It is detailed without being verbose.

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?

The description covers the key output fields, usage context, and common pitfalls. It does not explain the request parameter, but the schema provides details for the nested properties, and the output schema is present. Minor gaps like explicit pagination behavior are not covered, but the overall guidance is solid for a read-only analysis tool.

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

Parameters2/5

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

The description does not explain the 'request' parameter structure at all. Although the schema includes descriptions for the nested 'address' and 'page' properties, the schema coverage is reported as 0% (the top-level 'request' parameter has no description). The description also does not mention pagination or how to specify the wallet address, so the agent must infer this from the tool name and schema alone.

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

Purpose5/5

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

The description states a specific verb and resource: 'Prediction market PnL breakdown for a Polygon wallet, market by market.' It clearly distinguishes this tool from the sibling prediction_market_address_summary by focusing on per-market detail versus aggregate, so an agent can select the right one without opening the schema.

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

Usage Guidelines5/5

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

The description has a dedicated 'When to use' section and explicitly names the alternative: 'use prediction_market_address_summary for the aggregate.' It also gives guidance on summing rows for a wallet total, leaving no ambiguity about when this tool is appropriate.

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

prediction_market_address_summarySummarizing prediction market addressA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses important behavioral details: lifetime vs. derived field semantics, Total PnL = realized + unrealized, and the critical caveat that blank PnL fields mean unavailable data, not zero. It also warns that trade count, volume, and ROI are not provided by this API.

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 well organized with a one-line summary followed by concise, scannable sections for usage, key fields, and pitfalls. Every bullet earns its place and no redundant filler is present.

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?

This is complete for a read-only summary tool: it covers when to use it, what the lifetime metrics mean, what the API cannot provide, how to interpret missing values, and which sibling tool to fall back to. The output schema exists, so return-value details are already structured.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate for missing parameter meaning, but it never explains the `request` object or how the address/page parameters work. It only says the tool is 'for a Polygon wallet,' which lightly hints at the address field but does not convey the request structure or pagination behavior.

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 clearly identifies the tool as the wallet-level Polymarket summary, using 'Prediction market summary metrics for a Polygon wallet' and 'First wallet-level Polymarket tool for a quick trader overview.' It explicitly distinguishes itself from detailed trade/PnL tools, and the key-fields list grounds the purpose in concrete output semantics.

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

Usage Guidelines5/5

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

The 'When to use' section gives explicit conditions: use it before detailed address trades/PnL when the user wants a wallet profile, activity summary, or Polymarket activity check. It also names the sibling tool prediction_market_address_pnl as the alternative for per-market costs and proceeds.

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

prediction_market_address_tradesChecking prediction market address trades

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

prediction_market_lookupLooking up prediction marketA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context beyond this: it uses Polymarket's search API, natural language queries work well, recommends short 1–3 keyword queries, and mandates explicit statement when no suitable market is found rather than silently substituting. These behaviors are not inferable from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured with clear section headers (PM building blocks, When to use, Query tips, Output rules) and a helpful example event vs. market. Each sentence serves a purpose, though it could be tightened without losing value. It is front-loaded with the core purpose and uses formatting to improve scannability.

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?

Given the tool's complexity (nested request object, multiple configuration flags, integration with detail tools), the description is remarkably complete. It explains the event/market relationship, when to use this versus prediction_market_ohlcv, the importance of marketId for detail tools, query strategy, and output honesty rules. The presence of an output schema covers return values, so the description fills every other gap.

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

Parameters4/5

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

Schema description coverage is 0% for the top-level 'request' parameter, though nested properties have descriptions. The tool description compensates by explaining the purpose of queryVariant ('cleaner short keyword version') and includeEventMarkets ('also return child markets... for detail tools'), which adds meaning beyond the schema. It does not explicitly describe all parameters (e.g., maxCandidates, maxEventMarkets), but the schema covers those and the description's additions are genuine and useful.

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

Purpose5/5

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

The description states a specific verb and resource ('Search Polymarket for events and markets') and lists the search dimensions (name, topic, URL, slug). It also clarifies the event vs. market distinction, which differentiates it from siblings like general_search and prediction_market_ohlcv. The purpose is unambiguous and the tool is clearly distinguished.

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?

A dedicated 'When to use:' section explicitly states this is the first tool when the user provides a topic/event/slug/URL but no marketId. It explicitly says 'Do NOT use general_search for prediction markets' and routes price history queries to prediction_market_ohlcv. It also explains when to set includeEventMarkets and queryVariant, providing clear context and exclusions.

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

prediction_market_ohlcvLoading prediction market prices

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

prediction_market_orderbookChecking prediction market orderbookA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description adds critical behavioral nuance: order size is share quantity not USD, Yes and No are complementary, No bids act as resistance to Yes rallies, and No-side prices must be converted to Yes-equivalent before comparing with OHLCV. These guardrails materially change how an agent interprets results.

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 well-structured with bold section headers, and each bullet provides distinct, non-redundant guidance. No sentence is filler; the Yes/No relationship and pitfall details earn their space.

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?

Given the output schema exists, return format does not need to be described. The description covers when to use, how to source the required `marketId`, how to interpret values, and which sibling to prefer, making it complete for correct invocation.

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 0%, and the description does not explain the `request` object or `page` parameter, though the schema itself already documents `marketId` and `page` properties. It does add the useful prerequisite 'If `marketId` is unknown, call `prediction_market_lookup` first', but this conflicts slightly with the schema's `marketId` description which says to obtain it from `prediction_market_screener`.

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

Purpose5/5

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

The description states a specific resource ('Live orderbook for a Polymarket market') and enumerates its intended outputs: bid/ask depth, liquidity, and yes-share/no-share order structure. It also implicitly distinguishes itself from the sibling `prediction_market_ohlcv` by pointing to that tool for current odds and implied probability.

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?

It has an explicit 'When to use' bullet, a 'Pitfalls' section that explicitly routes to `prediction_market_ohlcv` for current odds, and a 'Prerequisites' telling the agent to call `prediction_market_lookup` if `marketId` is unknown. This leaves no ambiguity about when to pick this tool over siblings.

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

prediction_market_pnl_leaderboardChecking prediction market PnL leadersA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already mark the tool as readOnly and non-destructive, but the description goes well beyond that by defining the exact PnL formula, explaining each field, and warning that ROI, volume, and trade count are not provided. It also tells the agent how to behave when PnL fields are blank, which is valuable operational guidance.

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 organized into clear, scannable sections with front-loaded purpose, definitions, pitfalls, and prerequisites. Every section adds practical value, and the bullets make the longer content easy for an agent to parse.

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 tool with this complexity, the description is remarkably complete: it covers the PnL formula, field meanings, missing-data behavior, and prerequisites, while the output schema handles return shape. It falls slightly short due to the inconsistent marketId source guidance and the lack of explicit differentiation from similar PnL tools.

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

Parameters2/5

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

The top-level request parameter has 0% schema description coverage and the description does not explain the request object or the page parameter. It does note that marketId can be obtained via prediction_market_lookup, but this conflicts with the schema's instruction to get it from prediction_market_screener, and no other parameter semantics are compensated for.

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 specific definition: 'PnL leaderboard for a Polymarket market,' which names the resource and scope. It further narrows the purpose with 'Only for profitability claims' and explains the key PnL fields, making it clearly distinguishable from token- or address-level PnL siblings.

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

Usage Guidelines4/5

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

The 'When to use' section explicitly limits the tool to profitability claims, and the prerequisites section gives a concrete next step if marketId is unknown. It does not name sibling alternatives or give explicit when-not-to-use exclusions beyond profitability claims, so a small gap remains.

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

prediction_market_position_detailLoading prediction market positionA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnlyHint=true annotation, the description discloses important behavioral details: each row represents one outcome token of one wallet, a wallet holding both sides appears twice, and Position PnL applies only to the displayed row. These pitfalls and row-scoping notes add real interpretive value that an agent could not infer from annotations or the schema.

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 well-organized with bold section headers, concise bullets for key fields, an explicit pitfalls section, and a one-line prerequisite. Every sentence adds non-obvious information and the most important framing comes first.

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?

Given the output schema exists, the description still explains the meaningful fields, warns about duplicate rows for two-sided positions, and routes to prediction_market_lookup when marketId is unknown. This is sufficient for an agent to know what the tool returns, what the numbers mean, and what to do before calling it.

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?

Although the reported schema description coverage is 0%, the nested schema itself documents marketId and page with meaningful descriptions. The tool description adds a useful prerequisite for obtaining marketId, but it does not explain the request wrapper or the pagination parameter, so it only partially compensates for the top-level schema gap.

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 opens with 'Detailed position breakdown for a Polymarket market,' which names a specific resource and the kind of output an agent can expect. It is clear and distinct from the many trading-history siblings, though it does not explicitly contrast itself with nearby tools like prediction_market_address_summary or prediction_market_trades.

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

Usage Guidelines4/5

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

The description gives a concrete prerequisite and an explicit alternative: 'If marketId is unknown, call prediction_market_lookup first.' It also implies the tool is for inspecting positions in a specific market, which gives an agent context for when to choose it, but it does not exhaustively list when-not-to-use cases against the other prediction_market_* tools.

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

prediction_market_screenerScreening prediction marketsA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

The description discloses search behavior not captured by annotations: 'Literal-style matching on text and slugs, not fuzzy web search.' It also sets output-handling rules ('If a query returns no rows, do not invent a nearest match') and prevents overinference from titles, which is important for trustworthy results. Annotations already declare read-only and open-world, and the description adds substantial behavioral context beyond them.

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 organized with clear headers (When to use, Query tips, Output rules) and front-loads the core purpose. Every section earns its place by providing actionable guidance; there is no filler or repetition of schema details.

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

Completeness5/5

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

For a broad discovery tool with an output schema and annotations, the description covers use cases, exclusions, query formulation, empty-result handling, and output accuracy expectations. The combination of annotations, schema, and description leaves little an agent needs to invoke the tool correctly.

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

Parameters4/5

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

The input schema documents nested fields (mode, page, query, status, orderBy), but the tool description adds critical query semantics: 'Literal-style matching on text and slugs,' 'Prefer one short topic or slug fragment,' and 'Do not bundle unrelated topics.' It also maps to mode by naming markets/events/categories. This goes beyond the schema's generic 'Optional text query for filtering' description, though it does not elaborate on status or orderBy values.

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 specific verb and resource: 'Browse and sort Polymarket markets, events, or categories.' It further clarifies this is for 'broad discovery, screening, and ranked browsing across many markets,' and explicitly contrasts with the sibling `prediction_market_lookup`, so an agent can distinguish it without inspecting schemas.

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

Usage Guidelines5/5

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

It provides an explicit 'When to use' section stating the intended scope and a direct exclusion: 'Do NOT use this to resolve one named market/event/slug/URL — use prediction_market_lookup instead.' Query tips further guide usage with concrete examples and negative constraints (e.g., 'Do not bundle unrelated topics').

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

prediction_market_top_holdersFinding prediction market top holdersA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

The annotations declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds behavioral context such as: positions are share balances not USD notional, Position Value USD is marked value not payout, and output summary is based only on shown rows. This enriches the read-only nature but does not mention pagination specifics or rate limits, which is acceptable given the annotation coverage.

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 well-structured with purposeful sections labeled 'Key fields' and 'Pitfalls' and a 'Prerequisites' note. Every bullet adds value, front-loading the most critical interpretations and cautions. No redundant sentences; each provides operational guidance.

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?

Given the tool's complexity (nested request schema, potential ambiguity in interpreting positions and values) and the presence of an output schema, the description covers the critical pitfalls and prerequisites that an agent needs to avoid misinterpretation. It also references related tools for lookup, completing the context. Combined with the output schema, this is adequate for correct invocation.

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?

The input schema has one parameter 'request' with nested properties, and the schema description coverage is 0% (schema properties have their own descriptions but not summarized in the tool description). The tool description does not explain the parameters beyond referencing marketId in prerequisites admissions. For example, it doesn't clarify that marketId is required in the nested schema. With 0% coverage, the description should compensate, but it partially does by mentioning the prerequisite. It lacks detail on orderBy options, which are partially self-explanatory from enums, but the description doesn't add meaning beyond schema. Score 3 as baseline for low coverage with minimal compensation.

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

Purpose5/5

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

The description states a specific verb ('finding'), a specific resource ('top holders for a Polymarket market'), and clearly distinguishes it from siblings. It names a prerequisite tool and includes usage notes, making the purpose unmistakable despite the terse title. It is clear and specific, differentiating from other prediction_market tools.

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?

Explicitly states a prerequisite: if marketId is unknown, call prediction_market_lookup first. It also warns against over-interpreting data (e.g., not labeling positions as smart money without Nansen support), which helps the agent avoid misuse. The description effectively guides correct usage and alternatives.

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

prediction_market_tradesChecking prediction market trades

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

smart_traders_and_funds_dcasChecking Smart Money DCA ordersA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful scope and output context (Solana, deposit size, amount spent, order status), but it does not disclose pagination, default ordering, or other query behavior. No contradiction with annotations.

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?

Two sentences, front-loaded with the core purpose and followed by a single routing note. No filler, no repetition, every sentence earns its place.

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 read-only tool with an output schema, the description covers the core purpose, Solana scope, returned data categories, and the key sibling distinction. It omits pagination and default sort behavior, but the schema's property descriptions and output schema fill in much of the remaining detail.

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

Parameters2/5

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

Schema description coverage is reported at 0%, so the description needed to compensate by explaining how to use the sole `request` parameter. It does not: it only describes what the tool returns, not how to construct the request object. The nested schema fields are documented, but the description itself adds no parameter-level meaning.

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 specific verb and resource: 'Get Jupiter DCA (dollar-cost-averaging) orders opened by smart traders and funds on Solana.' It also names the included fields (deposit size, amount spent, order status) and explicitly distinguishes it from the one-off-swap sibling tool, so an agent can tell it apart from the many smart_traders tools.

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?

It states the intended scenario directly: 'Use this for scheduled accumulation intent.' It also names the alternative for the opposite case: 'use smart_traders_and_funds_dex_trades for one-off swaps.' This is an explicit when-to-use and when-not-to-use signal.

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

smart_traders_and_funds_dex_tradesTracking Smart Money DEX tradesA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: the data is individual per-wallet/per-transaction, and the population explicitly excludes whales/large holders/influencers, which shapes interpretation of results.

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?

Two sentences with no filler. The first sentence front-loads the scope, exclusions, and chain default; the second points to the relevant sibling. Every word earns its place.

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

Completeness5/5

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

For a read-only query tool with an output schema and safety annotations, the description covers the core semantics: granularity, population exclusions, chain scope, and the aggregated alternative. Nothing critical is missing for an agent to decide whether to call this tool.

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?

The prose adds little parameter-specific meaning beyond the default chain behavior; the heavy lifting is done by the schema, which documents each filter (chains, orderBy, tradeValueUsd, traderAddress, token symbols, includeSmartMoneyLabels). Although context reports 0% schema description coverage, the embedded schema clearly describes the nested filters, so a baseline of 3 is appropriate.

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?

States a specific verb and resource: get individual DEX trades made by smart traders and funds, per wallet and per transaction. It explicitly excludes whales/large holders/influencers and names the default chain behavior, which distinguishes it from sibling tools like netflow, perp_trades, and dcas.

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

Usage Guidelines4/5

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

Provides a clear routing cue: use this for exactly which wallet bought/sold what, and use smart_traders_and_funds_netflow for the aggregated view. It does not explicitly address other sibling alternatives, but the tool name and descriptions of those siblings make the distinction fairly obvious.

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

smart_traders_and_funds_historical_token_balancesReviewing Smart Money holdings history

Read-only

Inspect

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. This endpoint uses inclusive UTC calendar dates, not rolling timestamps.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

smart_traders_and_funds_netflowChecking Smart Money netflowsA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context by clarifying that data is aggregated, not per-wallet, and that whales/large holders/influencers are excluded, which materially affects interpretation of results.

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?

Two crisp sentences front-load the core behavior and end with a pointer to the relevant sibling. No filler words, and every clause adds decision-relevant information.

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?

Given the read-only annotations and the presence of an output schema, the description is sufficient for an agent to select and invoke the tool correctly. It covers the key dimensions of aggregation, exclusions, timeframes, and chain scope, though it could marginally benefit from mentioning default ordering or filtering options explicitly.

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?

The top-level schema has 0% description coverage, so the description partially compensates by explaining the core semantics: USD net flow per token over 1h/24h/7d/30d and per-chain filtering with a default of all chains. However, it does not explain the required request wrapper or any of the filter options beyond chains, leaving the nested schema to carry most parameter-level meaning.

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 clearly states a specific verb ('Get') and resource ('aggregated smart trader and fund net USD flow per token'), and explicitly scopes what is included and excluded ('EXCLUDES whales, large holders, influencers, etc.'). It also differentiates itself from a sibling tool by pointing to smart_traders_and_funds_token_balances for holdings.

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

Usage Guidelines4/5

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

The description gives a clear usage context: use this for what smart money is buying or selling right now, and use smart_traders_and_funds_token_balances for what they hold. It names one key alternative but does not fully cover when to choose other smart-money siblings like dcas, dex_trades, or historical balances.

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

smart_traders_and_funds_perp_tradesTracking Smart Money perp tradesA

Read-only

Inspect

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"
}
```

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral caveats beyond them: Hyperliquid-only, no date filtering, recent trades only, and that labels do not expand the address universe. The label warning is especially useful because it prevents a likely misinterpretation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well organized: purpose, caveats, returned columns, sorting, and examples are all separated. It front-loads the most decision-relevant constraints before the detailed column list. The column list is somewhat redundant given that an output schema exists, but it is scannable and not padded.

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 provides scope, exclusions, sorting contract, label semantics, and example request bodies, which is sufficient given the annotated schema and output schema. An agent has what it needs to invoke the tool correctly and avoid the common mistakes of label searching or expecting historical date filtering.

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

Parameters4/5

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

Schema description coverage is low (0%), so the description compensates by explaining sortable fields, the default orderBy behavior ('amount', direction desc), and the important includeSmartMoneyLabels semantics. The concrete JSON examples also clarify how parameters are passed. However, page, valueUsd, and traderAddress are not covered in prose, so some burden remains on the schema.

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 first sentence is specific: 'Get recent Hyperliquid perpetual futures trades from Smart Money addresses across all tokens.' This names the verb, resource, scope, and domain, and clearly differentiates it from sibling tools such as smart_traders_and_funds_dex_trades and smart_traders_and_funds_dcas.

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

Usage Guidelines5/5

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

The description explicitly says labels narrow the Smart Money cohort and are not a general label search. It also names the alternative for broad Smart Money activity: token_discovery_screener with traderType="sm". The Hyperliquid-only and recent-trades-only constraints further clarify when this tool is appropriate.

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

smart_traders_and_funds_pnl_leaderboardRanking Smart Money by PnLA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds behavioral context by specifying that it EXCLUDES whales and large holders, and details the PnL metrics and time windows (1/7/30/90/180 days). This goes beyond the annotations and helps the agent understand the exact scope of the leaderboard.

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 two sentences long, with the first sentence front-loading the core purpose and scope, and the second sentence providing usage guidance and an alternative. There is no fluff or redundancy, making it efficient for an agent to parse quickly.

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 read-only leaderboard tool with a rich input schema and an output schema present, the description provides enough context for the agent to understand the core functionality and when to use it. It does not describe the output format, but that is covered by the output schema. The main gap is that it does not mention the available filters (chains, labels) explicitly, though the schema covers them.

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?

The description mentions 'realized, unrealized and total USD PnL' and '1/7/30/90/180 day window', which directly map to the orderBy and timeframe parameters in the schema. However, it does not explain chains, orderByDirection, includeSmartMoneyLabels, or pagination. Since the schema itself has detailed descriptions for these properties, the description adds partial meaning but does not fully compensate for the 0% schema description coverage from the description side.

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 clearly states the tool ranks smart trader and fund addresses by PnL metrics, explicitly excludes whales/large holders/influencers, and names the specific sibling (token_pnl_leaderboard) for the alternative use case. This distinguishes it from the many sibling tools that focus on specific tokens or other smart-money data.

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

Usage Guidelines4/5

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

The description provides explicit guidance on when to use this tool ('to find the best performing smart money wallets') and when to use the alternative ('use token_pnl_leaderboard for the best performers on one specific token'). This covers the primary routing scenario, though it does not mention other relevant siblings like smart_traders_and_funds_dcas or perp trades.

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

smart_traders_and_funds_token_balancesChecking Smart Money positionsA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds meaningful behavioral context: aggregated rather than per-wallet data, category exclusions, 24h change, per-chain segmentation, and the 'all' default. It does not mention pagination or response size, but the output schema covers return shape.

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?

Two tight sentences: the first states the action, aggregation level, exclusions, chain behavior, and 24h change; the second points to filtering. No filler, repetition, or unnecessary detail.

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?

The description covers the essential decisions: aggregation level, exclusions, chain selection, and time-window change. Pagination and sorting are left to the schema, which is acceptable given the output schema exists; a brief pointer to the available filters would make it slightly more self-contained.

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

Parameters2/5

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

The prose only says 'Use filters to narrow down the results' and mentions chain selection; it does not explain page, orderBy, minHolders, includeStablecoin, includeNativeTokens, or includeSmartMoneyLabels. Although the nested schema has some descriptions, the reported schema description coverage is 0%, and the tool description itself does not compensate for parameter-level meaning.

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 specific verb and resource: 'Get aggregated ... smart trader and fund ... token balances and 24h change per chain.' It clearly distinguishes this tool from per-wallet views and explicitly excludes whales, large holders, and influencers, making its scope unambiguous relative to 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?

The description gives useful context: aggregate smart-money balances by chain, default to all chains or specify chains, and use filters to narrow results. However, it does not explicitly say when to prefer this over sibling tools like smart_traders_and_funds_historical_token_balances or smart_traders_and_funds_netflow, and offers no when-not-to-use guidance beyond 'not per wallet.'

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

token_current_top_holdersFinding top token holdersA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A5/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description goes far beyond these by disclosing pagination (25 per page), fallback behavior for unsupported sort values (falls back to holding_size and notes the change), mode-specific column sets, and restrictions on native tokens and stablecoins. It also notes that unsupported combinations are not errors but degrade gracefully.

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 exceptionally well-structured: it opens with a one-line summary, then uses headers (Note, Modes, Columns returned, Sorting Options, Examples, Restrictions) to organize dense information. Every section serves a distinct purpose—examples are practical, restrictions are clearly separated, and columns are listed per mode. There is no fluff; each sentence earns its place.

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?

Given the tool's complexity (two modes, many parameters, multiple restrictions), the description is complete. It covers modes, columns, sorting options, fallback behavior, native-token restrictions, SOL exclusion, and provides five examples covering the main use cases. An output schema exists, so return value details are covered there; the description adds the operational context an agent needs.

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 input schema provides descriptions for each parameter, the tool description adds substantial meaning through examples that show real parameter combinations (e.g., mode, chain, token_address, label_type, orderBy, includeSmartMoneyLabels). It clarifies the meaning of mode with defaults, explains the orderBy enum values per mode, and shows how filters like upnlUsd and positionValueUsd work in perps. This is far beyond the schema's terse descriptions.

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 specific, concrete statement: 'Get upto 25 (per page) top holders information for a specific token.' It clearly identifies the resource (token holders) and the action (retrieve), and distinguishes between onchain_tokens and perps modes. This differentiates it from sibling tools like token_flows or token_transfers, which have different scopes.

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

Usage Guidelines5/5

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

The description provides explicit usage guidance: it warns against using smart_money as a market proxy, explains the two modes and when each is appropriate, gives an explicit exclusion for SOL in onchain_tokens mode with a pointer to perps, and details sorting restrictions for native tokens/stablecoins. It also mentions alternative labelTypes to bypass limitations. This is comprehensive.

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

token_dex_tradesChecking latest DEX trades

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes	TokenDexTradesRequest containing parameters, pagination settings, and optional sorting

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

token_discovery_screenerDiscovering trending tokensA

Read-only

Inspect

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
Perps support orderBy='price_change' for every traderType. Prices use completed 5-minute buckets at the timeframe boundaries.
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", "bnb", "base"], "timeframe": "24h", "sectors": ["DeFi Lending (Money Markets)"], "netflow": {"from": 1000000} }

Find tokens which have a lot of buying activity (high nofBuyers and buyVolume)

Note that we added some filters to remove spam and low quality tokens. We added liquidity filter so that we only surface tokens which we can buy or sell.

We sort by `netflow` descending to get tokens with the most net buying activity.

{
    "chains": ["ethereum", "solana", "bnb", "base"],
    "timeframe": "24h",
    "liquidity": {"from": 100000},
    "buyVolume": {"from": 1000000},
    "marketCapUsd": {"from": 1000000},
    "nofBuyers": {"from": 10},
    "orderBy": "netflow",
    "orderByDirection": "desc"
}

Find Hyperliquid perps with high open interest and positive net flow

{
    "chains": ["hyperliquid"],
    "timeframe": "7d",
    "openInterest": {"from": 100000},
    "volume": {"from": 1000000},
    "netflow": {"from": 0},
    "nofTraders": {"from": 10},
    "orderBy": "netflow",
    "orderByDirection": "desc"
}

WARNING: To avoid timeouts, it's recommended to:

Use 4 chains or less at a time (API tends to timeout with more chains)
Use shorter timeframes (e.g., 24h or 1h instead of 7d or 30d)

Args:

Returns: Comprehensive token metrics as markdown. Returns empty string if no tokens found.

Columns returned:
- **Token Address**: Token address (e.g., 0x1234567890123456789012345678901234567890)
- **Symbol**: Token trading symbol (e.g., ETH, BTC, DOGE)
- **Chain**: Blockchain network (ethereum, solana, polygon, etc.)
- **Price USD**: Current token price in USD (currency formatted)
- **Price Change**: Price change percentage over the date range (percentage, can be negative)
- **Market Cap**: Current market capitalization (currency formatted)
- **Fully Diluted Valuation (FDV)**: Market cap if all tokens were circulating (currency formatted)
- **FDV/MC Ratio**: Ratio indicating how much supply is locked/vested (numeric, >1 means locked supply)
- **USD Volume**: Total trading volume in USD (currency formatted)
- **Buy USD Volume**: Total buy volume in USD (currency formatted)
- **Sell USD Volume**: Total sell volume in USD (currency formatted)
- **Net Flow USD**: Net flow (buys minus sells) in USD (currency formatted, can be negative)
- **DEX Liquidity**: Available liquidity for trading (currency formatted)
- **Inflow/FDV**: Inflow as percentage of FDV (percentage formatted)
- **Outflow/FDV**: Outflow as percentage of FDV (percentage formatted)
- **Token Age (Days)**: Days since token was first deployed
- **Sectors**: List of token sectors/categories

Hyperliquid perps columns (smart-money mode, when `onlySmartTradersAndFunds=true`):
- **Net Position** (`LONG $X` / `SHORT $X` / `FLAT`): current net direction. Use this when answering long/short questions.
- **Current Longs USD** / **Current Shorts USD**: gross notional on each side; sizing only, not direction.
- **Net Position Change**: delta over the timeframe — can be positive while Net Position is still SHORT.

Notes: - Positive Net Flow on spot tokens indicates more buying than selling - High FDV/MC Ratio suggests significant locked or vested tokens

Filtering Options (filters parameter): - Numeric Ranges: volume, liquidity, marketCapUsd, netflow, tokenAgeDays, nofTraders, nofBuyers, nofSellers, nofBuys, nofSells, buyVolume, sellVolume, fdv, fdvMcRatio, inflowFdvRatio, outflowFdvRatio - Categories: sectors (e.g. ["AI", "Meme"]), includeSmartMoneyLabels - Asset class toggles (spot chains only, default false for both): includeStablecoins, includeNativeTokens. Set true only when the user asks for stablecoins/native tokens specifically. - Trader Type: traderType (string: "all", "sm", "whale", "public_figure") - Use "sm" ONLY when user explicitly asks for "smart money". - Use "whale" ONLY when user specifically asks for whales or large holders. - Use "public_figure" ONLY when user asks for KOLs or popular figures. - Data with "sm", "whale", and "public_figure" is sparse — "whale" and "public_figure" are even sparser than "sm". Pairing any of these with other filters (volume, liquidity, netflow) is likely to return no results. - Only pair traderType="sm/whale/public_figure" with other filters (volume, liquidity, netflow) if the user request explicitly requires it. - Instead of pairing this with other filters, you can rely on orderBy to sort by netflow, volume, liquidity, etc.

**CRITICAL WARNING:** 'priceChange' is NOT a valid filter. You cannot filter for "tokens up > 10%". Use `orderBy="priceChange"` instead.

Sorting Options (orderBy field): Available fields (use with orderByDirection: "asc" or "desc"):

- **priceUsd**: Sort by token price
- **priceChange**: Sort by price change percentage
- **marketCapUsd**: Sort by market capitalization
- **volume**: Sort by total trading volume
- **buyVolume**: Sort by buy volume
- **sellVolume**: Sort by sell volume
- **netflow**: Sort by net flow (buys - sells)
- **liquidity**: Sort by DEX liquidity
- **nofTraders**: Sort by number of traders

(Note: Fields like `tokenAgeDays` or `outflowFdvRatio` are for FILTERING only, not sorting)

Default: orderBy="netflow", orderByDirection="desc"

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly/openWorld/non-destructive; the description adds real behavioral context beyond them: 25-per-page cap, max-5-chains trimming, dual spot+perps sections, unsupported filter/orderBy fallback to defaults, and smart-money data sparsity. It is marred by an internal naming inconsistency — it tells the agent to use orderBy='priceChange' while the schema enum is 'price_change', which risks a malformed call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and limits are front-loaded well, but the body is very long and includes a full 'Returns:' column-by-column section even though an output schema already exists, which is redundant per the tooling's own convention. Warnings and constraints are also restated in multiple places (top WARNING vs the CRITICAL WARNING on priceChange), reducing efficiency.

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 high-complexity screener with many nested filter parameters and a special-case chain, the description is near-complete: filtering, sorting, pagination, perps behavior, and edge-case warnings are all covered. The residual gap is the orderBy field-name mismatch, which could cause an incorrect invocation, so not a full 5.

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

Parameters4/5

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

Adds substantial meaning beyond the schema: which orderBy fields are valid vs filter-only (tokenAgeDays, outflowFdvRatio), the CRITICAL note that priceChange is not a filter, traderType pairing caveats, and that `page` applies to both sections. The camelCase ('priceChange') vs schema snake_case ('price_change') mismatch slightly undermines the added semantics.

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 opening states a concrete verb+resource: 'Get comprehensive token screening data across multiple blockchain networks with advanced filtering,' and clarifies it is for 'token discovery and finding trending tokens by combining different metrics.' This is far more specific than a tautology. It never names or contrasts a sibling (e.g. token_quant_scores, token_info), so it lands at 4 rather than 5.

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

Usage Guidelines4/5

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

Extensive when-to-use guidance: when to set traderType='sm'/'whale'/'public_figure', when to enable includeStablecoins/includeNativeTokens, how to handle the hyperliquid mix, and timeout avoidance (4 chains or less, shorter timeframes). It does not name alternative sibling tools, so no explicit alternatives/exclusions, keeping it at 4.

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

token_flowsTracking token movements

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes	TokenFlowsRequest containing parameters and pagination settings

Output Schema

ParametersJSON Schema

Name	Required	Description
`mode`	No
`rows`	No
`chain`	No
`date_to`	No
`message`	No	Notice or error text when the tool returns no data rows.
`date_from`	No
`pagination`	No
`token_address`	No
`holder_segment`	No

token_infoLoading token infoA

Read-only

Inspect

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

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds substantial behavioral context: it details the return format (markdown), the two modes with distinct fields, and notes about address vs symbol usage. It also provides example JSON structures, clarifying expected inputs. This goes well beyond the annotations and fully informs the agent of 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 description is long but well-structured, using headings, bullet lists, and examples. It front-loads the purpose and then systematically details fields, notes, and examples. Each section earns its place; there is no filler or repetition. The structure makes it easy to scan and reference.

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 complete for a tool of this complexity. It covers both modes, all parameters, the return fields for each mode, and practical notes (address vs symbol, timeframe options). The example JSONs are provided. With the output schema present (as indicated), the description does not need to explain return values further. Nothing critical is missing.

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?

Despite the schema coverage being reported as 0%, the description thoroughly explains all parameters. It covers mode (onchain_tokens vs perps), chain (with supported networks), timeframe (with allowed values), and tokenAddress (explaining address vs symbol). The examples clarify the exact format. The description compensates fully for the lack of schema-level parameter documentation.

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 clearly states the tool's purpose: 'Get token information — spot on-chain details or Hyperliquid perpetual futures stats.' It names the two modes and differentiates them, and the title 'Loading token info' aligns. The description distinguishes this tool from siblings like token_dex_trades or token_ohlcv by focusing on token info rather than specific transactions or price data.

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

Usage Guidelines4/5

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

The description provides clear guidance on when to use each mode: on-chain for spot details (contract addresses) and perps for Hyperliquid stats (symbols). It also explains the default mode and the distinction between address vs symbol. However, it does not explicitly mention when to use this tool instead of sibling tools like token_dex_trades or token_ohlcv, so no exclusions or alternatives are stated. This is clear context but lacks explicit 'when-not' guidance for other tools.

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

token_jup_dcaChecking Jupiter DCA ordersA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already convey readOnlyHint, openWorldHint, and non-destructiveness. The description adds meaningful context by clarifying that this surfaces scheduled buying/selling pressure and by naming the returned metrics (deposit size, amount spent, amount accumulated, status). It does not contradict annotations.

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?

Two tight sentences with no filler. The core purpose is front-loaded, followed by usage guidance and a chain restriction. Every sentence earns its place.

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?

Given an output schema exists and annotations cover safety, the description is largely sufficient: it provides purpose, a concrete use case, a sibling distinction, and a chain constraint. It omits filter behavior, but the schema documents the filtering parameters, so the practical gap is small.

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

Parameters2/5

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

Schema description coverage is reported as 0%, and the description does not compensate for the input parameters. It says nothing about tokenAddress, status, traderAddress, depositUsdValue, includeSmartMoneyLabels, or page; only output concepts are mentioned, so it adds little beyond the schema.

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 specific verb and resource: 'Get Jupiter DCA (dollar-cost-averaging) orders opened against a Solana token', and lists key returned fields. It also clearly distinguishes itself from token_dex_trades, so an agent can differentiate sibling tools without opening schemas.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool ('see scheduled buying or selling pressure that has not hit the market yet') and names the alternative for executed trades ('use token_dex_trades for trades already executed'). It also restricts scope to Solana tokens, leaving no ambiguity.

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

token_ohlcvLoading price data

Read-only

Inspect

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):
```
{
    "chain": "ethereum",
    "tokenAddress": "0xba5ddd1f9d7f570dc94a51479a000e3bce967196",
    "date": {
        "from": "20MIN_AGO",
        "to": "NOW"
    }
}
```

Get OHLCV for the BTC Hyperliquid perp over 7 days:
```
{
    "chain": "hyperliquid",
    "tokenAddress": "BTC",
    "date": {
        "from": "7D_AGO",
        "to": "NOW"
    }
}
```

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

token_pnl_leaderboardFinding top performers

Read-only

Inspect

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 (currency formatted, can be negative)

Sorting Options You can ONLY sort by pnl_usd_total, roi_percent_total, pnl_usd_realised, roi_percent_realised, pnl_usd_unrealised, roi_percent_unrealised, holding_amount, max_balance_held, nof_trades, still_holding_balance_ratio, netflow_amount

Filtering Options: 📋 List filters: trader_address, trader_address_label 📊 Numeric range filters: pnl_usd_realised, pnl_usd_unrealised, holding_amount, holding_usd, nof_trades, still_holding_balance_ratio, max_balance_held, max_balance_held_usd

Examples: # On-chain tokens (default mode) { "mode": "onchain_tokens", "chain": "ethereum", "tokenAddress": "0xa0b86a33e6ba3e5b9e4b1b1b1b1b1b1b1b1b1b1b", "dateRange": {"from": "30D_AGO", "to": "NOW"}, "orderBy": "pnl_usd_total", "order_by_direction": "desc" }

# Hyperliquid perpetual futures
```
{
  "mode": "perps",
  "tokenAddress": "ETH",
  "dateRange": {"from": "7D_AGO", "to": "NOW"}
}
```

# Advanced filtering: Find profitable active traders with significant holdings
```
{
  "chain": "ethereum",
  "tokenAddress": "0xa0b86a33e6ba3e5b9e4b1b1b1b1b1b1b1b1b1b1b",
  "dateRange": {"from": "30D_AGO", "to": "NOW"},
  "pnlUsdTotal": {"from": 1000, "to": 999999999},
  "nofTrades": {"from": 5, "to": 100},
  "holdingUsd": {"from": 10000, "to": 999999999},
  "stillHoldingBalanceRatio": {"from": 0.1, "to": 1.0},
  "orderBy": "roi_percent_total",
  "order_by_direction": "desc"
}
```

Notes: - Ranked by total PnL performance by default - Useful for identifying successful traders and copying strategies - Both ascending and descending sorts provide valuable insights (winners vs losers) - ONLY RETURNS TOP 25 RESULTS for the sort order. Hence the result is NEVER complete. - Make sure the sort order is relevant to your analysis as otherwise you will miss data.

** This tool does not support hyperevm as chain **

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

token_quant_scoresAnalyzing token quant scoresA

Read-only

Inspect

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)

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it explains the output structure (Score, Signal, Percentile, Last Trigger), notes that not all indicators are available for every token/chain combination, and mentions that some indicators don't apply to stablecoins. This goes beyond the annotations and gives the agent a clear picture of what to expect. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with purpose and usage, then details the output format and indicator types. It is somewhat long but every section adds value — the output field explanations and indicator categories are necessary for correct interpretation. No fluff, so it earns a 4.

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?

Given the tool's complexity (multiple indicator types, percentile comparisons, caveats), the description is fairly complete. It explains the output fields, indicator categories, and the note about availability. It does not explicitly state that a token address is required, but the schema makes that clear. The output schema exists, so return values are covered. Minor gaps exist (e.g., error handling, prerequisites), but overall the description provides enough context for an agent to use the tool correctly.

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

Parameters2/5

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

Schema description coverage is 0% — the tool description does not explain how to construct the 'request' parameter. The schema itself includes descriptions for 'chain' and 'tokenAddress', but the 'request' wrapper is an anyOf with two object types, which could confuse an agent. The description does not compensate by explaining that the tool requires a token address and chain, nor does it clarify the anyOf structure. With low schema coverage, the description was expected to fill the gap but does not, so this dimension scores low.

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 statement of what the tool does: 'Get Nansen Score Indicators for a token - quantitative risk and reward signals.' It specifies the resource (token) and action (get), and distinguishes itself from siblings like token_technical_indicators by focusing on risk/reward scoring. The purpose is unambiguous and specific.

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

Usage Guidelines4/5

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

The description explicitly states when to use the tool: '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.' This provides clear context. It does not mention when not to use it or alternative tools, but the explicit positive guidance is strong, so it earns a 4 rather than a 5.

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

token_recent_flows_summaryAnalyzing recent activityA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds meaningful behavioral context: aggregation over lookback periods, the interpretation of positive/negative flow, exchange flow semantics, and perps mode return details. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed and well-structured with sections, but somewhat long. It front-loads the core purpose and uses bullets for return values, though some redundancy exists (e.g., repeated notes on positive/negative flow). Still, every major sentence adds value and it is not bloated to the point of distraction.

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?

Given the tool's complexity, the description is remarkably complete: it covers scope, supported chains, return format, interpretation, limitations, modes, and proscriptions. With output schema present and annotations covering safety, nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry the burden. It explains modes (onchain_tokens vs perps), supported chains (ETH, SOL), lookback period options, and how mode defaults to perps for symbols. It also describes the request's flattened structure and return format, adding semantics far beyond the sparse schema.

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 clearly states the tool gets an on-chain flow snapshot across all wallet categories in one call, lists the segments, and explicitly contrasts with token_flows for specific date ranges. It is a specific verb+resource that distinguishes it from siblings.

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?

It provides explicit when-to-use guidance: correct for standard lookbacks like 1d, and explicitly names token_flows as the alternative for specific date ranges and hourly breakdowns. It also warns Bitcoin is not supported and instructs to use token_flows for granular needs, making selection unambiguous.

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

token_sectorsListing token sectorsA

Read-only

Inspect

List valid token sectors for token discovery filters.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with read-only behavior. The description adds only that it lists 'valid' sectors, implying a controlled vocabulary. It does not contradict annotations but also does not provide significant behavioral detail beyond what annotations already convey.

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, succinct sentence that front-loads the verb and resource. There is no fluff, and every word contributes to clarity. It is an example of concise and well-structured tool documentation.

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

Completeness5/5

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

For a tool with no parameters and an existing output schema, the description is fully sufficient. It explains the tool's purpose, and the output schema provides the return structure. No additional information is needed for an agent to call this tool correctly.

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

Parameters4/5

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

The tool has zero parameters, so schema coverage is trivially 100%. Per the rubric, a baseline of 4 is appropriate for no parameters. The description does not need to explain parameters and does not attempt to, so it does not detract from the baseline.

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 clearly states the tool's function: listing valid token sectors for token discovery filters. The verb 'List' and resource 'token sectors' are specific, and the purpose ties directly to token discovery, distinguishing it from sibling tools like token_discovery_screener that likely consume these sectors.

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

Usage Guidelines4/5

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

The description provides clear context that the tool's output is intended for token discovery filters, implying its use case. However, it does not explicitly mention when to use it versus alternatives or when not to use it, and it names no sibling tools. The context is sufficient for an agent to infer usage but lacks explicit exclusions.

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

token_technical_indicatorsLoading technical indicatorsA

Read-only

Inspect

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.

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-hour snapshot for the BTC Hyperliquid perp:
```
{
    "chain": "hyperliquid",
    "tokenAddress": "BTC",
    "timeframe": "4h"
}
```

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark this as read-only and non-destructive, and the description adds substantial behavioral context beyond that: computation from the last 260 closed candles, explicit timeframe with no auto-resolution, n/a behavior for insufficient history, and the Hyperliquid VWAP volume-NULL limitation. This is the kind of behavioral disclosure an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but it is well-organized with sections, bolded callouts, a timeframe list, and concrete examples. It earns most of its length; the detailed per-indicator output bullets are slightly redundant given an output schema exists, so it is not maximally lean.

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

Completeness5/5

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

For a complex tool covering multiple chains, perp futures, seven timeframes, and seven indicator groups, the description covers all operational edge cases: insufficient-history n/a, Hyperliquid symbol formats, timeframe semantics, VWAP unavailability, and the output shape. Nothing an agent needs to invoke it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description bears the full burden of explaining parameters, and it delivers. It explains that chain supports EVM/Solana and Hyperliquid, how to encode perp symbols as tokenAddress with namespace normalization, the full timeframe enum and its default, and that results are always computed up to now with no date range. The two JSON examples make the intended 'request' shape 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 specific verb and resource: 'Get a technical-analysis snapshot for a token', then enumerates exactly which indicators are computed. It distinguishes itself from the sibling token_ohlcv by explicitly saying it should be used instead of computing indicators from raw candles.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance with '**YOU MUST USE THIS** for technical analysis instead of computing indicators from raw token_ohlcv candles' and explains why (more history, charting conventions). It also gives concrete guidance for Hyperliquid perps, timeframe selection by horizon, and the VWAP-on-Hyperliquid caveat.

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

token_transfersTracking token transfers

Read-only

Inspect

Get 25 token transfers (per page) for a specific token based on the sort order. Default: the last 24 hours, largest transfers first (orderBy "amount", "desc").

Direction rules (fromAddress = the sender, toAddress = the receiver):

"Transfers of X", "X's transfers", "track X", and "what is X doing" do not name a direction. For these, make two calls with the same address: one with fromAddress, one with toAddress. Sort both by amount. Each call then shows different transactions: the largest sent and the largest received.
Use only fromAddress when the user asks what X sent (outflows, withdrawals, "sent to", "moved to an exchange").
Use only toAddress when the user asks what X received (inflows, deposits, "where did X get").
Do not put the same address in fromAddress and toAddress of one call. The filters combine with AND, so the call returns only transfers from the wallet to itself (usually none).
If the user names no wallet, do not add an address filter.

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 - amount (default): largest transfers first. Use it when the user asks about size, value, dollar amounts, the largest transfers, or whales. - timestamp: latest transfers first. Use it only when the user asks for the latest transfers or for a time order.

Examples: # Basic request (largest transfers in the last 24 hours, the default sort) { "chain": "ethereum", "tokenAddress": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab", "dateRange": {"from": "24H_AGO", "to": "NOW"}, "orderBy": "amount", "order_by_direction": "desc" }

# Latest transfers first (only when the user asks for the latest)
```
{
  "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"},
  "transferOriginCategories": ["dex"],
  "transferValueUsd": {"from": 1000}
}
```

# One wallet, no direction named: make two calls, both sorted by amount
# Call 1: what the wallet sent
```
{
  "chain": "base",
  "tokenAddress": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
  "dateRange": {"from": "7D_AGO", "to": "NOW"},
  "fromAddress": "0x2b060b9c89B8aD04e5E1fD40F1f327e41DD32c72",
  "orderBy": "amount",
  "order_by_direction": "desc"
}
```
# Call 2: what the wallet received
```
{
  "chain": "base",
  "tokenAddress": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
  "dateRange": {"from": "7D_AGO", "to": "NOW"},
  "toAddress": "0x2b060b9c89B8aD04e5E1fD40F1f327e41DD32c72",
  "orderBy": "amount",
  "order_by_direction": "desc"
}
```

Available Filters:

Address Filters:

fromAddress (str or list[str], optional): the wallet(s) that SENT the tokens Example: "0x2b060b9c89B8aD04e5E1fD40F1f327e41DD32c72" Example: ["0xaddr1", "0xaddr2"]
toAddress (str or list[str], optional): the wallet(s) that RECEIVED the tokens See the Direction rules at the top.

Transfer Origin Categories:

transferOriginCategories (list[str]): List of transfer types to include Possible values: ['dex', 'cex', 'non_exchange_transfers', 'all_transfers'] Default: ['all_transfers'] Examples:
- ['dex'] - only DEX transfers
- ['cex'] - only CEX transfers
- ['dex', 'cex'] - both DEX and CEX
- ['non_exchange_transfers'] - only non-exchange transfers
- ['all_transfers'] - all types (default)

Smart Money Filter:

onlySmartTradersAndFunds (bool): Only show smart money transfers (default: false) When true, filters to show only transfers involving profitable addresses

Numeric Range Filter:

transferValueUsd (object, optional): Filter by USD value of transfer Format: {"from": X, "to": Y} or {"from": X} or {"to": Y}
- Specify only from for minimum bound (no maximum)
- Specify only to for maximum bound (no minimum)
- Specify both for a bounded range Example: {"from": 1000} - only transfers worth at least $1,000 USD Example: {"to": 50000} - only transfers up to $50,000 USD Example: {"from": 1000, "to": 50000} - transfers between $1,000 and $50,000 USD Note: This filters by the USD value of the transfer at time of transaction

Notes: - Use fromAddress/toAddress for a specific wallet (see Direction rules) - Use transferOriginCategories to control which transfer origins are included - Smart Money filter shows only transfers involving profitable addresses (definition of Smart Money) - transferValueUsd filters by USD value at time of transaction

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

token_who_bought_soldFinding recent traders

Read-only

Inspect

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

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`rows`	No
`chain`	No
`date_to`	No
`message`	No	Notice or error text when the tool returns no data rows.
`date_from`	No
`pagination`	No
`buy_or_sell`	No
`token_address`	No

transaction_lookupLooking up transaction detailsC

Read-only

Inspect

Get comprehensive transaction details including token transfers.

ParametersJSON Schema

Name	Required	Description	Default
`chain`	No		all
`transaction_hash`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful detail that token transfers are included in the returned details, but it does not disclose any additional behavioral traits such as missing transaction handling or chain-scoping effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It earns its place but is slightly too sparse to fully compensate for missing usage and parameter context.

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?

An output schema exists, so return-value details are less necessary, but the description still lacks when-to-use guidance and parameter semantics. For a tool with dozens of siblings and an undocumented chain parameter, this is not complete enough for reliable selection and invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate, but it does not explain what transaction_hash or chain mean or how they affect results. 'transaction_hash' is somewhat self-explanatory, and 'chain' has a default of 'all', but the description gives no parameter-level guidance.

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 uses a clear verb ('Get') and names the resource ('transaction details') with a specific scope ('comprehensive ... including token transfers'). It is distinguishable from address- and token-focused siblings, but it does not explicitly mention lookup by transaction hash, which leaves slight ambiguity versus address_transactions.

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?

No guidance is given about when to use this tool instead of alternatives such as address_transactions, token_transfers, or prediction_market_lookup. There is no stated context, prerequisite, or exclusion, so an agent must infer when this is the right choice.

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

wallet_pnl_for_tokenCalculating token performance

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

wallet_pnl_summaryAnalyzing wallet performance

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

Tool Schema Changelog

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

17 tool updatesOct 10, 2026

Changedaddress_counterparties2 fields changed

changedInput schema / properties / request / properties / timeRange / properties / from / description

Previous value: -"Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD)."New value: +"Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight."

changedInput schema / properties / request / properties / timeRange / properties / to / description

Previous value: -"End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD)."New value: +"End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight."

Changedaddress_counterparties_batch2 fields changed

changedInput schema / properties / request / properties / timeRange / properties / from / description

Previous value: -"Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD)."New value: +"Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight."

changedInput schema / properties / request / properties / timeRange / properties / to / description

Previous value: -"End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD)."New value: +"End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight."

Changedaddress_dex_trades1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Complete request for an address' DEX trades (flattened).",
-    "properties": {
-      "address": {
-        "description": "The wallet address whose DEX trades to fetch",
-        "type": "string"
-      },
-      "chain": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Single chain to query (e.g. ethereum, base, arbitrum, solana). This endpoint queries ONE chain at a time and does NOT accept 'all' or 'evm'. For EVM wallets a concrete chain is REQUIRED (they trade across many chains); non-EVM addresses are auto-detected from the address. Use 'hyperliquid' for Hyperliquid perpetual trades (requires an EVM address)."
-      },
-      "dateRange": {
-        "description": "Date range for the trades (defaults to last 7 days). Use ALL_TIME for full history (start 2009-01-03).",
-        "properties": {
-          "from": {
-            "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          },
-          "to": {
-            "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          }
-        },
-        "required": [
-          "from",
-          "to"
-        ],
-        "type": "object"
-      },
-      "orderBy": {
-        "anyOf": [
-          {
-            "enum": [
-              "timestamp",
-              "value"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Sort field. Pass an exact value above or None for default ('timestamp')."
-      },
-      "order_by_direction": {
-        "default": "DESC",
-        "enum": [
-          "ASC",
-          "DESC",
-          "asc",
-          "desc"
-        ],
-        "type": "string"
-      },
-      "page": {
-        "default": 1,
-        "type": "integer"
-      },
-      "tokenAddressBought": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Token bought filter. On spot chains, use the token contract address. On Hyperliquid, use a perp symbol (e.g. BTC, HYPE, xyz:NVDA); returns Long-side trades."
-      },
-      "tokenAddressSold": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Token sold filter. On spot chains, use the token contract address. On Hyperliquid, use a perp symbol (e.g. BTC, HYPE, xyz:NVDA); returns Short-side trades."
-      },
-      "valueUsd": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter trades by USD value (open-ended min/max allowed)"
-      }
-    },
-    "required": [
-      "address"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Complete request for an address' DEX trades (flattened).",
+    "properties": {
+      "address": {
+        "description": "The wallet address whose DEX trades to fetch",
+        "type": "string"
+      },
+      "chain": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Single chain to query (e.g. ethereum, base, arbitrum, solana). This endpoint queries ONE chain at a time and does NOT accept 'all' or 'evm'. For EVM wallets a concrete chain is REQUIRED (they trade across many chains); non-EVM addresses are auto-detected from the address. Use 'hyperliquid' for Hyperliquid perpetual trades (requires an EVM address)."
+      },
+      "dateRange": {
+        "description": "Date range for the trades (defaults to last 7 days). Use ALL_TIME for full history (start 2009-01-03).",
+        "properties": {
+          "from": {
+            "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+            "type": "string"
+          },
+          "to": {
+            "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to"
+        ],
+        "type": "object"
+      },
+      "orderBy": {
+        "anyOf": [
+          {
+            "enum": [
+              "timestamp",
+              "value"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Sort field. Pass an exact value above or None for default ('timestamp')."
+      },
+      "order_by_direction": {
+        "default": "DESC",
+        "enum": [
+          "ASC",
+          "DESC",
+          "asc",
+          "desc"
+        ],
+        "type": "string"
+      },
+      "page": {
+        "default": 1,
+        "type": "integer"
+      },
+      "tokenAddressBought": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Token bought filter. On spot chains, use the token contract address. On Hyperliquid, use a perp symbol (e.g. BTC, HYPE, xyz:NVDA); returns Long-side trades."
+      },
+      "tokenAddressSold": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Token sold filter. On spot chains, use the token contract address. On Hyperliquid, use a perp symbol (e.g. BTC, HYPE, xyz:NVDA); returns Short-side trades."
+      },
+      "valueUsd": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter trades by USD value (open-ended min/max allowed)"
+      }
+    },
+    "required": [
+      "address"
+    ],
+    "type": "object"
+  }
+]

Changedaddress_transactions1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Complete request for address transactions (flattened).",
-    "properties": {
-      "address": {
-        "description": "Single address to analyze",
-        "type": "string"
-      },
-      "chain": {
-        "default": "evm",
-        "type": "string"
-      },
-      "dateRange": {
-        "description": "Date range for transactions (defaults to last 30 days)",
-        "properties": {
-          "from": {
-            "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          },
-          "to": {
-            "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          }
-        },
-        "required": [
-          "from",
-          "to"
-        ],
-        "type": "object"
-      },
-      "hideSpamToken": {
-        "default": true,
-        "description": "Remove suspicious tokens from transaction list",
-        "type": "boolean"
-      },
-      "page": {
-        "default": 1,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "address"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Complete request for address transactions (flattened).",
+    "properties": {
+      "address": {
+        "description": "Single address to analyze",
+        "type": "string"
+      },
+      "chain": {
+        "default": "evm",
+        "type": "string"
+      },
+      "dateRange": {
+        "description": "Date range for transactions (defaults to last 30 days)",
+        "properties": {
+          "from": {
+            "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+            "type": "string"
+          },
+          "to": {
+            "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to"
+        ],
+        "type": "object"
+      },
+      "hideSpamToken": {
+        "default": true,
+        "description": "Remove suspicious tokens from transaction list",
+        "type": "boolean"
+      },
+      "page": {
+        "default": 1,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "address"
+    ],
+    "type": "object"
+  }
+]

Changedhyperliquid_leaderboard1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Request for Hyperliquid perp leaderboard (flattened).",
-    "properties": {
-      "accountValue": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by account value (from/to)"
-      },
-      "date": {
-        "description": "Date range",
-        "properties": {
-          "from": {
-            "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          },
-          "to": {
-            "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          }
-        },
-        "required": [
-          "from",
-          "to"
-        ],
-        "type": "object"
-      },
-      "orderByDirection": {
-        "default": "DESC",
-        "description": "Sort direction: 'ASC' or 'DESC' (case-insensitive).",
-        "enum": [
-          "ASC",
-          "DESC",
-          "asc",
-          "desc"
-        ],
-        "type": "string"
-      },
-      "order_by": {
-        "anyOf": [
-          {
-            "enum": [
-              "total_pnl",
-              "realized_pnl_usd",
-              "unrealized_pnl_usd",
-              "roi",
-              "volume_usd",
-              "total_trades",
-              "account_value"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Sort field. Pass an exact value above or None for default ('total_pnl')."
-      },
-      "page": {
-        "default": 1,
-        "type": "integer"
-      },
-      "roi": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by ROI (from/to)"
-      },
-      "totalPnl": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by total PnL (from/to)"
-      }
-    },
-    "required": [
-      "date"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Request for Hyperliquid perp leaderboard (flattened).",
+    "properties": {
+      "accountValue": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by account value (from/to)"
+      },
+      "date": {
+        "description": "Date range",
+        "properties": {
+          "from": {
+            "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+            "type": "string"
+          },
+          "to": {
+            "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to"
+        ],
+        "type": "object"
+      },
+      "orderByDirection": {
+        "default": "DESC",
+        "description": "Sort direction: 'ASC' or 'DESC' (case-insensitive).",
+        "enum": [
+          "ASC",
+          "DESC",
+          "asc",
+          "desc"
+        ],
+        "type": "string"
+      },
+      "order_by": {
+        "anyOf": [
+          {
+            "enum": [
+              "total_pnl",
+              "realized_pnl_usd",
+              "unrealized_pnl_usd",
+              "roi",
+              "volume_usd",
+              "total_trades",
+              "account_value"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Sort field. Pass an exact value above or None for default ('total_pnl')."
+      },
+      "page": {
+        "default": 1,
+        "type": "integer"
+      },
+      "roi": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by ROI (from/to)"
+      },
+      "totalPnl": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by total PnL (from/to)"
+      }
+    },
+    "required": [
+      "date"
+    ],
+    "type": "object"
+  }
+]

Changedprediction_market_address_trades1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "description": "Request for address-level prediction market trades.",
-    "properties": {
-      "address": {
-        "description": "Polygon wallet address to analyze.",
-        "type": "string"
-      },
-      "dateRange": {
-        "anyOf": [
-          {
-            "description": "Date range via tokens or dates.\nTokens: NOW, ALL_TIME, XMIN_AGO, XD_AGO, XH_AGO; THIS_YEAR_START, THIS_QUARTER_START, THIS_MONTH_START, THIS_WEEK_START, TODAY_START; LAST_WEEK_START/END, LAST_MONTH_START/END, LAST_QUARTER_START/END, LAST_YEAR_START/END.\nALL_TIME is full history. It resolves to 2009-01-03. Use ALL_TIME instead of a very large day count.\nWeek starts Monday. Quarters are calendar. Dates: YYYY-MM-DD or ___-MM-DD (year omitted).\nPlease check detailed system instructions for more information.",
-            "properties": {
-              "from": {
-                "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-                "type": "string"
-              },
-              "to": {
-                "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-                "type": "string"
-              }
-            },
-            "required": [
-              "from",
-              "to"
-            ],
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Optional date range for address trades. Defaults to the last 30 days."
-      },
-      "page": {
-        "default": 1,
-        "description": "Page number for paginated results.",
-        "minimum": 1,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "address"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "description": "Request for address-level prediction market trades.",
+    "properties": {
+      "address": {
+        "description": "Polygon wallet address to analyze.",
+        "type": "string"
+      },
+      "dateRange": {
+        "anyOf": [
+          {
+            "description": "Date range via tokens or dates.\nTokens: NOW, ALL_TIME, XMIN_AGO, XD_AGO, XH_AGO, XY_AGO; THIS_YEAR_START, THIS_QUARTER_START, THIS_MONTH_START, THIS_WEEK_START, TODAY_START; LAST_WEEK_START/END, LAST_MONTH_START/END, LAST_QUARTER_START/END, LAST_YEAR_START/END.\nDurations are exact rolling UTC timestamps at both ends: 1D_AGO equals 24H_AGO; 1Y_AGO equals 365 days. Bare duration aliases and case variants are supported.\nExplicit dates and calendar tokens keep calendar boundaries and inclusive final dates. TODAY_START is current-day midnight. Date-only endpoints keep their calendar contracts.\nALL_TIME is full history. It resolves to 2009-01-03. Use ALL_TIME instead of a very large day count.\nWeek starts Monday. Quarters are calendar. Dates: YYYY-MM-DD or ___-MM-DD (year omitted).\nPlease check detailed system instructions for more information.",
+            "properties": {
+              "from": {
+                "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+                "type": "string"
+              },
+              "to": {
+                "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+                "type": "string"
+              }
+            },
+            "required": [
+              "from",
+              "to"
+            ],
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Optional date range for address trades. Defaults to the last 30 days."
+      },
+      "page": {
+        "default": 1,
+        "description": "Page number for paginated results.",
+        "minimum": 1,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "address"
+    ],
+    "type": "object"
+  }
+]

Changedprediction_market_ohlcv1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "description": "Request for historical prediction market OHLCV.",
-    "properties": {
-      "dateRange": {
-        "anyOf": [
-          {
-            "description": "Date range via tokens or dates.\nTokens: NOW, ALL_TIME, XMIN_AGO, XD_AGO, XH_AGO; THIS_YEAR_START, THIS_QUARTER_START, THIS_MONTH_START, THIS_WEEK_START, TODAY_START; LAST_WEEK_START/END, LAST_MONTH_START/END, LAST_QUARTER_START/END, LAST_YEAR_START/END.\nALL_TIME is full history. It resolves to 2009-01-03. Use ALL_TIME instead of a very large day count.\nWeek starts Monday. Quarters are calendar. Dates: YYYY-MM-DD or ___-MM-DD (year omitted).\nPlease check detailed system instructions for more information.",
-            "properties": {
-              "from": {
-                "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-                "type": "string"
-              },
-              "to": {
-                "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-                "type": "string"
-              }
-            },
-            "required": [
-              "from",
-              "to"
-            ],
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Optional date range for OHLCV. Defaults to the last 30 days when omitted."
-      },
-      "marketId": {
-        "description": "Numeric Polymarket market ID (e.g. '654412'). Obtain this from the prediction_market_screener tool.",
-        "maxLength": 100,
-        "minLength": 1,
-        "type": "string"
-      },
-      "orderBy": {
-        "anyOf": [
-          {
-            "enum": [
-              "period_start",
-              "volume_usd",
-              "trade_count"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Sort field. Pass an exact value above or None for default ('period_start')."
-      },
-      "orderByDirection": {
-        "default": "DESC",
-        "description": "Sort direction: 'ASC' or 'DESC' (case-insensitive).",
-        "enum": [
-          "ASC",
-          "DESC",
-          "asc",
-          "desc"
-        ],
-        "type": "string"
-      },
-      "page": {
-        "default": 1,
-        "description": "Page number for paginated results.",
-        "minimum": 1,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "marketId"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "description": "Request for historical prediction market OHLCV.",
+    "properties": {
+      "dateRange": {
+        "anyOf": [
+          {
+            "description": "Date range via tokens or dates.\nTokens: NOW, ALL_TIME, XMIN_AGO, XD_AGO, XH_AGO, XY_AGO; THIS_YEAR_START, THIS_QUARTER_START, THIS_MONTH_START, THIS_WEEK_START, TODAY_START; LAST_WEEK_START/END, LAST_MONTH_START/END, LAST_QUARTER_START/END, LAST_YEAR_START/END.\nDurations are exact rolling UTC timestamps at both ends: 1D_AGO equals 24H_AGO; 1Y_AGO equals 365 days. Bare duration aliases and case variants are supported.\nExplicit dates and calendar tokens keep calendar boundaries and inclusive final dates. TODAY_START is current-day midnight. Date-only endpoints keep their calendar contracts.\nALL_TIME is full history. It resolves to 2009-01-03. Use ALL_TIME instead of a very large day count.\nWeek starts Monday. Quarters are calendar. Dates: YYYY-MM-DD or ___-MM-DD (year omitted).\nPlease check detailed system instructions for more information.",
+            "properties": {
+              "from": {
+                "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+                "type": "string"
+              },
+              "to": {
+                "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+                "type": "string"
+              }
+            },
+            "required": [
+              "from",
+              "to"
+            ],
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Optional date range for OHLCV. Defaults to the last 30 days when omitted."
+      },
+      "marketId": {
+        "description": "Numeric Polymarket market ID (e.g. '654412'). Obtain this from the prediction_market_screener tool.",
+        "maxLength": 100,
+        "minLength": 1,
+        "type": "string"
+      },
+      "orderBy": {
+        "anyOf": [
+          {
+            "enum": [
+              "period_start",
+              "volume_usd",
+              "trade_count"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Sort field. Pass an exact value above or None for default ('period_start')."
+      },
+      "orderByDirection": {
+        "default": "DESC",
+        "description": "Sort direction: 'ASC' or 'DESC' (case-insensitive).",
+        "enum": [
+          "ASC",
+          "DESC",
+          "asc",
+          "desc"
+        ],
+        "type": "string"
+      },
+      "page": {
+        "default": 1,
+        "description": "Page number for paginated results.",
+        "minimum": 1,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "marketId"
+    ],
+    "type": "object"
+  }
+]

Changedprediction_market_trades1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "description": "Request for recent market trades.",
-    "properties": {
-      "dateRange": {
-        "anyOf": [
-          {
-            "description": "Date range via tokens or dates.\nTokens: NOW, ALL_TIME, XMIN_AGO, XD_AGO, XH_AGO; THIS_YEAR_START, THIS_QUARTER_START, THIS_MONTH_START, THIS_WEEK_START, TODAY_START; LAST_WEEK_START/END, LAST_MONTH_START/END, LAST_QUARTER_START/END, LAST_YEAR_START/END.\nALL_TIME is full history. It resolves to 2009-01-03. Use ALL_TIME instead of a very large day count.\nWeek starts Monday. Quarters are calendar. Dates: YYYY-MM-DD or ___-MM-DD (year omitted).\nPlease check detailed system instructions for more information.",
-            "properties": {
-              "from": {
-                "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-                "type": "string"
-              },
-              "to": {
-                "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-                "type": "string"
-              }
-            },
-            "required": [
-              "from",
-              "to"
-            ],
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Optional date range for market trades. Defaults to the last 7 days."
-      },
-      "marketId": {
-        "description": "Numeric Polymarket market ID (e.g. '654412'). Obtain this from the prediction_market_screener tool.",
-        "maxLength": 100,
-        "minLength": 1,
-        "type": "string"
-      },
-      "page": {
-        "default": 1,
-        "description": "Page number for paginated results.",
-        "minimum": 1,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "marketId"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "description": "Request for recent market trades.",
+    "properties": {
+      "dateRange": {
+        "anyOf": [
+          {
+            "description": "Date range via tokens or dates.\nTokens: NOW, ALL_TIME, XMIN_AGO, XD_AGO, XH_AGO, XY_AGO; THIS_YEAR_START, THIS_QUARTER_START, THIS_MONTH_START, THIS_WEEK_START, TODAY_START; LAST_WEEK_START/END, LAST_MONTH_START/END, LAST_QUARTER_START/END, LAST_YEAR_START/END.\nDurations are exact rolling UTC timestamps at both ends: 1D_AGO equals 24H_AGO; 1Y_AGO equals 365 days. Bare duration aliases and case variants are supported.\nExplicit dates and calendar tokens keep calendar boundaries and inclusive final dates. TODAY_START is current-day midnight. Date-only endpoints keep their calendar contracts.\nALL_TIME is full history. It resolves to 2009-01-03. Use ALL_TIME instead of a very large day count.\nWeek starts Monday. Quarters are calendar. Dates: YYYY-MM-DD or ___-MM-DD (year omitted).\nPlease check detailed system instructions for more information.",
+            "properties": {
+              "from": {
+                "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+                "type": "string"
+              },
+              "to": {
+                "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+                "type": "string"
+              }
+            },
+            "required": [
+              "from",
+              "to"
+            ],
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Optional date range for market trades. Defaults to the last 7 days."
+      },
+      "marketId": {
+        "description": "Numeric Polymarket market ID (e.g. '654412'). Obtain this from the prediction_market_screener tool.",
+        "maxLength": 100,
+        "minLength": 1,
+        "type": "string"
+      },
+      "page": {
+        "default": 1,
+        "description": "Page number for paginated results.",
+        "minimum": 1,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "marketId"
+    ],
+    "type": "object"
+  }
+]

Changedsmart_traders_and_funds_historical_token_balances1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Request for smart money historical token balances (v1 API) - flattened.",
-    "properties": {
-      "chains": {
-        "description": "Chains to include. Supported: base, bnb, ethereum, monad, robinhood, solana.",
-        "items": {
-          "enum": [
-            "base",
-            "bnb",
-            "ethereum",
-            "monad",
-            "robinhood",
-            "solana"
-          ],
-          "type": "string"
-        },
-        "type": "array"
-      },
-      "dateRange": {
-        "anyOf": [
-          {
-            "description": "Date range via tokens or dates.\nTokens: NOW, ALL_TIME, XMIN_AGO, XD_AGO, XH_AGO; THIS_YEAR_START, THIS_QUARTER_START, THIS_MONTH_START, THIS_WEEK_START, TODAY_START; LAST_WEEK_START/END, LAST_MONTH_START/END, LAST_QUARTER_START/END, LAST_YEAR_START/END.\nALL_TIME is full history. It resolves to 2009-01-03. Use ALL_TIME instead of a very large day count.\nWeek starts Monday. Quarters are calendar. Dates: YYYY-MM-DD or ___-MM-DD (year omitted).\nPlease check detailed system instructions for more information.",
-            "properties": {
-              "from": {
-                "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-                "type": "string"
-              },
-              "to": {
-                "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-                "type": "string"
-              }
-            },
-            "required": [
-              "from",
-              "to"
-            ],
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Date range for the history. Defaults to the last 30 days. Maximum lookback is 4 years."
-      },
-      "includeNativeTokens": {
-        "default": true,
-        "description": "Whether to include native tokens (ETH, SOL, etc.) in results",
-        "type": "boolean"
-      },
-      "includeSmartMoneyLabels": {
-        "anyOf": [
-          {
-            "items": {
-              "enum": [
-                "30D Smart Trader",
-                "90D Smart Trader",
-                "180D Smart Trader",
-                "All Time Smart Trader",
-                "Fund",
-                "Smart HL Perps Trader",
-                "Any Smart Money"
-              ],
-              "type": "string"
-            },
-            "type": "array"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Smart money category filters to include"
-      },
-      "includeStablecoin": {
-        "default": true,
-        "description": "Whether to include stablecoins in results",
-        "type": "boolean"
-      },
-      "orderBy": {
-        "anyOf": [
-          {
-            "enum": [
-              "date",
-              "value_usd",
-              "balance",
-              "balance_24h_percent_change",
-              "holders_count",
-              "share_of_holdings_percent",
-              "market_cap_usd"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Sort field. Pass an exact value above or None for default ('date')."
-      },
-      "orderByDirection": {
-        "default": "DESC",
-        "description": "Sort direction: 'ASC' or 'DESC' (case-insensitive).",
-        "enum": [
-          "ASC",
-          "DESC",
-          "asc",
-          "desc"
-        ],
-        "type": "string"
-      },
-      "page": {
-        "default": 1,
-        "type": "integer"
-      },
-      "tokenAddress": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Restrict the history to a single token address"
-      },
-      "tokenSymbol": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Restrict the history to a single token symbol"
-      }
-    },
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Request for smart money historical token balances (v1 API) - flattened.",
+    "properties": {
+      "chains": {
+        "description": "Chains to include. Supported: base, bnb, ethereum, monad, robinhood, solana.",
+        "items": {
+          "enum": [
+            "base",
+            "bnb",
+            "ethereum",
+            "monad",
+            "robinhood",
+            "solana"
+          ],
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "dateRange": {
+        "anyOf": [
+          {
+            "description": "Date range via tokens or dates.\nTokens: NOW, ALL_TIME, XMIN_AGO, XD_AGO, XH_AGO, XY_AGO; THIS_YEAR_START, THIS_QUARTER_START, THIS_MONTH_START, THIS_WEEK_START, TODAY_START; LAST_WEEK_START/END, LAST_MONTH_START/END, LAST_QUARTER_START/END, LAST_YEAR_START/END.\nDurations are exact rolling UTC timestamps at both ends: 1D_AGO equals 24H_AGO; 1Y_AGO equals 365 days. Bare duration aliases and case variants are supported.\nExplicit dates and calendar tokens keep calendar boundaries and inclusive final dates. TODAY_START is current-day midnight. Date-only endpoints keep their calendar contracts.\nALL_TIME is full history. It resolves to 2009-01-03. Use ALL_TIME instead of a very large day count.\nWeek starts Monday. Quarters are calendar. Dates: YYYY-MM-DD or ___-MM-DD (year omitted).\nPlease check detailed system instructions for more information.",
+            "properties": {
+              "from": {
+                "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+                "type": "string"
+              },
+              "to": {
+                "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+                "type": "string"
+              }
+            },
+            "required": [
+              "from",
+              "to"
+            ],
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Date range for the history. Defaults to the last 30 days. Maximum lookback is 4 years."
+      },
+      "includeNativeTokens": {
+        "default": true,
+        "description": "Whether to include native tokens (ETH, SOL, etc.) in results",
+        "type": "boolean"
+      },
+      "includeSmartMoneyLabels": {
+        "anyOf": [
+          {
+            "items": {
+              "enum": [
+                "30D Smart Trader",
+                "90D Smart Trader",
+                "180D Smart Trader",
+                "All Time Smart Trader",
+                "Fund",
+                "Smart HL Perps Trader",
+                "Any Smart Money"
+              ],
+              "type": "string"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Smart money category filters to include"
+      },
+      "includeStablecoin": {
+        "default": true,
+        "description": "Whether to include stablecoins in results",
+        "type": "boolean"
+      },
+      "orderBy": {
+        "anyOf": [
+          {
+            "enum": [
+              "date",
+              "value_usd",
+              "balance",
+              "balance_24h_percent_change",
+              "holders_count",
+              "share_of_holdings_percent",
+              "market_cap_usd"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Sort field. Pass an exact value above or None for default ('date')."
+      },
+      "orderByDirection": {
+        "default": "DESC",
+        "description": "Sort direction: 'ASC' or 'DESC' (case-insensitive).",
+        "enum": [
+          "ASC",
+          "DESC",
+          "asc",
+          "desc"
+        ],
+        "type": "string"
+      },
+      "page": {
+        "default": 1,
+        "type": "integer"
+      },
+      "tokenAddress": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Restrict the history to a single token address"
+      },
+      "tokenSymbol": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Restrict the history to a single token symbol"
+      }
+    },
+    "type": "object"
+  }
+]

Changedtoken_dex_trades1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Complete request for token DEX trades (flattened).",
-    "properties": {
-      "action": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by action: 'buy'/'sell' (onchain), 'Add'/'Reduce'/'Open'/'Close' (perps, can combine with side for precise filtering)."
-      },
-      "chain": {
-        "default": "ethereum",
-        "description": "Blockchain network. Supported: arbitrum, arc, avalanche, base, bnb, ethereum, hyperevm, injective, iotaevm, linea, mantle, mantra, monad, near, optimism, plasma, polygon, robinhood, ronin, scroll, sei, solana, sonic, sui, ton, tron, unichain, zksync",
-        "type": "string"
-      },
-      "dateRange": {
-        "description": "Date range for trade analysis",
-        "properties": {
-          "from": {
-            "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          },
-          "to": {
-            "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          }
-        },
-        "required": [
-          "from",
-          "to"
-        ],
-        "type": "object"
-      },
-      "includeSmartMoneyLabels": {
-        "anyOf": [
-          {
-            "items": {
-              "enum": [
-                "30D Smart Trader",
-                "90D Smart Trader",
-                "180D Smart Trader",
-                "All Time Smart Trader",
-                "Fund",
-                "Smart HL Perps Trader",
-                "Any Smart Money"
-              ],
-              "type": "string"
-            },
-            "type": "array"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "List of smart money labels to filter by (default: empty list). Use 'Any Smart Money' to include all smart money types."
-      },
-      "mode": {
-        "default": "onchain_tokens",
-        "description": "Analysis mode: 'onchain_tokens' for on-chain tokens by contract address, 'perps' for Hyperliquid perpetual futures by symbol. If mode is omitted and token_address is a symbol (not a contract address), mode defaults to 'perps'.",
-        "enum": [
-          "onchain_tokens",
-          "perps"
-        ],
-        "type": "string"
-      },
-      "orderBy": {
-        "anyOf": [
-          {
-            "enum": [
-              "timestamp",
-              "amount"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Sort field. Pass an exact value above or None for default ('timestamp')."
-      },
-      "order_by_direction": {
-        "default": "DESC",
-        "enum": [
-          "ASC",
-          "DESC",
-          "asc",
-          "desc"
-        ],
-        "type": "string"
-      },
-      "page": {
-        "default": 1,
-        "type": "integer"
-      },
-      "side": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by position side: 'Long'/'Short'."
-      },
-      "tokenAddress": {
-        "type": "string"
-      },
-      "traderAddress": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "items": {
-              "type": "string"
-            },
-            "type": "array"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by trader address"
-      },
-      "valueUsd": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by trade value in USD"
-      }
-    },
-    "required": [
-      "tokenAddress"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Complete request for token DEX trades (flattened).",
+    "properties": {
+      "action": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by action: 'buy'/'sell' (onchain), 'Add'/'Reduce'/'Open'/'Close' (perps, can combine with side for precise filtering)."
+      },
+      "chain": {
+        "default": "ethereum",
+        "description": "Blockchain network. Supported: arbitrum, arc, avalanche, base, bnb, ethereum, hyperevm, injective, iotaevm, linea, mantle, mantra, monad, near, optimism, plasma, polygon, robinhood, ronin, scroll, sei, solana, sonic, sui, ton, tron, unichain, zksync",
+        "type": "string"
+      },
+      "dateRange": {
+        "description": "Date range for trade analysis",
+        "properties": {
+          "from": {
+            "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+            "type": "string"
+          },
+          "to": {
+            "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to"
+        ],
+        "type": "object"
+      },
+      "includeSmartMoneyLabels": {
+        "anyOf": [
+          {
+            "items": {
+              "enum": [
+                "30D Smart Trader",
+                "90D Smart Trader",
+                "180D Smart Trader",
+                "All Time Smart Trader",
+                "Fund",
+                "Smart HL Perps Trader",
+                "Any Smart Money"
+              ],
+              "type": "string"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "List of smart money labels to filter by (default: empty list). Use 'Any Smart Money' to include all smart money types."
+      },
+      "mode": {
+        "default": "onchain_tokens",
+        "description": "Analysis mode: 'onchain_tokens' for on-chain tokens by contract address, 'perps' for Hyperliquid perpetual futures by symbol. If mode is omitted and token_address is a symbol (not a contract address), mode defaults to 'perps'.",
+        "enum": [
+          "onchain_tokens",
+          "perps"
+        ],
+        "type": "string"
+      },
+      "orderBy": {
+        "anyOf": [
+          {
+            "enum": [
+              "timestamp",
+              "amount"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Sort field. Pass an exact value above or None for default ('timestamp')."
+      },
+      "order_by_direction": {
+        "default": "DESC",
+        "enum": [
+          "ASC",
+          "DESC",
+          "asc",
+          "desc"
+        ],
+        "type": "string"
+      },
+      "page": {
+        "default": 1,
+        "type": "integer"
+      },
+      "side": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by position side: 'Long'/'Short'."
+      },
+      "tokenAddress": {
+        "type": "string"
+      },
+      "traderAddress": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by trader address"
+      },
+      "valueUsd": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by trade value in USD"
+      }
+    },
+    "required": [
+      "tokenAddress"
+    ],
+    "type": "object"
+  }
+]

Changedtoken_flows1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Complete request for token flows (flattened).",
-    "properties": {
-      "chain": {
-        "default": "ethereum",
-        "description": "Blockchain network. Supported: arbitrum, arc, avalanche, base, bnb, ethereum, hyperevm, injective, iotaevm, linea, mantle, mantra, monad, near, optimism, plasma, polygon, robinhood, ronin, scroll, sei, solana, sonic, sui, ton, tron, unichain, zksync",
-        "type": "string"
-      },
-      "dateRange": {
-        "description": "Date range for flow analysis",
-        "properties": {
-          "from": {
-            "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          },
-          "to": {
-            "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          }
-        },
-        "required": [
-          "from",
-          "to"
-        ],
-        "type": "object"
-      },
-      "holder_segment": {
-        "default": "top_100_holders",
-        "description": "Label types for holder analysis and filtering.",
-        "enum": [
-          "whale",
-          "public_figure",
-          "smart_money",
-          "top_100_holders",
-          "exchange"
-        ],
-        "type": "string"
-      },
-      "mode": {
-        "default": "onchain_tokens",
-        "description": "Analysis mode: 'onchain_tokens' for on-chain tokens by contract address, 'perps' for Hyperliquid perpetual futures by symbol. If mode is omitted and token_address is a symbol (not a contract address), mode defaults to 'perps'.",
-        "enum": [
-          "onchain_tokens",
-          "perps"
-        ],
-        "type": "string"
-      },
-      "page": {
-        "default": 1,
-        "description": "Page number, starting at 1",
-        "minimum": 1,
-        "type": "integer"
-      },
-      "perPage": {
-        "default": 10,
-        "description": "Number of records per page, from 1 to 1000",
-        "maximum": 1000,
-        "minimum": 1,
-        "type": "integer"
-      },
-      "tokenAddress": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "tokenAddress"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Complete request for token flows (flattened).",
+    "properties": {
+      "chain": {
+        "default": "ethereum",
+        "description": "Blockchain network. Supported: arbitrum, arc, avalanche, base, bnb, ethereum, hyperevm, injective, iotaevm, linea, mantle, mantra, monad, near, optimism, plasma, polygon, robinhood, ronin, scroll, sei, solana, sonic, sui, ton, tron, unichain, zksync",
+        "type": "string"
+      },
+      "dateRange": {
+        "description": "Date range for flow analysis",
+        "properties": {
+          "from": {
+            "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+            "type": "string"
+          },
+          "to": {
+            "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to"
+        ],
+        "type": "object"
+      },
+      "holder_segment": {
+        "default": "top_100_holders",
+        "description": "Label types for holder analysis and filtering.",
+        "enum": [
+          "whale",
+          "public_figure",
+          "smart_money",
+          "top_100_holders",
+          "exchange"
+        ],
+        "type": "string"
+      },
+      "mode": {
+        "default": "onchain_tokens",
+        "description": "Analysis mode: 'onchain_tokens' for on-chain tokens by contract address, 'perps' for Hyperliquid perpetual futures by symbol. If mode is omitted and token_address is a symbol (not a contract address), mode defaults to 'perps'.",
+        "enum": [
+          "onchain_tokens",
+          "perps"
+        ],
+        "type": "string"
+      },
+      "page": {
+        "default": 1,
+        "description": "Page number, starting at 1",
+        "minimum": 1,
+        "type": "integer"
+      },
+      "perPage": {
+        "default": 10,
+        "description": "Number of records per page, from 1 to 1000",
+        "maximum": 1000,
+        "minimum": 1,
+        "type": "integer"
+      },
+      "tokenAddress": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "tokenAddress"
+    ],
+    "type": "object"
+  }
+]

Changedtoken_ohlcv1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Unified request model for TGM OHLCV endpoint (flattened).\n\nResolution is automatically calculated based on the date range to keep\nresponses at approximately 100 rows, preventing context overflow.",
-    "properties": {
-      "chain": {
-        "type": "string"
-      },
-      "date": {
-        "description": "Date range for OHLCV data with 'from' and 'to' fields",
-        "properties": {
-          "from": {
-            "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          },
-          "to": {
-            "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          }
-        },
-        "required": [
-          "from",
-          "to"
-        ],
-        "type": "object"
-      },
-      "includeMarketCap": {
-        "default": false,
-        "description": "Include market cap fields (openMcap, closeMcap, highMcap, lowMcap). Default: false for cleaner output",
-        "type": "boolean"
-      },
-      "tokenAddress": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "chain",
-      "tokenAddress",
-      "date"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Unified request model for TGM OHLCV endpoint (flattened).\n\nResolution is automatically calculated based on the date range to keep\nresponses at approximately 100 rows, preventing context overflow.",
+    "properties": {
+      "chain": {
+        "type": "string"
+      },
+      "date": {
+        "description": "Date range for OHLCV data with 'from' and 'to' fields",
+        "properties": {
+          "from": {
+            "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+            "type": "string"
+          },
+          "to": {
+            "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to"
+        ],
+        "type": "object"
+      },
+      "includeMarketCap": {
+        "default": false,
+        "description": "Include market cap fields (openMcap, closeMcap, highMcap, lowMcap). Default: false for cleaner output",
+        "type": "boolean"
+      },
+      "tokenAddress": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "chain",
+      "tokenAddress",
+      "date"
+    ],
+    "type": "object"
+  }
+]

Changedtoken_pnl_leaderboard1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Complete request for token PnL leaderboard (flattened).",
-    "properties": {
-      "boughtAmount": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by total amount of tokens bought"
-      },
-      "boughtUsd": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by total USD value of tokens bought"
-      },
-      "chain": {
-        "default": "ethereum",
-        "description": "Blockchain network. Supported: arbitrum, arc, avalanche, base, bnb, ethereum, hyperevm, injective, iotaevm, linea, mantle, mantra, monad, near, optimism, plasma, polygon, robinhood, ronin, scroll, sei, solana, sonic, sui, ton, tron, unichain, zksync",
-        "type": "string"
-      },
-      "dateRange": {
-        "description": "Date range for PnL analysis",
-        "properties": {
-          "from": {
-            "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          },
-          "to": {
-            "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          }
-        },
-        "required": [
-          "from",
-          "to"
-        ],
-        "type": "object"
-      },
-      "fullName": {
-        "anyOf": [
-          {
-            "items": {
-              "type": "string"
-            },
-            "type": "array"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by specific trader labels/names"
-      },
-      "holdingAmount": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by current token holdings amount"
-      },
-      "holdingUsd": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by current USD value of holdings"
-      },
-      "maxBalanceHeld": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by maximum token balance ever held"
-      },
-      "maxBalanceHeldUsd": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by maximum USD value ever held"
-      },
-      "mode": {
-        "default": "onchain_tokens",
-        "description": "Analysis mode: 'onchain_tokens' for on-chain tokens by contract address, 'perps' for Hyperliquid perpetual futures by symbol. If mode is omitted and token_address is a symbol (not a contract address), mode defaults to 'perps'.",
-        "enum": [
-          "onchain_tokens",
-          "perps"
-        ],
-        "type": "string"
-      },
-      "netflowAmountUsd": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by net flow (negative = net seller)"
-      },
-      "nofBuys": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by number of buy transactions"
-      },
-      "nofSells": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by number of sell transactions"
-      },
-      "nofTrades": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by number of trades"
-      },
-      "orderBy": {
-        "anyOf": [
-          {
-            "enum": [
-              "pnl_usd_realised",
-              "pnl_usd_unrealised",
-              "pnl_usd_total",
-              "roi_percent_total",
-              "roi_percent_realised",
-              "roi_percent_unrealised",
-              "holding_amount",
-              "max_balance_held",
-              "still_holding_balance_ratio",
-              "netflow_amount",
-              "nof_trades"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Sort field. Pass an exact value above or None for default ('pnl_usd_realised'). Native-balance fields are preferred over USD twins."
-      },
-      "order_by_direction": {
-        "default": "DESC",
-        "enum": [
-          "ASC",
-          "DESC",
-          "asc",
-          "desc"
-        ],
-        "type": "string"
-      },
-      "page": {
-        "default": 1,
-        "type": "integer"
-      },
-      "pnlUsdRealised": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by realized PnL (completed trades)"
-      },
-      "pnlUsdTotal": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by total PnL (combined realized and unrealized)"
-      },
-      "pnlUsdUnrealised": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by unrealized PnL (current positions)"
-      },
-      "roiPercentRealised": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by realized ROI percentage"
-      },
-      "roiPercentTotal": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by total ROI percentage"
-      },
-      "roiPercentUnrealised": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by unrealized ROI percentage"
-      },
-      "soldAmount": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by total amount of tokens sold"
-      },
-      "soldUsd": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by total USD value of tokens sold"
-      },
-      "stillHoldingBalanceRatio": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by percentage of peak holdings still held"
-      },
-      "tokenAddress": {
-        "type": "string"
-      },
-      "traderAddress": {
-        "anyOf": [
-          {
-            "items": {
-              "type": "string"
-            },
-            "type": "array"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Filter by specific trader addresses"
-      }
-    },
-    "required": [
-      "tokenAddress"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Complete request for token PnL leaderboard (flattened).",
+    "properties": {
+      "boughtAmount": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by total amount of tokens bought"
+      },
+      "boughtUsd": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by total USD value of tokens bought"
+      },
+      "chain": {
+        "default": "ethereum",
+        "description": "Blockchain network. Supported: arbitrum, arc, avalanche, base, bnb, ethereum, hyperevm, injective, iotaevm, linea, mantle, mantra, monad, near, optimism, plasma, polygon, robinhood, ronin, scroll, sei, solana, sonic, sui, ton, tron, unichain, zksync",
+        "type": "string"
+      },
+      "dateRange": {
+        "description": "Date range for PnL analysis",
+        "properties": {
+          "from": {
+            "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+            "type": "string"
+          },
+          "to": {
+            "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to"
+        ],
+        "type": "object"
+      },
+      "fullName": {
+        "anyOf": [
+          {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by specific trader labels/names"
+      },
+      "holdingAmount": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by current token holdings amount"
+      },
+      "holdingUsd": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by current USD value of holdings"
+      },
+      "maxBalanceHeld": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by maximum token balance ever held"
+      },
+      "maxBalanceHeldUsd": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by maximum USD value ever held"
+      },
+      "mode": {
+        "default": "onchain_tokens",
+        "description": "Analysis mode: 'onchain_tokens' for on-chain tokens by contract address, 'perps' for Hyperliquid perpetual futures by symbol. If mode is omitted and token_address is a symbol (not a contract address), mode defaults to 'perps'.",
+        "enum": [
+          "onchain_tokens",
+          "perps"
+        ],
+        "type": "string"
+      },
+      "netflowAmountUsd": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by net flow (negative = net seller)"
+      },
+      "nofBuys": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by number of buy transactions"
+      },
+      "nofSells": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by number of sell transactions"
+      },
+      "nofTrades": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by number of trades"
+      },
+      "orderBy": {
+        "anyOf": [
+          {
+            "enum": [
+              "pnl_usd_realised",
+              "pnl_usd_unrealised",
+              "pnl_usd_total",
+              "roi_percent_total",
+              "roi_percent_realised",
+              "roi_percent_unrealised",
+              "holding_amount",
+              "max_balance_held",
+              "still_holding_balance_ratio",
+              "netflow_amount",
+              "nof_trades"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Sort field. Pass an exact value above or None for default ('pnl_usd_realised'). Native-balance fields are preferred over USD twins."
+      },
+      "order_by_direction": {
+        "default": "DESC",
+        "enum": [
+          "ASC",
+          "DESC",
+          "asc",
+          "desc"
+        ],
+        "type": "string"
+      },
+      "page": {
+        "default": 1,
+        "type": "integer"
+      },
+      "pnlUsdRealised": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by realized PnL (completed trades)"
+      },
+      "pnlUsdTotal": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by total PnL (combined realized and unrealized)"
+      },
+      "pnlUsdUnrealised": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by unrealized PnL (current positions)"
+      },
+      "roiPercentRealised": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by realized ROI percentage"
+      },
+      "roiPercentTotal": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by total ROI percentage"
+      },
+      "roiPercentUnrealised": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by unrealized ROI percentage"
+      },
+      "soldAmount": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by total amount of tokens sold"
+      },
+      "soldUsd": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by total USD value of tokens sold"
+      },
+      "stillHoldingBalanceRatio": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by percentage of peak holdings still held"
+      },
+      "tokenAddress": {
+        "type": "string"
+      },
+      "traderAddress": {
+        "anyOf": [
+          {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filter by specific trader addresses"
+      }
+    },
+    "required": [
+      "tokenAddress"
+    ],
+    "type": "object"
+  }
+]

Changedtoken_transfers1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Complete request for token transfers (flattened).",
-    "properties": {
-      "chain": {
-        "type": "string"
-      },
-      "dateRange": {
-        "description": "Date range for transfer analysis. Max window: 365 days — longer ranges are clamped to the most recent year and the effective range is reported in the response. Prefer relative tokens (1H_AGO, 24H_AGO, 7D_AGO, 30D_AGO, 1Y_AGO).",
-        "properties": {
-          "from": {
-            "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          },
-          "to": {
-            "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          }
-        },
-        "required": [
-          "from",
-          "to"
-        ],
-        "type": "object"
-      },
-      "fromAddress": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "items": {
-              "type": "string"
-            },
-            "type": "array"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Wallet(s) that SENT the tokens. Use alone only when the user asks what a wallet sent. 'Transfers of X' names no direction: then make a second call with toAddress. Do not put the same address in toAddress: the filters combine with AND."
-      },
-      "onlySmartTradersAndFunds": {
-        "default": false,
-        "description": "Whether to include only smart money transfers.",
-        "type": "boolean"
-      },
-      "orderBy": {
-        "anyOf": [
-          {
-            "enum": [
-              "timestamp",
-              "amount"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Sort field. Pass an exact value above or None for default ('amount', largest first). Use 'timestamp' only when the user asks for the latest transfers or a time order."
-      },
-      "order_by_direction": {
-        "default": "DESC",
-        "enum": [
-          "ASC",
-          "DESC",
-          "asc",
-          "desc"
-        ],
-        "type": "string"
-      },
-      "page": {
-        "default": 1,
-        "type": "integer"
-      },
-      "toAddress": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "items": {
-              "type": "string"
-            },
-            "type": "array"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Wallet(s) that RECEIVED the tokens. Use alone only when the user asks what a wallet received. 'Transfers of X' names no direction: then make a second call with fromAddress. Do not put the same address in fromAddress: the filters combine with AND."
-      },
-      "tokenAddress": {
-        "type": "string"
-      },
-      "transferOriginCategories": {
-        "default": [
-          "all_transfers"
-        ],
-        "description": "List of transfer types to include. Possible values: ['dex', 'cex', 'non_exchange_transfers', 'all_transfers']",
-        "items": {
-          "type": "string"
-        },
-        "type": "array"
-      },
-      "transferValueUsd": {
-        "anyOf": [
-          {
-            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
-            "properties": {
-              "from": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Minimum value (inclusive), optional"
-              },
-              "to": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "default": null,
-                "description": "Maximum value (inclusive), optional"
-              }
-            },
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Range of USD values for transfer analysis"
-      }
-    },
-    "required": [
-      "chain",
-      "tokenAddress"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Complete request for token transfers (flattened).",
+    "properties": {
+      "chain": {
+        "type": "string"
+      },
+      "dateRange": {
+        "description": "Date range for transfer analysis. Max window: 365 days — longer ranges are clamped to the most recent year and the effective range is reported in the response. Prefer relative tokens (1H_AGO, 24H_AGO, 7D_AGO, 30D_AGO, 1Y_AGO).",
+        "properties": {
+          "from": {
+            "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+            "type": "string"
+          },
+          "to": {
+            "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to"
+        ],
+        "type": "object"
+      },
+      "fromAddress": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Wallet(s) that SENT the tokens. Use alone only when the user asks what a wallet sent. 'Transfers of X' names no direction: then make a second call with toAddress. Do not put the same address in toAddress: the filters combine with AND."
+      },
+      "onlySmartTradersAndFunds": {
+        "default": false,
+        "description": "Whether to include only smart money transfers.",
+        "type": "boolean"
+      },
+      "orderBy": {
+        "anyOf": [
+          {
+            "enum": [
+              "timestamp",
+              "amount"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Sort field. Pass an exact value above or None for default ('amount', largest first). Use 'timestamp' only when the user asks for the latest transfers or a time order."
+      },
+      "order_by_direction": {
+        "default": "DESC",
+        "enum": [
+          "ASC",
+          "DESC",
+          "asc",
+          "desc"
+        ],
+        "type": "string"
+      },
+      "page": {
+        "default": 1,
+        "type": "integer"
+      },
+      "toAddress": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Wallet(s) that RECEIVED the tokens. Use alone only when the user asks what a wallet received. 'Transfers of X' names no direction: then make a second call with fromAddress. Do not put the same address in fromAddress: the filters combine with AND."
+      },
+      "tokenAddress": {
+        "type": "string"
+      },
+      "transferOriginCategories": {
+        "default": [
+          "all_transfers"
+        ],
+        "description": "List of transfer types to include. Possible values: ['dex', 'cex', 'non_exchange_transfers', 'all_transfers']",
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "transferValueUsd": {
+        "anyOf": [
+          {
+            "description": "Numeric range where from_value and to_value are optional,\nallowing for open-ended ranges (e.g., only minimum or only maximum).",
+            "properties": {
+              "from": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Minimum value (inclusive), optional"
+              },
+              "to": {
+                "anyOf": [
+                  {
+                    "type": "number"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "default": null,
+                "description": "Maximum value (inclusive), optional"
+              }
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Range of USD values for transfer analysis"
+      }
+    },
+    "required": [
+      "chain",
+      "tokenAddress"
+    ],
+    "type": "object"
+  }
+]

Changedtoken_who_bought_sold1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Complete request for token who bought/sold (flattened).",
-    "properties": {
-      "buy_or_sell": {
-        "description": "Transaction type for buyers or sellers analysis",
-        "enum": [
-          "BUY",
-          "SELL"
-        ],
-        "type": "string"
-      },
-      "chain": {
-        "type": "string"
-      },
-      "include_labels": {
-        "description": "Filter based on a particular set of segments based on label, default is empty which includes all segments",
-        "items": {
-          "description": "Wallet labels for holder analysis and filtering.",
-          "enum": [
-            "Whale",
-            "Public Figure",
-            "Exchange",
-            "Fund",
-            "30D Smart Trader",
-            "90D Smart Trader",
-            "180D Smart Trader",
-            "All Time Smart Trader"
-          ],
-          "type": "string"
-        },
-        "type": "array"
-      },
-      "min_trade_volume_usd": {
-        "default": 10,
-        "type": "number"
-      },
-      "orderBy": {
-        "anyOf": [
-          {
-            "enum": [
-              "token_trade_volume",
-              "bought_token_volume",
-              "sold_token_volume"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Sort field. Pass an exact value above or None for default ('token_trade_volume'). USD volume fields are disabled; native token volume is preferred."
-      },
-      "order_by_direction": {
-        "default": "DESC",
-        "enum": [
-          "ASC",
-          "DESC",
-          "asc",
-          "desc"
-        ],
-        "type": "string"
-      },
-      "page": {
-        "default": 1,
-        "type": "integer"
-      },
-      "time_range": {
-        "description": "Date range for analysis",
-        "properties": {
-          "from": {
-            "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          },
-          "to": {
-            "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          }
-        },
-        "required": [
-          "from",
-          "to"
-        ],
-        "type": "object"
-      },
-      "tokenAddress": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "chain",
-      "tokenAddress",
-      "buy_or_sell"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Complete request for token who bought/sold (flattened).",
+    "properties": {
+      "buy_or_sell": {
+        "description": "Transaction type for buyers or sellers analysis",
+        "enum": [
+          "BUY",
+          "SELL"
+        ],
+        "type": "string"
+      },
+      "chain": {
+        "type": "string"
+      },
+      "include_labels": {
+        "description": "Filter based on a particular set of segments based on label, default is empty which includes all segments",
+        "items": {
+          "description": "Wallet labels for holder analysis and filtering.",
+          "enum": [
+            "Whale",
+            "Public Figure",
+            "Exchange",
+            "Fund",
+            "30D Smart Trader",
+            "90D Smart Trader",
+            "180D Smart Trader",
+            "All Time Smart Trader"
+          ],
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "min_trade_volume_usd": {
+        "default": 10,
+        "type": "number"
+      },
+      "orderBy": {
+        "anyOf": [
+          {
+            "enum": [
+              "token_trade_volume",
+              "bought_token_volume",
+              "sold_token_volume"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Sort field. Pass an exact value above or None for default ('token_trade_volume'). USD volume fields are disabled; native token volume is preferred."
+      },
+      "order_by_direction": {
+        "default": "DESC",
+        "enum": [
+          "ASC",
+          "DESC",
+          "asc",
+          "desc"
+        ],
+        "type": "string"
+      },
+      "page": {
+        "default": 1,
+        "type": "integer"
+      },
+      "time_range": {
+        "description": "Date range for analysis",
+        "properties": {
+          "from": {
+            "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+            "type": "string"
+          },
+          "to": {
+            "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to"
+        ],
+        "type": "object"
+      },
+      "tokenAddress": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "chain",
+      "tokenAddress",
+      "buy_or_sell"
+    ],
+    "type": "object"
+  }
+]

Changedwallet_pnl_for_token1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Complete request for wallet PnL for token (flattened).",
-    "properties": {
-      "chain": {
-        "default": "evm",
-        "description": "Blockchain to query. Use 'hyperliquid' for a Hyperliquid perp coin — then tokenAddress is the perp SYMBOL (e.g. 'BTC', 'HYPE', 'xyz:CL'), not a contract address, and the wallet must be an EVM address. Every other chain expects a token contract address.",
-        "type": "string"
-      },
-      "dateRange": {
-        "description": "Date range for PnL analysis",
-        "properties": {
-          "from": {
-            "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          },
-          "to": {
-            "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          }
-        },
-        "required": [
-          "from",
-          "to"
-        ],
-        "type": "object"
-      },
-      "showRealized": {
-        "description": "Set to true for realized PnL (completed/closed trades), false for current position analysis (unrealized PnL + active holdings). Ignored on chain='hyperliquid', which always reports both.",
-        "type": "boolean"
-      },
-      "tokenAddress": {
-        "description": "Token address to generate PnL stats for",
-        "type": "string"
-      },
-      "walletAddress": {
-        "description": "The wallet address to analyze",
-        "type": "string"
-      }
-    },
-    "required": [
-      "walletAddress",
-      "tokenAddress",
-      "dateRange",
-      "showRealized"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Complete request for wallet PnL for token (flattened).",
+    "properties": {
+      "chain": {
+        "default": "evm",
+        "description": "Blockchain to query. Use 'hyperliquid' for a Hyperliquid perp coin — then tokenAddress is the perp SYMBOL (e.g. 'BTC', 'HYPE', 'xyz:CL'), not a contract address, and the wallet must be an EVM address. Every other chain expects a token contract address.",
+        "type": "string"
+      },
+      "dateRange": {
+        "description": "Date range for PnL analysis",
+        "properties": {
+          "from": {
+            "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+            "type": "string"
+          },
+          "to": {
+            "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to"
+        ],
+        "type": "object"
+      },
+      "showRealized": {
+        "description": "Set to true for realized PnL (completed/closed trades), false for current position analysis (unrealized PnL + active holdings). Ignored on chain='hyperliquid', which always reports both.",
+        "type": "boolean"
+      },
+      "tokenAddress": {
+        "description": "Token address to generate PnL stats for",
+        "type": "string"
+      },
+      "walletAddress": {
+        "description": "The wallet address to analyze",
+        "type": "string"
+      }
+    },
+    "required": [
+      "walletAddress",
+      "tokenAddress",
+      "dateRange",
+      "showRealized"
+    ],
+    "type": "object"
+  }
+]

Changedwallet_pnl_summary1 field changed

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Complete request for wallet PnL summary (flattened).",
-    "properties": {
-      "chain": {
-        "default": "evm",
-        "description": "Blockchain to query. Use 'hyperliquid' for Hyperliquid perp traders only (realized PnL from fills + current unrealized snapshot). 'evm'/'all' on an EVM address reports spot/on-chain and Hyperliquid perp results in separate sections. Or pass a specific chain name for that chain's spot PnL alone.",
-        "type": "string"
-      },
-      "dateRange": {
-        "description": "Date range for PnL summary analysis",
-        "properties": {
-          "from": {
-            "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          },
-          "to": {
-            "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-            "type": "string"
-          }
-        },
-        "required": [
-          "from",
-          "to"
-        ],
-        "type": "object"
-      },
-      "walletAddress": {
-        "description": "The wallet address to analyze",
-        "type": "string"
-      }
-    },
-    "required": [
-      "walletAddress",
-      "dateRange"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Complete request for wallet PnL summary (flattened).",
+    "properties": {
+      "chain": {
+        "default": "evm",
+        "description": "Blockchain to query. Use 'hyperliquid' for Hyperliquid perp traders only (realized PnL from fills + current unrealized snapshot). 'evm'/'all' on an EVM address reports spot/on-chain and Hyperliquid perp results in separate sections. Or pass a specific chain name for that chain's spot PnL alone.",
+        "type": "string"
+      },
+      "dateRange": {
+        "description": "Date range for PnL summary analysis",
+        "properties": {
+          "from": {
+            "description": "Start token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps; dates and calendar tokens start at midnight.",
+            "type": "string"
+          },
+          "to": {
+            "description": "End token or date (YYYY-MM-DD or ___-MM-DD). Durations use exact rolling UTC timestamps without an extra day. Dates and calendar tokens include the final date; TODAY_START stays at midnight.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to"
+        ],
+        "type": "object"
+      },
+      "walletAddress": {
+        "description": "The wallet address to analyze",
+        "type": "string"
+      }
+    },
+    "required": [
+      "walletAddress",
+      "dateRange"
+    ],
+    "type": "object"
+  }
+]

Related MCP Connectors

Nansen A
io.github.nansen-ai
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Blockchain Web3 & Decentralized Tech Finance
502
solenrich B
io.github.0xSardius
Solana onchain intelligence for AI agents: wallet risk, due-diligence, perps funding, smart money.
Blockchain Cryptocurrency Finance
4922
AgentServices
to.agentservices
52 paid x402 API endpoints for AI agents — crypto, data, DeFi, market intelligence.
Cryptocurrency Finance AI & Machine Learning
22
AI HUNTERZ — Autonomous Crypto Intelligence
io.github.hunterzai16z
49 crypto intelligence APIs. Whale tracking, DeFi yields, alpha signals. Pay in USDC on Base.
Cryptocurrency Blockchain AI & Machine Learning
2

Related MCP Servers

CabalSpy Wallet Tracker MCPofficial
Cryptocurrency Blockchain Finance
CabalSpy
F
license
Not graded
quality
A
maintenance
KOL, smart money & whale wallets API on Solana, BNB, Base, ETH: Wallet tracker, Leaderboard
Updated 3 days ago (2026-10-07 12:23 UTC)
-
CryptoQuant MCP Serverofficial
Blockchain Cryptocurrency Finance
CryptoQuantOfficial
A
license
A
quality
A
maintenance
Enables AI assistants to access real-time on-chain crypto analytics, whale tracking, and market metrics through natural language queries. It provides access to over 245 endpoints for comprehensive data analysis of assets like Bitcoin, Ethereum, and stablecoins.
Updated 5 days ago (2026-10-06 05:18 UTC)
7
259 npm
7
MIT
cryptoiz-mcp
Blockchain Cryptocurrency Finance
dadang11
A
license
Not graded
quality
C
maintenance
AI-powered Solana DEX smart money signals. Detects whale/dolphin accumulation, divergence patterns, and market phase across 170+ tokens. Pay-per-call via x402 USDC micropayments.
Updated 5 months ago (2026-04-29 21:24 UTC)
54 npm
1
MIT
NoesisAPI
Blockchain Web3 & Decentralized Tech Finance
Rengon0x
A
license
Not graded
quality
D
maintenance
Solana on-chain intelligence API — token scans, wallet PnL, bundle detection, fresh wallets, dev profiling. MCP server for Claude, Cursor & AI agents. Live PumpFun/Raydium streams
Updated 5 months ago (2026-05-18 14:26 UTC)
1
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?

Server Details

Available Tools

Query by single address

Query by entity

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Find tokens which are going up in price.

Added some liquidity filter to remove spam and low quality tokens.

Find top stablecoins by market cap

Find AI memecoins with high trading activity

Find DeFi lending tokens

Find tokens which have a lot of buying activity (high nofBuyers and buyVolume)

Note that we added some filters to remove spam and low quality tokens. We added liquidity filter so that we only surface tokens which we can buy or sell.

We sort by netflow descending to get tokens with the most net buying activity.

Find Hyperliquid perps with high open interest and positive net flow

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

CabalSpy Wallet Tracker MCPofficial

CryptoQuant MCP Serverofficial

Glama MCP Gateway

Resources

We sort by `netflow` descending to get tokens with the most net buying activity.