Skip to main content
Glama
jakobautomation

agentsvc-mcp

token_smart_money

Track smart money and whale activity for a token: see large wallets accumulating or distributing, early buyers' holdings, and bot volume to decide whether to follow or avoid trades.

Instructions

Token Smart Money and Whale Tracker — Smart money and whale activity for a token, straight from the chain: which large wallets are accumulating or distributing right now (buy/sell USD, net, average buy and sell price, realized profit, what they still hold), who the first buyers after launch were and whether they still hold or sold everything, and how much of the volume is bots. Trades are attributed to the wallet that really received or sent the token, so Coinbase smart wallets and aggregator routes count as the real trader. Wallet types from on-chain data: trader, fresh_wallet (< 10 tx, possible insider), smart_account, high_frequency_bot, contract. Base, Ethereum, BSC, Arbitrum, Polygon, Avalanche, Optimism. For trading agents deciding whether to follow or avoid a token. Cost: $0.015 USDC per call. Latency p99: 25000ms.

Input Schema

NameRequiredDescriptionDefault
chainNobase, ethereum, bsc, arbitrum, polygon, avalanche or optimism. Default base
hoursNoWindow for current whale activity, 1 to 24 (limited to the most recent blocks the node serves, about 5.5 h on Base)
tokenYesToken contract address (0x...)
min_usdNoUSD a wallet must have bought or sold to count as large. Default: 5% of the window volume, between 50 and 1000
early_buyersNoAlso list the first 20 buyers after launch and whether they still hold
include_botsNoKeep bots and contracts in large_wallets instead of listing them separately

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses cost ($0.015 USDC per call), latency (p99 25000ms), supported chains, the wallet-type taxonomy, the attribution rule (real receiving/sending wallet, aggregator routes), and the data-window limitation (~5.5h on Base). It omits auth requirements, pagination, and error behavior, so not a 5.

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?

Purpose and key return fields are front-loaded, and the cost/latency facts are useful. However the body is one very long run-on sentence loaded with parentheticals, which hurts scannability slightly.

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 data-fetch tool with no output schema, the description effectively substitutes as the return specification, listing the fields an agent will receive plus cost, latency, and chain coverage. It lacks any note on output shape/ordering or failure modes, but the core is 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 chain, hours, token, min_usd, early_buyers, and include_bots; the baseline of 3 applies. The description reinforces chains and wallet categorization but adds no syntax or format detail beyond what the schema provides.

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 resource ('Smart money and whale activity for a token') and enumerates exactly what the agent gets back: large-wallet buy/sell USD, net, average prices, realized profit, holdings, first buyers, bot volume share. This is clearly distinguishable from siblings like token_flows or wallet_portfolio, which cover 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 Guidelines3/5

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

Offers a target audience ('For trading agents deciding whether to follow or avoid a token'), which implies usage, but never states when to choose this over token_flows, token_watch, or wallet_portfolio, and gives no exclusions or prerequisites. Usage is inferable but not explicit.

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

Deploy Server

Other Tools