Skip to main content
Glama

YourAITools MCP Hub

SmartPerps: Hyperliquid smart-money bias

smart_money_bias
Read-onlyIdempotent

Is the smart money long or short this coin? For a Hyperliquid perp ticker, shows how the 120 Hyperliquid accounts with the highest 30-day PnL (public leaderboard) are positioned now: bias (strong long to strong short), traders long vs short, snapshot age and coverage. Free preview tier. Paid tiers add notional and 1h/24h flows (lite) or entries, leverage, liquidation bands and top positions (coin). Not for: placing trades, spot markets or non-Hyperliquid venues; for a market-wide scan use smart_money_scan. Read-only analytics on public data; not financial advice.

[SmartPerps via YourAITools MCP Hub] Free tier: same as SmartPerps's own MCP server (call without payment and without tier). Paid: lite $0.003 / coin $0.02 per call, with a credits key (Authorization: Bearer yatc_...) or x402 (USDC; the hub returns the payment terms). Failed tool calls aren't charged: credits are refunded automatically and x402 payments only settle on success.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "smart_money_bias"
  }
}

Input Schema

NameRequiredDescriptionDefault
tierNoPaid tier: lite $0.003, coin $0.02. Omit tier (with no credits key or x402 payment) to use the free tier.
symbolYesHyperliquid perp ticker, e.g. BTC, ETH, SOL, HYPE, kPEPE (BTC-PERP, ETH-USD, SOLUSDT accepted)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / symbol / examples
      Added value: +[
      +  "HYPE"
      +]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, but the description adds material context they cannot: the data source (public leaderboard, top 120 by 30-day PnL), the snapshot-age field, free vs. paid tier boundaries with exact price points, the auth mechanisms (Bearer credits key or x402 USDC), and that failed calls are refunded/never settled. That is behaviorally useful beyond structured fields and is consistent with readOnlyHint.

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?

Front-loading is excellent: the question, the data source, then the excluded uses, then tiers and pricing. The closing hub-attribution and payment/refund paragraph is dense operational boilerplate that could be trimmed, but each sentence still carries distinct decision-relevant information (cost, auth, refunds).

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?

There is no output schema, so the description carries the burden of describing returns — and it does: bias on a strong-long to strong-short scale, traders long vs short counts, snapshot age and coverage, plus the additional fields exposed in each paid tier. For a two-parameter read-only analytics call, nothing an agent needs to invoke it correctly is missing.

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 100%, so the baseline is 3; the description earns an extra point by explaining what the optional `tier` actually buys (notional and 1h/24h flows for lite, entries/leverage/liquidation bands/top positions for coin) and by anchoring `symbol` to Hyperliquid perp tickers with accepted alternate formats. The schema already carries the enum and examples, so the added value is real but incremental.

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?

Opens with a concrete question the tool answers ('Is the smart money long or short this coin?') and names the exact resource and scope: 120 Hyperliquid accounts ranked by 30-day PnL, positioned on a given perp ticker. The sibling smart_money_scan is named as the contrasting market-wide tool, so an agent can discriminate without opening either 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?

Explicit when-not guidance is provided: not for placing trades, spot markets, or non-Hyperliquid venues, plus a direct routing rule ('for a market-wide scan use smart_money_scan'). Tier selection is also given a decision rule: omit tier with no credits key or x402 payment to stay on free.

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