SOL+BTC positioning: long/short account ratio (retail crowding) + open interest with 1h/24h change (Bybit). Costs $0.004 USDC per call (x402, Solana mainnet).
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds genuinely useful behavior beyond the schema: a hard cost of $0.004 USDC per call via x402 on Solana mainnet, plus the data composition and venue (Bybit, 1h/24h deltas). It does not cover output format, data freshness, rate limits, or failure modes, so it is solid but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first packs metric composition, venue, timeframes, and interpretation; the second packs cost and payment rail. There is no filler and no repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only data call with no output schema, the description covers the key decision inputs — what metrics come back, from where, and at what cost. The main lacuna is the return shape (single combined reading vs. separate SOL/BTC values), but invocation itself is fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to clarify about arguments; the baseline of 4 applies. The description instead usefully explains what the returned data measures (long/short ratio, OI change), which is the relevant semantic content for this parameterless call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool returns: SOL+BTC positioning composed of long/short account ratio (labeled as retail crowding) plus open interest with 1h/24h change on Bybit. This distinguishes it from overlapping siblings like get_long_short and get_open_interest by naming the venue and the combined metric composition. Minor deduction: it is phrased as a noun phrase rather than a declarative verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'retail crowding' gloss implies a use case — assessing how crowded retail positioning is — and the venue/timeframe scoping gives selection context. However, there is no explicit when-to-use or when-not-to guidance, and with 52 siblings including get_long_short and get_open_interest, explicit routing instructions would materially help an agent choose this tool over the alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools are tightly scoped and cross-referenced, but the set contains overlapping families: liquidation tools (alert/scan/history/stats/leaders/recent/heatmap) and redundant snapshots like get_market_snapshot vs get_trade_context, get_last_liquidation vs get_recent_liquidations, and get_cascade_forecast_free vs get_cascade_forecast. Agents will need to read descriptions carefully to avoid misselection.
All tool names follow a consistent get_<domain>_<detail> snake_case pattern, which makes the API predictable. The only real deviations are the bare 'pricing' tool and the 'free' suffix on taster variants.
At 52 tools, this far exceeds the 3-15 well-scoped range and crosses the 50-tool extreme threshold. The count is inflated by numerous paid/free taster pairs and many overlapping liquidation variants.
The surface covers prices, funding, open interest, orderbooks, liquidations, wallet/token data, Solana network health, DeFi TVL, and stablecoin flows—broad coverage for a crypto data feed. Gaps like historical OHLC/price candles, a machine-readable symbol list, and pagination endpoints are workable around but would round it out.