Get real-time price data for one or more crypto futures symbols. Returns current price, 24h high/low, volume, and 24h price change percentage.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes | List of symbols to get prices for, e.g. ["BTCUSDT", "ETHUSDT"] |
| Name | Required | Description | Default |
|---|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description aligns with these (fetches data, no writes). It adds behavioral detail about what data is returned (current price, high/low, volume, change), which is useful. However, it does not disclose details like rate limits, potential symbol validation, or handling of invalid symbols. With annotations covering the safety profile, the description adds some value but isn't rich on edge-case behaviors.
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?
The description is two sentences, front-loads the main purpose, and wastes no words. Every sentence provides value: the first defines the action, the second lists return data. It is appropriately concise for the complexity.
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?
Given the tool's simplicity (one parameter, read-only, output schema exists), the description is complete enough for selection and invocation. It lists key return data. It does not describe all output schema fields, but the output schema likely covers that. Minor gap: no mention of error handling or symbol format beyond the example, but this is minor for a price-query tool.
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 schema covers 100% of the one parameter ('symbols') with a description and example. The tool description adds context about what the data is used for (real-time price data) but does not add meaning beyond the schema's parameter description. Given high schema coverage, baseline 3 is appropriate.
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 clearly states the tool's purpose: 'Get real-time price data for one or more crypto futures symbols.' It specifies the resource (price data), the action (get), and the scope (one or more symbols). It also lists the returned data points (current price, 24h high/low, volume, 24h change). This distinguishes it from siblings like get_candles or get_market_stats, which likely focus on different data types.
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 description implies usage for fetching current prices, but does not explicitly state when to use this tool versus alternatives. For example, it doesn't say 'use this for live spot-price queries, use get_candles for OHLC history' or reference siblings. The context of 'real-time' and '24h' data gives some implicit guidance, but explicit differentiation or when-not-to-use scenarios are absent.
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.
Most tools have clearly distinct purposes: market data, signals, trader profiles, and account info are well separated. However, get_elite_leaderboard and get_top_traders both return ranked trader lists and could easily be mistaken for one another despite slightly different criteria.
Every tool uses a consistent get_ prefix followed by a descriptive noun phrase (get_candles, get_signal_details, get_trader_profile). The naming pattern is highly predictable and makes the toolset easy to navigate.
15 tools is at the upper bound of the ideal range, but each tool maps to a distinct data surface—market data, signals, traders, leaderboards, and account info. The count feels appropriate for a comprehensive crypto intelligence API.
The toolset covers the core read-only domain thoroughly: price/candle data, technical indicators, signals and their stats, trader rankings and profiles, position history, and account details. No significant gaps are apparent for the stated purpose of a smart-money tracking and analytics service.