Tanod MCP server

chainpeek: recent large trades on a token, who is buying and selling, on Base or Ethereum

get_large_token_trades

Read-onlyIdempotent

Find recent large ERC-20 buys and sells on Base or Ethereum to see which wallets traded in size, with USD amounts, side, pool, and tx hash.

Instructions

chainpeek: Who is buying this token? Recent large trades: big buys and sells on Base or Ethereum. For Solana use get_large_solana_token_trades; for a quote at your size use get_swap_quote. Returns who bought and sold an ERC-20 in size: the recent large buys and sells of it on Base or Ethereum from DEX swap events (Uniswap V2/V3, Aerodrome): time, side, token amount, USD size, the transaction sender as wallet, tx hash and pool, newest first, at most 50. Size-based only, no wallet is labelled; read from swap events of the top 3 pools, so it can miss trades elsewhere; amounts are heuristic; a bad address or a window over 60 minutes (Base) or 240 (Ethereum) is a 422 (not charged); cached 30 s. Typically 3 to 6 s (pool discovery, one log read per pool, one batch for the senders), at most 25 s. Price: USD 0.01. Free: 10 chain reads per IP per UTC day. Docs: https://tanod.dev/learn/token-large-trades-api.html

Input Schema

TableJSON Schema

Name	Required	Description	Default
`chain`	No	base (default) or ethereum.	base
`token`	Yes	ERC-20 token address (0x + 40 hex).
`min_usd`	No	Smallest trade to report, in USD of the quote side (default 1000, minimum 100).
`window_minutes`	No	How far back to read, in minutes (default 60). At most 60 on Base and 240 on Ethereum, so that the window fits one eth_getLogs read of at most 2,000 blocks per pool.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No
`block`	No
`chain`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`pools`	No
`token`	No
`cached`	No
`reason`	No
`trades`	No
`window`	No
`eth_usd`	No
`min_usd`	No
`decimals`	No
`returned`	No
`truncated`	No
`trade_count`	No
`swaps_scanned`	No
`wallets_unavailable`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: 30 s cache, 422 on bad address or oversized window (and not charged), 3-6 s typical / 25 s max latency, USD 0.01 price, free-tier limit, and honest limitations (misses trades outside top 3 pools, heuristic amounts, no wallet labels). This is the level of disclosure that actually changes how an agent calls the tool.

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

Conciseness4/5

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

Front-loaded with purpose, then alternatives, then return shape, then caveats — a sensible order. It is a single dense block that packs in a lot (latency, price, cache, error codes), which is justified by the tool's complexity but borders on overloaded.

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 tool with a full output schema, this covers everything an agent needs: routing, return fields, data-quality caveats, error behavior, latency, cost, and a docs link. Nothing material is missing.

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

Parameters3/5

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

Schema coverage is 100% and every parameter already carries its own description, including the Base 60 / Ethereum 240 window rationale and min_usd semantics. The description largely restates those constraints rather than adding new parameter-level meaning, so baseline 3 applies.

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 ('Recent large trades: big buys and sells on Base or Ethereum') and names exactly which sibling covers the Solana case and which covers quoting. An agent can distinguish this from get_large_solana_token_trades and get_swap_quote without opening any 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?

Explicit routing: 'For Solana use get_large_solana_token_trades; for a quote at your size use get_swap_quote.' It also implies when-not via the size-based-only caveat, so the agent knows this tool won't help for small or wallet-attributed flows.

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

Deploy Server