Crypto and macro market data for AI agents: funding rates and open interest across Binance, Bybit, OKX and Hyperliquid for up to 10 coins in a single call, plus Fear & Greed, ETH exchange flows, BTC/ETH/USDT dominance and the macro regime (Fed funds, CPI, 2s10s, dollar index). 17 free keyless tools, plus one paid tool that answers a specific market question as structured JSON — $0.25 in USDC over x402, no signup and no API key.
Scored across 18 tools
Most tools target clearly distinct data sources, and the derivative tools explicitly cross-reference each other (single-coin get_derivatives vs. watchlist get_derivatives_aggregate), as do get_implied_volatility and get_macro_rates' VIX. The one real overlap is analyze_market and get_market_brief, which both emit a regime/stance with confidence and an invalidation level; an agent could reasonably hesitate between the paid question-driven analysis and the deterministic composite brief.
All 18 tools use snake_case verb_noun form (analyze_market plus 17 get_* tools), with predictable domain prefixes like get_market_* and get_eth_*. No mixed conventions or vague verbs; the single analyze_ verb still fits the verb_noun pattern and signal its distinct role.
18 tools is slightly above the ideal range, but the server spans a genuinely broad surface (spot prices, derivatives, on-chain, macro, sentiment, execution) where each tool maps to a distinct endpoint with little redundancy. It earns its places rather than padding, though it borders on heavy.
Coverage is strong across prices, dominance, derivatives positioning, implied volatility, Fear & Greed, BTC on-chain, ETH whale/address flows, DeFi, macro rates/calendar, execution cost, and composite briefs. Minor gaps remain: no historical price/candle series (get_market_history only percentiles funding/OI/FG/dominance), on-chain metrics are BTC-centric, and there's no ETH network (gas) data.
Paid, $0.25 in USDC on Base, settled per call over x402 — no key, no account. Ask a specific question about Bitcoin, Ethereum, altcoins or macro. An agent picks the live market-data tools it needs (prices, funding rates, open interest, Fear & Greed, macro rates), runs them, and returns one JSON object: regime, confidence, the numbers behind the call, bull and bear scenarios, the level that invalidates it. Calling without payment returns the price and a sample of the output, and costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional free-form context to take into account. | |
| language | No | Language of the text fields. Defaults to en. | |
| question | Yes | The question to answer, e.g. "Is BTC funding overheated right now?" |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| analysis | No | |
| tools_called | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: the exact price ($0.25 USDC on Base) and payment rail (x402, no key or account), and the critical fallback behavior that an unpaid call returns the price plus a sample at no cost. These are real operational facts an agent cannot infer from readOnlyHint/openWorldHint alone.
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?
Three dense sentences that front-load the payment model before the capability and then the free-preview fallback. Nearly every sentence earns its place, though the payment and output enumeration make it slightly heavy for a single paragraph.
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 paid, open-world synthesis tool with an output schema present, the description covers cost, payment mechanics, inputs expected, and a preview fallback. Nothing an agent needs to decide to call it or to understand the billing consequence is missing.
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?
Schema coverage is 100%, so the schema already documents question, context, and language including the enum and default. The description reinforces that a specific question is expected and shows one sample question, but adds little syntactic detail beyond the schema, so baseline 3 applies.
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?
States a specific verb+resource — answering a targeted crypto question — and enumerates the live data tools it orchestrates (prices, funding rates, open interest, Fear & Greed, macro rates) plus the exact output shape (regime, confidence, scenarios, invalidation level). This clearly separates it from the raw-data siblings like get_market_quotes or get_derivatives.
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?
Gives clear context for use: ask a specific question and get a synthesized call rather than raw numbers, with an explicit no-cost preview path when payment is absent. It does not explicitly name an alternative (e.g. get_market_brief) or state when a raw-data sibling is preferable, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live Bitcoin network health: hashrate, difficulty, transaction count, estimated volume, miner revenue and the largest recent mempool transactions (>10 BTC). Call for on-chain Bitcoin activity. Miner revenue is null when the source stops publishing it, never a misleading zero.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| hashRate | No | |
| difficulty | No | |
| txCount24h | No | |
| marketPrice | No | |
| tradeVolumeUsd | No | |
| btcLargeMempool | No | Largest transactions currently waiting in the mempool. |
| minersRevenueUsd | No | null when the source does not publish it. Never 0 - miner revenue cannot be zero while blocks are produced. |
| estimatedTxVolumeUsd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable nuance: 'Miner revenue is null when the source stops publishing it, never a misleading zero,' which explains a potential output edge case. This goes beyond the annotation baseline, but does not exhaustively describe all behaviors (e.g., throttling or data freshness). A 4 is appropriate.
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 with no fluff. The main purpose is front-loaded, and the additional note about null values is essential and efficient. Every word earns its place, fitting the conciseness ideal.
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 tool with an output schema, the description fully covers what the tool does, what it returns, and a key behavioral nuance (null handling). There are no missing prerequisites, side effects, or return format ambiguities. The description is complete for the tool's complexity.
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, so the baseline for parameter semantics is 4 per the rubric. The description does not need to explain parameters since none exist, and the schema coverage is moot. The description's mention of what data is returned (e.g., 'largest recent mempool transactions >10 BTC') indirectly informs what the output contains, which is sufficient.
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: 'Live Bitcoin network health' and lists specific metrics (hashrate, difficulty, transaction count, etc.), distinguishing it from sibling cryptocurrency tools like market quotes or news. The verb 'get' and resource 'BTC network' are explicit, and the scope is unambiguous.
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 explicitly says 'Call for on-chain Bitcoin activity,' which gives a clear use case. It does not explicitly mention when not to use it or alternatives, but given the sibling list, the context is enough to infer this is for network health rather than market data. Lacking explicit exclusions, it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live crypto prices and market data: spot price, market cap, 24h volume and change for any coins (Bitcoin, Ethereum, Solana, altcoins). Call for any price, market cap or volume question.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Coin IDs as lowercase slugs, e.g. ['bitcoin','ethereum','solana'] | |
| vs_currency | No | Quote currency, defaults to 'usd' |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that data is 'live', implying real-time freshness, but says nothing about rate limits, auth, or data provenance beyond that. Adequate but not rich.
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, front-loaded with the resource and its fields, followed by the invocation cue. No filler or redundancy.
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?
With a rich output schema and full annotations, the description need not explain returns; it covers scope and a usage trigger. It is largely complete, though missing sibling differentiation leaves slight ambiguity among the many market-data tools.
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?
Schema description coverage is 100%, with both ids and vs_currency documented including slug format and default. The description adds only 'for any coins', so baseline 3 is appropriate; it does not add meaning 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?
States a specific verb+resource (get live crypto prices/market data) and enumerates the exact fields returned: spot price, market cap, 24h volume, 24h change, with example coins. Clear but does not differentiate itself from siblings like get_market_quotes or get_market_dominance.
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?
Gives an explicit trigger: 'Call for any price, market cap or volume question.' This is clear context for invocation, though it names no exclusions or alternative sibling tools for overlapping needs (e.g. dominance or market brief).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent crypto headlines for narrative context and catalysts. Summarize in your own words with attribution to the reporting outlet; do not reproduce articles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes | Recent headlines, newest first. Summaries are our own words, not article text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the baseline safety and idempotency are covered. The description adds value by revealing the output expectation (summarization with attribution) and the constraint on reproduction, which are behavioral traits beyond the annotations.
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-loaded with the core purpose. Every sentence adds essential information: the first states the purpose, the second states usage rules. No wasted words.
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?
The tool has no parameters and a rich annotations set. The description is complete for the tool's simplicity, covering purpose, usage guidelines, and output handling. An output schema exists, so the description does not need to detail return structure. Given the minimal complexity, the description is fully adequate.
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?
Schema description coverage is 100% with zero parameters, so the description does not need to document parameters. The description adds context about what the tool returns (headlines with narrative context and catalysts) and how the agent should use them, which is meaningful semantic guidance 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 clearly specifies a verb ('get') and resource ('crypto headlines'). It distinguishes the tool from siblings by focusing on 'narrative context and catalysts,' which sets it apart from market data tools like get_crypto_market or on-chain tools like get_eth_address.
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 explicitly directs the agent to summarize in its own words and attribute to the reporting outlet, which is a concrete usage guideline. It also prohibits reproduction of articles, setting clear boundaries. This helps the agent use the tool appropriately and avoid copyright issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live DeFi overview: total value locked (TVL), top chains by TVL and stablecoin market cap. Call for DeFi flows, liquidity and dry powder, or risk-on/risk-off reads.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| totalTvl | Yes | Total value locked across DeFi, in USD. |
| topChains | Yes | |
| stablecoinMarketCap | No | Dry powder waiting on the sidelines. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already declares readOnlyHint=true, destructiveHint=false, so the agent knows it's safe. The description adds that the data is 'Live', indicating real-time freshness, and enumerates the exposed metrics. No annotation contradiction; the description aligns with the safe, idempotent, read-only profile.
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, zero wasted words. The first sentence front-loads the core purpose and key data categories. The second sentence adds clear guidance on when to call. Every word earns its place; no repetition of annotation fields (title, hints).
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?
Despite the tool having no parameters and an existing output schema, the description covers all necessary context: what data it provides (TVL, chains, stablecoin cap) and when to use it (DeFi flows, liquidity, risk appetite). The agent can decide to call or skip without additional blanks.
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 input schema has 0 parameters, so baseline is 4 per guidelines. Description correctly states the tool returns TVL, top chains, and stablecoin cap – these are output concepts, not parameters. Since no parameters exist, the description cannot add parameter meaning, but it appropriately describes what the tool returns without needing param info.
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 'Live DeFi overview: total value locked (TVL), top chains by TVL and stablecoin market cap.' This provides a specific verb ('overview') and resource ('DeFi'), and lists concrete metrics. It differentiates from sibling tools like get_crypto_market (general crypto) or get_market_dominance (dominance) by focusing exclusively on DeFi liquidity metrics.
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 includes explicit use-case guidance: 'Call for DeFi flows, liquidity and dry powder, or risk-on/risk-off reads.' This tells the agent when to choose this tool over siblings. However, it does not mention any prerequisites or limitations (e.g., data update frequency, supported blockchains), which would improve the guideline further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Venue-by-venue breakdown for a single coin: what each major liquid venue — Binance, Bybit, OKX and Hyperliquid, the largest perpetual DEX — shows for funding and open interest, taken from that venue's largest-open-interest perpetual. Returns the per-venue rows plus the average funding, total open interest in USD and the funding spread. Reach for this when divergence between venues matters — one venue far more positive or negative than the rest signals localised positioning rather than market consensus. Takes one coin only; to sweep several at once, call get_derivatives_aggregate. Funding is returned in PERCENT per 8 hours (0.0061 means 0.0061%, not 0.61%) and also ANNUALIZED as a percent per year, so it can be compared directly against any other yield; open interest is in USD. Errors if the coin has no major-venue data. Current snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Coin or pair, e.g. BTC, BTCUSDT, ETH |
| Name | Required | Description |
|---|---|---|
| coin | Yes | |
| perExchange | Yes | Per-venue breakdown, from each venue's largest-open-interest perpetual. |
| exchangeCount | Yes | How many major venues backed the numbers. |
| fundingSpread | No | Highest minus lowest venue funding. A wide spread marks localised positioning. |
| avgFundingRate | No | Percent per 8 hours. 0.0067 means 0.0067%, not 0.67%. |
| totalOpenInterestUsd | No | Summed across the major venues. |
| avgFundingAnnualizedPct | No | The same funding as a yearly percentage, comparable to any other yield. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's safe. Description adds value beyond annotations: specifies return structure (per-venue rows plus averages), funding units (percent per 8 hours and annualized), OI in USD, and error behavior. No contradiction with annotations.
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?
Six sentences, no wasted words. Front-loaded with main result and venues. Each sentence adds essential information: venues, output fields, usage guidance, unit clarification, error condition. Well-structured for quick agent scanning.
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 (single parameter, output schema present), the description covers all necessary context: what data is returned, from which venues, units, error condition, and relation to sibling tool. No gaps remain.
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?
Schema coverage is 100% with a single 'symbol' parameter already described as 'Coin or pair, e.g. BTC, BTCUSDT, ETH'. Description reinforces 'Takes one coin only' but adds no new semantic detail beyond the schema. Baseline 3 is appropriate given high schema coverage.
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?
Description clearly states it provides 'venue-by-venue breakdown for a single coin' showing funding and open interest from major venues. Explicitly distinguishes from sibling 'get_derivatives_aggregate' for sweeping multiple coins. Uses specific verb 'get' (implied) and resource 'derivatives' with precision.
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?
Explicitly advises when to use: 'Reach for this when divergence between venues matters'. Provides clear exclusion: 'Takes one coin only; to sweep several at once, call get_derivatives_aggregate'. Also notes error condition when no data exists, setting proper expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Watchlist sweep over up to 10 coins in one call: the headline funding and open interest figures per coin — average funding, total open interest in USD, funding spread — with no per-venue rows, which keeps the response compact enough to compare positioning across a basket. Costs a single upstream call no matter how many coins you request, so prefer it over repeated single-coin calls. Figures come from the major liquid venues — Binance, Bybit, OKX and Hyperliquid; thin venues are excluded, since their outlier rates would otherwise distort the average by an order of magnitude. Coins with no major-venue data are listed in "unavailable" instead of failing the whole request. Reach for get_derivatives instead when you need the per-venue detail on one coin. Funding is returned in PERCENT per 8 hours (0.0061 means 0.0061%, not 0.61%) and also ANNUALIZED as a percent per year — 0.0067% per 8h is 7.3% a year, which says immediately whether a long is paying more than a bond yields. Open interest is in USD. Current snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| coins | No | Base coins, e.g. ["BTC","ETH","SOL"]. Maximum 10. Defaults to BTC and ETH. |
| Name | Required | Description |
|---|---|---|
| coins | Yes | |
| unavailable | Yes | Requested coins with no major-venue perpetual. Never silently dropped. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, establishing safety. The description adds substantial behavioral context: costs a single upstream call, excludes thin venues to avoid outlier distortion, handles unavailable coins gracefully, and details the units (percent per 8h, annualized, OI in USD). This goes well beyond what annotations provide, and there is no contradiction.
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 well-structured, starting with a clear action statement, then explaining benefits, data sources, handling of missing data, units, and the alternative tool. Every sentence adds value. However, it is slightly verbose (multiple sentences on units could be condensed), preventing a perfect score.
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 complexity (aggregate derivatives across multiple venues), the description covers all critical aspects: what data is returned (funding, OI, spread), how it is aggregated (no per-venue rows), data sources (Binance, Bybit, OKX, Hyperliquid), handling of unavailable coins, and units. The presence of an output schema means return value details are not needed, making this description 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?
Schema coverage is 100% (the one parameter 'coins' is fully described). The description adds value beyond the schema by explaining the maximum of 10 coins, the default (BTC and ETH), and the purpose of the parameter in the context of a basket sweep. Baseline 3 is exceeded due to this added context.
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 it performs a 'watchlist sweep' of up to 10 coins, returning headline funding and open interest figures aggregated across major venues. It explicitly distinguishes itself from the sibling `get_derivatives` by noting that tool provides per-venue detail, while this tool gives compact totals for comparison.
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 explicitly advises preferring this tool over repeated single-coin calls because it costs a single upstream call regardless of coin count. It also provides a clear alternative: 'Reach for get_derivatives instead when you need the per-venue detail on one coin.' Additionally, it explains that coins with missing data are listed as 'unavailable' rather than failing, guiding the agent on expected behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scheduled macro events (CPI, PCE, NFP / Employment Situation, GDP, Retail Sales, FOMC) from the official US release calendar. Call for upcoming economic catalysts. Returns the scheduled date and indicator, not analyst consensus.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days ahead to cover, defaults to 14 |
| Name | Required | Description |
|---|---|---|
| result | Yes | Scheduled macro releases ahead, soonest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value beyond these by specifying the data source (official US release calendar) and clarifying that it returns 'scheduled date and indicator, not analyst consensus.' No contradictions with annotations.
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 extremely concise: two sentences, front-loaded with examples, and no redundant information. Every word serves a purpose, earning its place.
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 optional parameter, existing output schema, rich annotations), the description fully covers what the agent needs to know: what events are returned, what is not returned (consensus), and the source. No gaps remain.
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?
Schema coverage is 100% for the single 'days' parameter, which already has a clear description. The tool description does not add additional meaning or constraints beyond what the schema provides, so 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 returns scheduled macro events from the official US release calendar, listing specific indicators (CPI, PCE, NFP, GDP, etc.). It distinguishes itself from sibling tools which are mostly crypto-focused, making the purpose unambiguous.
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 explicitly says 'Call for upcoming economic catalysts,' providing clear usage context. It lacks explicit when-not-to-use or alternative guidance, but given the sibling set, this is the only macro calendar tool, so the usage is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ethereum address activity: ETH balance plus recent large transfers in and out. Call when a specific wallet or exchange address is named and needs to be tracked.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Ethereum address (0x...) |
| Name | Required | Description |
|---|---|---|
| address | Yes | |
| balanceEth | Yes | |
| recentLargeTransfers | Yes | Transfers above 1 ETH, newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds value by specifying the output includes balance and large transfers, which is beyond what annotations convey.
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: one clearly defines the tool's output, the other gives usage guidance. No wasted words, front-loaded with the purpose.
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?
With an output schema present, the description does not need to explain return values. It covers the tool's purpose, usage context, and key output fields. Minor gap: no mention of any limitations, but adequate for a simple 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?
Schema description coverage is 100% for the single parameter. The description does not add additional meaning beyond what the schema already provides ('Ethereum address (0x...)'), so 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 it retrieves Ethereum address activity with ETH balance and recent large transfers. It distinguishes from siblings like get_eth_whale_flows by specifying a single wallet or exchange address, and the usage guidance reinforces this.
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 explicitly says 'Call when a specific wallet or exchange address is named and needs to be tracked,' providing clear context. It does not mention when not to use or alternatives, but the specificity is sufficient for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Large ETH transfers (>100 ETH) to and from live exchange hot wallets (Binance, Coinbase, Bitfinex) in the last 2 hours. Inflows to exchanges suggest potential selling pressure, outflows suggest accumulation. Call for smart-money signals and exchange flows. Wallets that could not be read are listed under "unavailable" rather than dropped, so an empty result is never mistaken for a quiet market. The response also states how far back each wallet could actually be read: the busiest exchange wallets produce thousands of transfers an hour, and a tool that silently sees only the last few minutes of one reports calm that was never measured.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| flows | Yes | Large ETH transfers to and from known exchange wallets, largest first. |
| coverage | Yes | How much of that window each wallet could actually be read back over. A busy wallet can exhaust one page before reaching the far end. |
| unavailable | Yes | Exchange wallets that could not be read. An empty flows list with entries here means nothing was read, not that nothing moved. |
| windowMinutes | Yes | The window asked for, in minutes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description reveals crucial behavioral details: the threshold for transfers, the interpretation of inflows/outflows, the 'unavailable' wallet handling to avoid false empty results, and the honest disclosure of read-depth limitations. This goes far beyond the annotations.
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 concise yet rich, with every sentence adding value. It is front-loaded with the core function, followed by interpretation guidance, and a critical caveat about data coverage. No word is wasted, and the structure supports quick comprehension.
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 tool, the description covers the data scope, interpretation, edge cases, and measurement limitations. The output schema exists but need not be repeated. It is complete and self-sufficient for an agent to select and invoke correctly.
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, so the baseline is 4. The description adds meaningful context about the data returned and its interpretation, but since there are no parameters to explain, this score 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 a specific verb and resource: it reports large ETH transfers (>100 ETH) to and from exchange hot wallets. It distinguishes itself from sibling tools by specifying the ETH exchange flow focus and the 2-hour window, making its unique purpose unmistakable.
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 explicitly says 'Call for smart-money signals and exchange flows,' providing a direct usage context. It does not name alternatives or state when not to use, but the clear purpose and context are sufficient for guiding an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a given trade size actually costs to execute right now, walked through the live order books of Bybit and OKX. Every other tool here reports where price is; this one reports the price YOU would get at YOUR size. Returns, per requested notional and separately for buying and selling: the average fill price, slippage against mid in basis points AND in dollars, the spread, the depth sitting within 1% of mid, and which venue is cheapest for that size. The floor is half the spread; anything above it is the size eating through levels. A size the book cannot absorb comes back as "filled": false with the amount that could actually be filled, never an extrapolated price. This is the number that decides whether a correct thesis still makes money after costs.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | Coin symbol, e.g. "BTC", "ETH", "SOL". The USDT perpetual is read. | |
| sizesUsd | No | Trade sizes to price, in US dollars. Defaults to 10000, 50000 and 250000. At most five. |
| Name | Required | Description |
|---|---|---|
| coin | Yes | |
| venues | Yes | |
| bandPct | No | Half-width of the depth band around mid, in percent. |
| cheapest | Yes | Per requested size, the venue with the lowest slippage among those that can fill it. |
| sizesUsd | Yes | |
| unavailable | Yes | Venues with no usable book for this coin. Never dropped silently. |
| unavailableDetail | No | The same venues with the reason each one failed, so a missing venue is diagnosable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotations, the description reveals how the tool handles insufficient liquidity: 'A size the book cannot absorb comes back as "filled": false with the amount that could actually be filled, never an extrapolated price.' It also explains the interpretation of slippage: 'The floor is half the spread; anything above it is the size eating through levels.' These are behavioral details not present in structured annotations.
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 a bit longer than typical but each sentence serves a purpose: first sentence states the core function, second differentiates from siblings, subsequent sentences explain output and edge-case behavior. It is front-loaded with the most important information and the additional detail is justified for a tool with non-obvious behavior, though some editorializing ('This is the number that decides...') could be trimmed.
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 complexity of the tool and the presence of a full output schema and annotations, the description provides crucial context not captured elsewhere: the venue comparison, behavior when the book cannot absorb size, and the interpretation of slippage as spread plus crossing levels. This makes the tool's behavior clear and complete for an agent to know when and how to invoke it.
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 already provides full descriptions for both coin and sizesUsd (100% coverage), so the tool description doesn't add parameter-level semantics beyond what the schema contains. It does reinforce that sizesUsd is 'per requested notional' but this matches the schema's 'Trade sizes to price, in US dollars.' Baseline of 3 is appropriate since the schema carries the parameter documentation burden.
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 computes actual execution cost for a given trade size by walking live order books of Bybit and OKX. It explicitly distinguishes from siblings: 'Every other tool here reports where price is; this one reports the price YOU would get at YOUR size.' This is a specific verb+resource with clear sibling differentiation.
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 explicitly contrasts with sibling tools: 'Every other tool here reports where price is; this one reports the price YOU would get at YOUR size.' It also explains when the metric matters: 'This is the number that decides whether a correct thesis still makes money after costs.' This provides clear context for when to use the tool, even without naming specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crypto Fear & Greed Index: current and previous value plus classification (Extreme Fear to Extreme Greed), with recent history. Best used as a contrarian sentiment signal, not on its own.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| value | Yes | 0-100. Low is fear, high is greed. |
| history | Yes | |
| previousValue | No | |
| classification | Yes | |
| previousClassification | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states the tool retrieves historical data ('recent history'), complements the readOnlyHint and idempotentHint annotations by confirming read behavior. While not strictly necessary to call out, it accurately describes the output without contradictions.
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 extremely concise—two sentences with no wasted words. All critical information (what, what format, when to use) is front-loaded and efficiently communicated.
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?
The description is complete for this tool: it describes the output (current/previous value, classification, recent history), provides usage context (contrarian sentiment signal), and clarifies limitations (not standalone). The output schema presumably documents return fields, so no additional return-value explanation is needed.
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 input schema has zero parameters, so the description correctly adds no additional parameter semantics. The baseline of 3 is appropriate since there is no parameter information to supplement.
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 retrieves the Crypto Fear & Greed Index, including current/previous values, classification, and recent history. It effectively distinguishes itself from sibling tools by specifying the specific index it retrieves.
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 provides clear guidance on when to use the tool ('best used as a contrarian sentiment signal') and explicitly advises against relying on it in isolation ('not on its own'). This directly helps an AI agent decide when to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How far the market EXPECTS price to move, priced off options (the DVOL index). Every other derivatives tool here describes how the market is POSITIONED; this one prices how expensive protection is. Returns the current 30-day implied volatility, annualized, in PERCENT (34.95 means 34.95%), together with its min, median, max and PERCENTILE over the window — an IV of 35% says nothing alone, but at the 5th percentile of the last month it says optionality is cheap and the market is complacent. Also returns the derived expected move (plus or minus percent over 1, 7 and 30 days), which scales with the square root of time, not linearly: dividing annualized IV by 365 instead of by the root understates a one-day move roughly nineteenfold. Distinct from the VIX reported by get_macro_rates, which is US equity volatility, not crypto. Published for BTC and ETH only; any other coin comes back under "unavailable" rather than failing the request.
| Name | Required | Description | Default |
|---|---|---|---|
| coins | No | Coins, e.g. ["BTC","ETH"]. Defaults to both. Only BTC and ETH have a published index. | |
| windowDays | No | How many days the percentile distribution covers. Defaults to 30, maximum 365. |
| Name | Required | Description |
|---|---|---|
| coins | Yes | |
| windowDays | Yes | |
| unavailable | Yes | Requested coins with no published volatility index. Never silently dropped. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, establishing a safe read-only profile. The description adds valuable behavioral context: the index source (DVOL), the interpretation of percentile context, the square-root-of-time scaling for expected moves, and the fallback behavior for unsupported coins. There is no contradiction with annotations.
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 front-loaded with the core purpose and has a logical flow: purpose → outputs → interpretation caveats → sibling differentiation → constraints. However, it is somewhat verbose, especially the detailed square-root-of-time explanation and the example about percentiles. While this adds educational value, it makes the description longer than strictly necessary for tool selection. Still, it remains well-structured and informative.
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 that an output schema exists (indicated true), the description does not need to detail the return format. It adequately covers the tool's outputs (30-day IV, percentile stats, expected moves), explains critical interpretation points (annualized percent, percentile context, time scaling), and handles edge cases (unsupported coins). The agent can fully understand the tool's role and behavior without additional context.
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?
Schema coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema by clarifying that the 'coins' parameter only works for BTC/ETH and that other values result in an 'unavailable' response rather than an error. While it doesn't elaborate on windowDays beyond what the schema says, this additional behavioral detail for the coins parameter is valuable and justifies a score of 4.
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 it returns options-implied volatility (DVOL index) and expected moves, using specific verbs ('prices how expensive protection is'). It explicitly distinguishes itself from sibling derivatives tools that describe market positioning and from get_macro_rates (VIX for US equities). The purpose is unambiguous and specific.
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 explicitly tells when to use this tool (to get crypto implied volatility) and when not: 'Every other derivatives tool here describes how the market is POSITIONED; this one prices how expensive protection is.' It contrasts with get_macro_rates for VIX and notes that only BTC and ETH are supported, with non-supported coins returning 'unavailable' rather than failing. No alternative usage guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live US macro data with the derived signals, not just the raw levels: Fed funds rate, 2Y and 10Y Treasury yields plus the 2s10s YIELD CURVE SPREAD (with its direction — steepening or flattening — and an inverted flag), CPI inflation year-over-year, the broad trade-weighted dollar index (a different index from the ICE dollar index, so read its direction rather than comparing its level), VIX and M2 money supply. Every series carries its previous reading, so direction is available without a second call. The curve slope, not the level of any single yield, is the liquidity and cycle signal: inversion has preceded every US recession, and re-steepening out of an inversion usually marks the start of easing — the moment that matters for risk assets. VIX explains crypto drawdowns that have no crypto-native cause.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| m2 | No | |
| vix | No | |
| ust2y | No | |
| cpiYoY | No | |
| ust10y | No | |
| fedFunds | No | |
| dollarIndex | No | |
| yieldCurve2s10s | No | 10Y minus 2Y. Inversion has preceded every recent US recession. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive. The description adds context about derived signals (yield curve spread, VIX explanation) which aids understanding of the data's meaning and behavior, going beyond the raw annotations.
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 verbose and somewhat redundant, repeating the 'derived signals' concept and elaborating on the yield curve and VIX details. It could be more concise while retaining key information.
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 no parameters and no output schema, the description effectively lists the data points returned and explains their relevance. It is sufficiently complete for a read-only data fetch tool, though it omits potential error or edge-case details.
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, so there is nothing to explain. The description provides no parameter info, but that is appropriate since none exist; the baseline for 0 params is 4.
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 it provides live US macro data with derived signals (Fed funds rate, yields, CPI, dollar index, VIX, M2). It distinguishes from sibling get_* tools by focusing on macro rates, which is a unique topic.
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?
No explicit guidance on when to use this tool over alternatives, though the distinct subject matter makes it implicitly obvious. It lacks a direct 'use this for macro data' or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The verdict in one call, not the ingredients. Composes positioning (funding and open interest with their percentiles), sentiment, implied volatility, the macro regime and the cost of execution into a single stance — risk-on, risk-off, fragile or neutral — with a confidence level, the signals that produced it and what would invalidate it. The rules are DETERMINISTIC, not a model opinion: the same numbers always give the same verdict, and every driver is returned with its value and its reading, so any part of it can be argued with rather than taken on faith. "Fragile" is a state rather than a direction: crowded positioning TOGETHER WITH cheap implied volatility, meaning the market is leaning one way and paying almost nothing for protection. A source that fails lowers confidence and is named under "missing" instead of being counted as a neutral zero. Percentile context exists only for BTC; for other coins the level is reported without the crowded label.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Coin, e.g. "BTC" (default), "ETH", "SOL". | |
| sizeUsd | No | Trade size the execution cost is measured at, in US dollars. Defaults to 100000. |
| Name | Required | Description |
|---|---|---|
| asOf | Yes | ISO timestamp the brief was computed at. |
| coin | Yes | |
| stance | Yes | fragile is a state, not a direction: crowded positioning together with cheap implied volatility. |
| drivers | Yes | Every signal that fed the verdict, so it can be argued with instead of taken on faith. |
| missing | Yes | Sources that did not answer. A missing signal is never counted as a neutral one. |
| verdict | Yes | The read in one or two sentences. |
| tradeable | No | null when no venue could be read. |
| confidence | Yes | |
| invalidation | Yes | Concrete, numeric conditions that would make this verdict wrong. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses deterministic behavior, explains the 'fragile' state condition, and how missing data is handled (lowers confidence and names missing sources). This goes beyond the readOnly/idempotent annotations and provides valuable behavioral insight.
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 somewhat lengthy but each sentence adds meaningful nuance about the tool's deterministic nature and edge cases. It is well-organized and front-loaded with the core purpose, avoiding unnecessary filler.
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?
The description fully explains what the tool outputs (stance, confidence, signals, invalidation criteria) and covers important edge cases like missing sources and percentile handling for BTC vs. other coins. Even without an explicit output schema, the description is sufficiently complete for an agent to understand the tool's behavior.
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?
Schema coverage is 100% (both coin and sizeUsd are described directly in the input schema). The description does not add additional parameter-specific explanation, but the schema descriptions are already clear, so the baseline of 3 applies.
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 that the tool produces a market brief with a consolidated stance (risk-on/off/fragile/neutral) and supporting signals. It explicitly differentiates itself from sibling tools by emphasizing it provides a 'verdict' rather than raw 'ingredients'.
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 when to use it—when a single high-level summary is needed instead of detailed data—and contrasts with 'ingredients' which suggests alternatives. However, it does not explicitly name sibling tools or provide explicit when-to-use/when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crypto market dominance: BTC.D, ETH.D and USDT.D as a percentage of total crypto market cap. Use as a regime filter (risk-on/off) and a BTC vs altcoin rotation signal.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| btcDominance | No | |
| ethDominance | No | |
| usdtDominance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, fully covering the safety profile. The description adds context about the return format (percentages) and intended use, but does not disclose additional behavioral traits like data freshness or update frequency. With annotations carrying the main burden, the description provides adequate but not extra transparency.
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, front-loaded with the primary output definition and followed by usage guidance. Every sentence adds value, with no redundancy or fluff.
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 no parameters, the presence of an output schema, and annotations covering safety, the description is complete. It explains what the tool returns, how to interpret it, and when to use it. No additional information is needed for correct invocation.
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?
There are zero parameters and schema description coverage is 100%. The description does not need to explain parameter semantics. Baseline for 0 parameters is 4, and the description meets this without adding unnecessary information.
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 states the tool returns crypto market dominance metrics (BTC.D, ETH.D, USDT.D) as percentages of total market cap. This clearly distinguishes it from sibling tools like get_crypto_market (overall market data) and get_fear_greed (sentiment), which serve different purposes.
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 provides explicit usage guidance: 'Use as a regime filter (risk-on/off) and a BTC vs altcoin rotation signal.' This tells the agent when to invoke this tool, though it does not explicitly exclude alternatives or list sibling tools for comparison. The context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where the current reading sits in its own recent distribution, from a series captured every ~10 minutes: funding, open interest, Fear & Greed and BTC dominance, each as current, median, min, max and percentile over the window. This is the one question a snapshot cannot answer — "is funding high right now?" has no absolute answer, only one relative to where it has been. A percentile near 0 means the reading is at the low end of the window, near 100 the high end. Check "samples" before trusting the percentile: a window with few measurements is not a distribution. Window defaults to 24 hours, maximum 168. Funding is in percent per 8 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | How many hours back the window covers. Defaults to 24, maximum 168. |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| from | Yes | |
| funding | No | Current reading placed in its own distribution over the window. |
| samples | Yes | Snapshots in the window, captured every ~10 minutes. |
| fearGreed | No | Current reading placed in its own distribution over the window. |
| windowHours | Yes | |
| btcDominance | No | Current reading placed in its own distribution over the window. |
| openInterestUsd | No | Current reading placed in its own distribution over the window. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations clearly mark the tool as readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds volatility context (data captured every ~10 minutes, window defaults to 24 hours, max 168) and cautions about sample size. However, it does not explain if the percentile is historical real-time or adjusted, nor how funding percent per 8 hours is computed. Still, annotations suffice for safety, and description adds useful nuances.
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 compact yet fully informative, front-loading the core purpose and then detailing metrics, utility, and caveats. Every sentence serves a clear function, and nothing is extraneous.
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 1 parameter, complete schema/annotations, and no nested objects, the description covers all key aspects: what it does, how to interpret results, and limitations (samples check). However, the output schema exists but isn't referenced; the description could benefit from a brief note on returned fields beyond percentiles. Still, it's nearly complete for the complexity level.
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?
Schema coverage is 100% and the description effectively repeats the only parameter ('hours') with defaults and maximums, matching the schema's description exactly. No additional meaning or formatting details are added beyond what the schema provides. 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 this tool computes where current readings sit in their recent distribution for funding, open interest, Fear & Greed, and BTC dominance. The verb 'sits' and resource 'recent distribution' are specific and differentiated from siblings; no other tool seems to provide historical percentiles over a sliding window.
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 explicitly states this is for relative context (e.g., 'is funding high right now?'), directly contrasting with a snapshot. It tells the agent to check 'samples' before trusting the percentile and specifies volatility-like behavior. No exclusion or alternative tools are named, but the uniqueness of the question justifies the tool's use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 parameters | |||
| Name | Required | Description |
|---|---|---|
| quotes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value by specifying the ETFs covered, the macro context, and the interpretation guidance (use direction/percent change). This goes beyond the annotations without contradicting them.
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 consists of three concise, front-loaded sentences. The first states what the tool provides, the second adds macro context, and the third gives practical usage guidance. Every sentence contributes essential information without redundancy.
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 no parameters and an output schema exists, the description adequately covers what the tool does and how to interpret its results. It names the specific ETFs and the correlation context, which is complete for the intended use. It could optionally list alternatives, but this is not essential.
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 no parameters, and schema coverage is 100% trivially. Per rubric baseline for 0 parameters is 4. The description does not need to add parameter details, and it appropriately explains the meaning of the returned data (live quotes, USD per share, direction and percent change).
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 that the tool provides live quotes for three specific ETFs (SPY, GLD, QQQ) and macro context for risk assessment. It explicitly names the resources and distinguishes itself from crypto-focused tools by mentioning traditional markets and correlation with crypto.
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 traditional market quotes and macro context relevant to crypto traders. It tells the user to focus on direction and percent change because the ETFs are priced in USD per share. However, it does not explicitly mention when not to use it or name direct alternatives like get_crypto_market.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_marketget_btc_networkget_crypto_marketget_crypto_newsget_defi_overviewget_derivativesget_derivatives_aggregateget_economic_calendarget_eth_addressget_eth_whale_flowsget_execution_costget_fear_greedget_implied_volatilityget_macro_ratesget_market_briefget_market_dominanceget_market_historyget_market_quotes
Add one secure layer between your agents and this server.