Skip to main content
Glama

Token overview

get_token_overview
Read-only

Everything Moby knows about one token in a single call: price, market cap, liquidity, volume, holder counts, safety signals and metadata. This is the default tool for 'tell me about '. Get token_address from search_tokens. liquidity_source says where liquidity sits: bonding_curve = a launchpad coin not yet migrated, liquidity is its curve reserve (0 = curve drained, everyone sold) and graduation_pct is % of the curve filled; dex_pool otherwise; null = unknown. market_cap is the circulating market cap (market_cap_basis is circulating), or the fully diluted value when Moby has no circulating figure (fully_diluted, flagged in data_notes). fdv is the fully diluted valuation (price x total supply). ath_market_cap (alias ath_mc) is the all-time-high on the same basis as market_cap; ath_fdv is the all-time-high FDV. Compare like with like: a coin is at its ATH only when market_cap ~= ath_market_cap or fdv ~= ath_fdv, never market_cap against ath_fdv. 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). safety_note spells out the tier. stats.untouched_pct equals the detail.tags Untouched cell's pct: one window (detail.window, last 7 days or since launch) and one denominator (detail.total, current Key Holders plus wallets that sold out in the window). Each wallet gets one tag: Sold out > Trimmed (its Key Holders story chip is trimming, or it sold in the window without buying) > Added (bought in the window) > Untouched. smart_money_read_v2 mixes two windows ON PURPOSE: tier/label/verdict grade the LAST HOUR of tracked-wallet flow (tier is green|yellow|red|holding, label is Buying|Holding|Selling|Mixed|Quiet); color/text/sentences/bullets/stats describe the 7-DAY holder base. They can disagree: green/Buying with red text means buying this hour into a base that churned all week — say both. Gate entries on tier, and read text for what the base did. stats.left_* is every tracked wallet that sold out (what the copy quotes); stats.exited_* is the entry-known subset the ratios use. concentration is the largest tracked holder (supply_pct, bag_to_liquidity, multiple_on_entry); flagged means one wallet carries the read or out-sizes the pool, and tier_cap_reason: concentration means the green hour was capped to yellow for it — treat the buying as one bag, not a crowd. data_notes lists the fields Moby lacks or knows only in part (launchpad unknown, a market_cap that may count one chain of a multichain coin, no holders_count, an unscored safety_tier, a risk scan that is not ok), each with what to verify on the web. When Moby lacks a data point (a null field, or one listed in data_notes), check the web (the project's site, docs or API, DexScreener, X) before quoting it, and never present a Moby-only number as the whole picture. 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
networkNosolana
token_addressYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, non-destructive, open-world), but the description goes far beyond them: how safety_tier colours should be interpreted (grey is NOT a red flag), that Moby refuses agent buys on red, that smart_money_read_v2 deliberately mixes a 1-hour tier with a 7-day base and the two can disagree, and that data_notes enumerates known gaps requiring web verification. That is exactly the extra behavioural context an agent needs.

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

Conciseness2/5

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

It is front-loaded correctly with the purpose, but the body is a single unstructured wall of several hundred words covering output-field interpretation, alias names, tier colour semantics and window mixing. Much of this overlaps with the existing output schema, and the density makes it hard to scan for the one thing needed at call time.

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 an output schema exists and a rich annotation set, the definition is more than complete: it explains how to interpret ATH bases, concentration capping, exited vs left-out wallet stats, and what to do when Moby lacks a data point. Nothing needed to call or interpret the result 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 0%, so the description carries the burden. It does add meaning for token_address (source it from search_tokens), but the second parameter, network, is never mentioned even though it is a const/default field the agent may need to reason about. Partial compensation only.

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 opening sentence names a specific resource (one token) and enumerates exactly what it returns (price, market cap, liquidity, volume, holders, safety, metadata), and explicitly declares itself 'the default tool for tell me about <token>'. This clearly separates it from siblings like get_token_price, get_token_holders and get_token_chart.

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 default-use case, tells the agent where to obtain the required argument ('Get token_address from search_tokens'), and gives an explicit exclusion: market data only, not the user's own wallet — use get_my_* tools for that. Both a positive routing rule and a negative one are present.

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