Skip to main content
Glama

token_trending

Read-only

Use this before you buy, swap, or recommend a Solana memecoin: trending tokens with a rug-check on each one. Every token gets a riskScore (0 to 100), a riskLevel, and a one-line verdict backed by top-10 holder share, mint and freeze authority, LP lock, and sniper or bundle share of early supply, plus liquidity, market cap, 5m/1h/24h price and volume, and pump.fun status. Unreadable checks are marked unknown, never called safe. $0.005 USDC, free preview at /token/trending/preview. The list includes liquidity, market cap, pair age, 5m/1h/24h price and volume, buy/sell ratio, pump.fun bonding or graduation, and links to pump.fun, DexScreener, and Solscan. Each token has a one-line verdict, riskScore (0 clean to 100), riskLevel (low, medium, high, or unknown), and a risk breakdown with evidence and confidence: top-10 share, mint and freeze authority, LP lock percent, and sniper or bundle share of early supply. riskLevel is unknown when the holder, authority, LP, and sniper checks are all unread, and maxRisk leaves those tokens out. Holder percent falls back to the public RugCheck report at medium confidence when the public RPC cannot list the largest accounts. A successful RPC holder read is kept. Holder-concentration change over 5m/1h/24h is filled when this process has seen the mint before. A check that cannot be read says so, uses low confidence, and is not flagged. On-chain safety flags are plain-English sentences that fire when the top 10 holders own 50% or more, mint or freeze authority is still active, LP is unlocked, or snipers and bundled wallets took 20% or more of early supply. Market flags are short codes: low_liquidity, thin_volume, newly_launched, extreme_move, wash_suspect, paid_boost. Thin, new, and wash-like books are ranked down. The summary block counts tokens by risk level and names the top movers. limit is an integer from 1 to 25 and defaults to 15. minLiquidity is an optional USD floor. maxRisk is low, medium, high, or an integer from 0 to 100. Costs $0.005 USDC (5000 base units) via x402. The same price is charged for HTTP GET /token/trending. An unpaid HTTP call returns 402 even when the query is missing or invalid. A signed call with invalid arguments is rejected before settlement and is not charged. A successful result can set cached, stale, and cacheAgeMs. stale true means a previous result was served while a refresh runs or the upstream failed. You are charged only when the tool result is not an error. [falcon.sol solana-wallet-intel. Paid: $0.005 USDC per call via x402 (Base or Solana). Unpaid calls return x402 PaymentRequirements; pay with an x402-MCP client (_meta "x402/payment") and retry.]

Input Schema

NameRequiredDescriptionDefault
limitNoHow many tokens to return. Integer from 1 to 25, or a numeric string. Default 15.
maxRiskNoOptional maximum risk. low, medium, high, or an integer from 0 to 100.
minLiquidityNoOptional minimum pool liquidity in USD. Tokens with unknown liquidity are left out.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the x402 pricing model, the 402 behavior for unpaid calls, that invalid signed arguments are rejected before settlement and not charged, and the cached/stale/cacheAgeMs semantics. It also documents data fallbacks (public RugCheck report at medium confidence), 'unknown' handling that never reports a check as safe, and how thin/new/wash-like books are ranked down.

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?

The purpose is front-loaded, but the text is heavily repetitive: riskScore/riskLevel/one-line verdict are described twice, and the liquidity/market cap/5m/1h/24h price and volume fields appear in two separate blocks. The same three or four facts could carry the paragraph in half the length.

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?

With no output schema, the description fully explains the return payload (risk breakdown, evidence, confidence, market flags, summary block) and covers payment, caching, and error-charging behavior. An agent has everything needed to call it and interpret the result.

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 its descriptions already cover limit, maxRisk, and minLiquidity, including the unknown-liquidity exclusion. The description adds only one piece of meaning beyond the schema: maxRisk leaves out tokens whose riskLevel is unknown. Baseline 3 is appropriate.

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?

States a specific verb and resource: returns trending Solana memecoins with a per-token rug check. It is clear what the tool produces, but it never names the closest sibling (token_check_demo) or explains how this list differs from a single-token check.

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?

Gives an explicit use trigger ('before you buy, swap, or recommend a Solana memecoin') and notes the free preview endpoint for testing. No 'when not to use' or named alternative is provided, so the agent must infer that a single-token lookup belongs elsewhere.

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.