Live quotes for the S&P 500 (SPY ETF), gold (GLD ETF) and Nasdaq 100 (QQQ ETF). Macro context for risk-on/risk-off and the correlation of traditional markets with crypto. These are ETFs priced in USD per share, so use direction and percent change rather than the absolute index level.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| quotes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to re-state safety. It adds value by clarifying the return behavior (ETFs priced in USD per share, use direction/percent change not absolute index level), but does not disclose anything beyond annotations plus this formatting hint.
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 long and front-loads the essential information (which ETFs). The explanation about how to interpret the data is helpful but could be slightly more concise. No wasted sentences.
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 has zero parameters, a complete output schema, and comprehensive annotations, the description adequately covers what an agent needs to know: which assets are included and how to interpret their values. It could mention the return format or data frequency, but for a quote tool with missing title, this is reasonably complete.
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 has zero parameters and the schema coverage is 100%, so the description has no parameters to document. However, the description provides meaningful usage semantics about interpreting the output (direction and percent change vs absolute level), which adds value beyond the schema.
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 explicitly names the specific ETFs (SPY, GLD, QQQ) and provides the context that these are USD-priced ETFs, making the tool's purpose clear. It could better distinguish from the sibling tool get_crypto_market, but it does state these are traditional markets for macro context.
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 mentions 'macro context for risk-on/risk-off and the correlation of traditional markets with crypto,' which implies it should be used when analyzing cross-market relationships. However, it does not explicitly say when to use this versus alternatives like get_crypto_market or get_fear_greed, nor does it provide exclusions.
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 target distinct domains (network, market, derivatives, macro, on-chain flows), and overlapping tools like get_derivatives vs get_derivatives_aggregate are clearly differentiated by scope and detail level. However, get_crypto_market and get_market_dominance both cover market-wide data, and get_btc_network and get_eth_whale_flows both touch on-chain activity, which could cause some confusion.
All tool names follow a consistent get_ prefix with descriptive nouns (e.g., get_btc_network, get_defi_overview, get_execution_cost). The pattern is uniform across all 16 tools, with no camelCase or inconsistent verb styles, making it very predictable for an agent.
With 16 tools, the server covers a broad but coherent domain of crypto market analysis—prices, on-chain, derivatives, macro, sentiment, and execution. Each tool addresses a distinct analytical need, and the count is well-scoped for a comprehensive agent, not excessive given the breadth of features.
The surface is remarkably complete for a market analysis agent, covering spot, derivatives, on-chain, macro, sentiment, history, and execution costs. Minor gaps exist: no direct tool for decentralized exchange (DEX) trading volumes or specific coin list discovery, and no tool for order book depth beyond the execution cost tool. However, agents can work around these with existing tools.