Skip to main content
Glama

Token key holders

get_token_key_holders
Read-only

The most significant holders of this token and how concentrated ownership is. High concentration is a risk signal worth stating explicitly to the user. ⚠️ These are OTHER people's wallets — this is NOT the user's position in the token. For that, use get_my_position. whale_count/trader_count/kol_count (and the claim's tag_count, when tag is set) are always TRUE totals; page/limit are echoed back. Each row carries the wallet's 30-day win_rate and realized_pnl_30d_usd, and days_since_prev_trade / prev_trade_at for its latest trade in this token (how long the wallet was quiet before it, any token). Rows and counts only include positions worth at least min_position_usd (default $100; each row's value_usd lets you filter further). position is the wallet's tracked buys / sells of THIS token: bought_usd, sold_usd, realized_pnl_usd, buys_count, sells_count, pct_of_peak_held (0-1 of its largest tracked bag still held), first_buy_at, entry_known. Only trades Moby tracked: sells can exceed buys (transfers in, or buys before tracking). When entry_known is false, realized_pnl_usd and pct_of_peak_held are null (unknown, not 0); position is null when Moby never saw the wallet trade the token. KOL platform is never null: unknown plus platform_reason (not_tagged = no platform on record); distinct_kol_platforms counts the known platforms across kols, unknown excluded. Wallet quality: use get_whale_wallet_track_record(wallet_address) for a wallet's win rate and PnL. Results are capped. Raise limit or step page only if the answer is genuinely not in the first page — a large result costs context that later steps of the same task need. This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with get_my_ are the ones that return the user's own data.

Input Schema

NameRequiredDescriptionDefault
tagNoClaim filter behind the expanded Smart Money read: one of the four exclusive tags (holding / bought / trimming / closed) or one of the read's own claims (never_sold / exited_24h / new_24h / left_7d / sat_still). Omit for everyone.
pageNo1-based page number.
sortNoRow order: value (default, largest position first) / newest (most recent first tracked buy first) / oldest (earliest first buy first) / recent_trade (latest tracked buy or sell first).value
limitNoHolders per page, 1-100. Keep it small.
networkNosolana
token_addressYes
min_position_usdNoMinimum live USD position to list or count a holder (whales, traders and KOLs). Omit for the default $100; raise it (e.g. 500) for conviction-only counts. Ignored when `tag` is set.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already establish read-only safety, but the description adds substantial behavioral context: concentration as a risk signal, true totals for counts, `min_position_usd` filtering, null/unknown semantics, tracked-trade limitations, result caps, and context-cost warnings.

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?

The description is front-loaded with purpose and warnings, but it is one very dense paragraph. It repeats the non-user-wallet point and the public-market disclaimer, which makes it less concise than it could be despite the useful detail.

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, existing output schema, and annotations, the description is complete enough for an agent to interpret results and avoid common mistakes. It covers data scope, caveats, filtering behavior, and alternative tools.

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 decent at 71%, and the description adds meaningful semantics for `min_position_usd`, `tag`, `page`, and `limit`, including defaults, ignored cases, and echoed values. It does not add much about `sort`, but the schema enum is adequate.

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?

Clearly states it returns the most significant holders of a token and concentration information. It distinguishes itself from the user's own position via `get_my_position`, but does not explicitly differentiate from sibling holder tools such as `get_token_holders` or `get_token_whale_holders`.

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?

Explicitly directs agents to `get_my_position` for the user's own holdings and to `get_whale_wallet_track_record` for wallet quality, and it gives practical guidance about pagination and context cost. It stops short of explaining when to choose this tool over other holder-focused siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources