Skip to main content
Glama

Token leaderboard

get_screener_leaderboard
Read-only

The main Moby token leaderboard: the tokens with the most notable activity right now, ranked best-first by Moby's composite 24h score. Start here when the user asks what is moving, what is trending, or what they should be looking at, and they have not named a specific token. Page 1 is the top of the board — for 'what is hot right now' the default page is the whole answer. Moby's leaderboards: Main = get_screener_leaderboard (composite 24h activity, 'what's moving'); Degen = get_degen_leaderboard (newer, smaller, higher risk); Majors = get_group_leaderboard(group_id="home_majors"); Stocks = get_group_leaderboard(group_id="home_stocks") (tokenized stocks); Pulse = get_group_leaderboard(group_id="home_pulse"). The Solana group ids majors_solana / stocks_solana work too, and the home_* ids are listed under home_tabs in get_screener_groups. The Majors and Stocks boards are THE reference for major and tokenized-stock contract addresses: take token_address from the row. Never resolve a major or a stock by ticker search alone, and never keep your own mint list. 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. whale_windows (any of h1/h4/h8/h24) adds a per-row whale block per window: whale_count (distinct tracked wallets that bought OR sold — buyers plus sellers, not buyers alone), whale_buyers_count (distinct buyers only), whale_buys_count, whale_sells_count and whale_net_flow_usd. The row's whale_count_h24 is the same buyers-plus-sellers count. Null figures mean unknown. asset_class: tokenized_stock marks tokenized equities (treat as stock proxies, not memecoins). safety_tier: green = verified; grey = usually fine (not scored yet or a young launchpad token, NOT a red flag — do not skip a coin for being grey); red = caution / DYOR, the only tier to treat as a warning (Moby refuses agent buys on red). 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
pageNo1-based page number. Page 1 is the top.
limitNoTokens per page, 1-100. Keep it small.
networkNosolana
whale_windowsNoWindows for the optional per-row `whale` block, e.g. ["h1", "h4"]. Omit for the default row.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare read-only/open-world/non-destructive behavior, but the description adds substantial operational context: capped results, pagination context cost, whale-block field meanings, null semantics, safety_tier meanings, and the red-tier buy restriction. It also clarifies that this is public market data, not the user's wallet data.

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 front-loads the purpose and usage guidance before moving through alternatives, pagination behavior, whale fields, and safety tiers. Given the crowded sibling set and non-obvious row semantics, the dense sentences earn their place without decorative fluff.

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?

An output schema exists, so the description need not fully document return values, yet it still covers selection context, pagination, whale output interpretation, asset_class, and safety_tier behavior. This gives an agent enough context to invoke and use 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?

With 75% schema coverage, the schema documents page, limit, and whale_windows, and the description adds meaningful usage guidance: page 1 is the default answer, raise limit/page only when necessary, and whale_windows adds a per-row whale block with defined buyer/seller counts and net flow. The network parameter is const solana, so the description's lack of elaboration there is acceptable.

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 explicitly identifies the resource (Moby token leaderboard), the ranking basis (composite 24h score), and the whole-market public-data scope. It also distinguishes this board from sibling leaderboards and get_my_* tools, so an agent can select it without opening another 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?

It states the primary use case directly: start here when the user asks what is moving, trending, or what they should look at, and has not named a specific token. It also names alternatives and their conditions, including Degen, Majors, Stocks, Pulse, and get_my_* tools for user-specific data.

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