Vike Data API

Token Transfers

token_transfers

Read-onlyIdempotent

Get who bought and sold a specific token in a given period, ranked by net USD. tab=bought lists the top NET buyers (bought more than sold), tab=sold the top NET sellers, largest first, with quantities and USD values. Wallets that only pass the token through (routers, pools: bought ~= sold) are not listed; a row can still be a contract (a pool, vault or settlement contract), and title names the known ones; hide_contracts leaves out the contracts we know of. bought / sold / net_tokens are whole tokens, usd_spent / usd_received USD. net_usd = usd_received - usd_spent, so a net buyer's is NEGATIVE: its net USD bought is -net_usd.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "token_address": "<token_address>"
    },
    "name": "token_transfers"
  }
}

Input Schema

Name	Required	Description	Default
`tab`	No	Net buyers or net sellers (default sold)	sold
`chain`	No	Chain (default ethereum)	ethereum
`period`	No	Lookback period (default 24h)	24h
`max_amount`	No	Count only transfers of at most this many tokens (whole tokens, not raw units, up to 1e18). Applied to each transfer BEFORE a wallet's totals are summed, so bought, sold and the USD columns add up only those transfers and a wallet ranks on them alone. Omit for no ceiling
`min_amount`	No	Count only transfers of at least this many tokens (whole tokens, not raw units, up to 1e18). Applied to each transfer BEFORE a wallet's totals are summed, so bought, sold and the USD columns add up only those transfers and a wallet ranks on them alone. Omit for no floor
`token_address`	Yes	Token contract address (0x-prefixed)
`hide_contracts`	No	Leave out the contracts we know of (the website's 'Hide pools & routers'): wallets labelled as a pool, router, vault, bridge or staking contract, and addresses with contract code that bought and sold within 1% of each other (pass-through). Contract code is checked only for the wallets our pages rank, so a contract outside that set can still appear; one that mostly buys or sells (a vault, a smart wallet) stays. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 3, 2026

addedInput schema / properties / max_amount

Added value: +{
+  "description": "Count only transfers of at most this many tokens (whole tokens, not raw units, up to 1e18). Applied to each transfer BEFORE a wallet's totals are summed, so bought, sold and the USD columns add up only those transfers and a wallet ranks on them alone. Omit for no ceiling",
+  "type": [
+    "number",
+    "string"
+  ]
+}

addedInput schema / properties / min_amount

Added value: +{
+  "description": "Count only transfers of at least this many tokens (whole tokens, not raw units, up to 1e18). Applied to each transfer BEFORE a wallet's totals are summed, so bought, sold and the USD columns add up only those transfers and a wallet ranks on them alone. Omit for no floor",
+  "type": [
+    "number",
+    "string"
+  ]
+}

Changed1 schema field changedNov 2, 2026

addedInput schema / properties / hide_contracts

Added value: +{
+  "default": false,
+  "description": "Leave out the contracts we know of (the website's 'Hide pools & routers'): wallets labelled as a pool, router, vault, bridge or staking contract, and addresses with contract code that bought and sold within 1% of each other (pass-through). Contract code is checked only for the wallets our pages rank, so a contract outside that set can still appear; one that mostly buys or sells (a vault, a smart wallet) stays. Default false.",
+  "type": [
+    "boolean",
+    "string"
+  ]
+}

Changed1 schema field changedNov 1, 2026

changedInput schema / properties / tab / description

Previous value: -"Show buyers or sellers (default sold)"New value: +"Net buyers or net sellers (default sold)"

First observedOct 25, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond the supplied readOnly, idempotent, non-destructive annotations, the description discloses ranking behavior, pass-through wallet exclusion, contract rows, and a non-obvious sign convention for net_usd. The clarification that a net buyer's net_usd is negative is particularly valuable and prevents 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 front-loaded with the core purpose and then packs in operational details without obvious filler. It is dense and somewhat run-on, but each sentence contributes useful meaning and nothing is wasted.

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 no output schema, the description does a good job explaining the returned columns and the net_usd sign convention. It does not mention any row limit or pagination behavior for the ranked results, leaving a small gap for a complex ranking tool.

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

Parameters4/5

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

Schema coverage is already 100%, so the schema alone establishes a baseline of 3. The description adds meaningful semantics beyond the schema for tab, clarifying that 'bought' means net buyers and 'sold' means net sellers ranked largest first, and reinforces what hide_contracts excludes.

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 gives a specific verb and resource: 'Get who bought and sold a specific token in a given period, ranked by net USD.' This clearly distinguishes it from generic wallet or token lookup tools, but it does not explicitly differentiate it from siblings such as token_holders or token_screener.

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 explains how tab=bought and tab=sold behave and what hide_contracts does, which implies when to use those options. However, it never states when to choose this tool over alternatives like token_holders or wallet_token_balances, and it provides no explicit exclusions or prerequisites.

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

All Vike Data API tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.