Crypto positioning and macro intelligence for agents — the signal set a trading desk watches, delivered as structured JSON. Multi-venue perpetual funding and open interest across Binance, Bybit and OKX (largest-open-interest perp per venue, thin venues excluded), Ethereum exchange whale flows, Bitcoin network health, DeFi TVL and stablecoin supply, Fear & Greed, and BTC/ETH/USDT dominance as a risk-on/risk-off regime filter. Plus the macro backdrop that actually drives crypto: Fed funds rate, 2Y
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 readOnly, idempotent, and non-destructive behavior, but the description adds valuable context: the tool is 'live', and 'miner revenue is null when the source stops publishing it, never a misleading zero.' This discloses edge-case behavior directly and prevents misinterpretation of missing data.
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 all key facts front-loaded in the first sentence. It lists specific metrics concisely and adds one crucial edge-case note in the second sentence. Every word earns its place, and there is no redundant 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 the tool has no parameters, an output schema exists, and the description enumerates the major fields returned, the information provided is complete for effective use. The description also adds the live nature and null-handling behavior, so there are no obvious gaps in understanding.
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 description coverage is 100%, so there are no parameter semantics to clarify. The description sensibly names the data fields returned, but for a no-param tool, the baseline of 4 is appropriate since there is nothing beyond the schema to explain.
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 resource ('Bitcoin network health') and provides a specific list of components (hashrate, difficulty, transaction count, estimated volume, miner revenue, largest recent mempool transactions). The instruction 'Call for on-chain Bitcoin activity' explicitly differentiates it from sibling tools like get_crypto_market or get_market_quotes, establishing a clear verb and scope.
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 phrase 'Call for on-chain Bitcoin activity' provides clear context for when to use this tool, implying it should be selected when on-chain metrics are needed rather than market or derivatives data. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full explicit guidance.
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 | Yes | 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 provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which cover safety traits. The description adds context on what data is returned (spot price, market cap, etc.) but doesn't disclose response size limits, rate limits, or handling of invalid coin IDs. The description aligns with annotations (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?
Two sentences, effectively front-loaded with purpose and examples. The only minor critique is the phrase 'Live crypto prices and market data' slightly redundant with the examples that follow, but overall very concise.
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 output schema exists, the description adequately covers what the tool returns. For a data retrieval tool with 2 parameters, it provides sufficient context. The only gap is lack of guidance on how to handle invalid coin IDs or pagination if many coins are requested.
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%, so baseline is 3. The description adds no additional parameter semantics beyond what the schema provides for ids and vs_currency.
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 provides 'live crypto prices and market data' including specific metrics (spot price, market cap, 24h volume and change). It names example coins and explicitly states the use case: 'Call for any price, market cap or volume question.' This fully distinguishes it from siblings like get_crypto_news or get_defi_overview.
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 strong contextual guidance by listing when to call (any price/market cap/volume question) and implicitly distinguishes from siblings by focusing on current market data. However, it does not explicitly state when to avoid this tool or mention alternatives like get_market_history for historical data.
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, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: it explains the units (funding as percent per 8 hours and annualized, OI in USD), the error condition for coins without major-venue data, and confirms it's a current snapshot. 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 approximately 100 words, well-structured with the primary purpose front-loaded. Every sentence contributes essential information—venue list, data returned, usage guidance, units, error handling. 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?
Given the tool has an output schema (not shown), the description appropriately omits return value details. It covers input requirements, behavioral constraints, error conditions, and usage rationale. It is fully complete for a read-only data retrieval 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 the single parameter 'symbol' with description. The description adds concrete examples (BTC, BTCUSDT, ETH) and clarifies that only one coin is accepted. This provides useful context beyond the schema definition.
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 a venue-by-venue breakdown of funding and open interest for a single coin from major venues (Binance, Bybit, OKX, Hyperliquid). It specifies the exact data returned (per-venue rows, averages, total OI, funding spread) and distinguishes itself from the sibling tool get_derivatives_aggregate by noting it handles one coin only.
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 tells the agent when to use this tool: 'Reach for this when divergence between venues matters' and when to use the alternative: 'to sweep several at once, call get_derivatives_aggregate'. This provides clear context for decision-making.
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 declare readOnly, openWorld, idempotent, and non-destructive, and the description adds valuable context beyond these: venue selection (major liquid venues only), fallback behavior (coins listed in 'unavailable' instead of failing), and unit conventions (funding in percent per 8h and annualized). 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 internally structured and front-loaded: purpose, efficiency, data-source rationale, fallback behavior, sibling distinction, and unit clarification. Every sentence earns its place, including the concrete annualization example, making it informative without waste.
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 moderate complexity and the presence of an output schema, the description covers all key aspects: data sources, units, fallback behavior, and the distinction from get_derivatives. It explains return values enough ('unavailable' list, aggregate figures) and notes 'Current snapshot' for time sensitivity.
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 fully describes the only parameter (coins) with max 10 and defaults, so the baseline is 3. The description adds little beyond schema, only implying the output groups by coin. It does not introduce new parameter constraints or format details.
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 'headline funding and open interest figures per coin' for up to 10 coins, with specific components (average funding, total OI, funding spread). It explicitly differentiates from sibling get_derivatives by noting 'no per-venue rows' and directing users to the sibling for detail.
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?
Explicit guidance is given: 'Costs a single upstream call... so prefer it over repeated single-coin calls' and 'Reach for get_derivatives instead when you need the per-venue detail on one coin.' This clearly states when to use this tool and when to use an alternative.
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, idempotentHint, and destructiveHint, so the description's burden is lower. It adds behavioral context by stating the return includes scheduled date and indicator (not consensus), which is useful but does not disclose data freshness or scope limitations beyond 'US release calendar.'
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 at two sentences, front-loading the key events list and purpose. Every clause adds value, though the structure could be slightly improved by separating the return type more explicitly from the usage guidance.
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 simple tool with one optional parameter and an output schema, the description covers its core purpose, input range, and what it returns (scheduled date and indicator). It explicitly notes it does not return consensus, which is helpful. Missing a brief note on data source limitations (US-only) is a minor gap.
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 single parameter 'days' is well-described in the schema with default and purpose. The description adds no additional semantic information about the parameter, meeting the baseline but not exceeding it.
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 scheduled macro events (CPI, PCE, NFP, GDP, Retail Sales, FOMC) from the official US release calendar. It provides specific examples and distinguishes from sibling tools like get_macro_rates by focusing on event dates rather than rate data.
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 advises calling for 'upcoming economic catalysts,' giving clear context for when to use the tool. However, it does not mention when not to use it or explicitly compare to siblings like get_macro_rates, leaving some situational guidance implicit.
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful output context (ETH balance plus transfers) but does not disclose limits like 'recent' definition or pagination. With annotations present, the description provides reasonable additional 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, front-loaded with the core function and followed by an explicit use case. Every word earns its place with no 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?
For a simple single-address lookup tool with an output schema, the description covers the essentials: what it returns, when to call it, and the input. It doesn't define 'recent' but the output schema likely clarifies the response. Overall, it is complete enough for an agent to select and invoke it 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 input schema covers 100% of parameters with 'address' described as 'Ethereum address (0x...)'. The description does not add extra parameter semantics beyond that, but since schema coverage is complete, the baseline score of 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 function: 'Ethereum address activity: ETH balance plus recent large transfers in and out.' It is specific about the resource (Ethereum address) and distinguishes it from siblings like get_eth_whale_flows by focusing on individual address tracking rather than aggregate flows.
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 guidance on when to use the tool: 'Call when a specific wallet or exchange address is named and needs to be tracked.' This gives clear context, though it does not explicitly mention alternatives or when not to use it.
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, the description discloses extensive behavioral details: it walks through live order books, defines the floor as half the spread, and explains that if a size cannot be absorbed, it returns 'filled': false with the actual fillable amount instead of an extrapolated price. 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 well-structured and front-loaded with the core purpose, then differentiates from siblings, summarizes the output, covers an edge case, and states its decision-making value. Every sentence earns its place despite the length.
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 tool of this complexity, the description is remarkably complete. It covers behavior, outputs, venue comparison, and failure handling. The output schema provides return-value structure, and annotations cover safety, so no significant 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 descriptions for both coin and sizesUsd. The tool description adds context about output (per requested notional, buying/selling) but does not materially change the meaning of the parameters themselves, 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 identifies the tool as reporting execution cost for a given trade size using live order books from Bybit and OKX. It explicitly distinguishes this from siblings: 'Every other tool here reports where price is; this one reports the price YOU would get at YOUR size.'
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 this tool with all others, making it clear when to use it: when the agent needs cost-at-size rather than just a price quote. It reinforces the use case by stating 'This is the number that decides whether a correct thesis still makes money after costs.'
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the description has less burden. It adds value by explaining the qualitative classification (Extreme Fear to Extreme Greed) and that it includes recent history, which are useful 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 with no redundancy. The first sentence front-loads the core purpose and return values, and the second adds usage guidance. Every sentence is necessary and earns 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 has zero parameters, comprehensive annotations, and an output schema (mentioned in context), the description is complete. It covers purpose, return content, and usage context without requiring additional 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?
With 0 parameters and 100% schema coverage, the baseline is 4. The description adds no parameter info, but none is needed. It correctly describes what the tool returns without parameter details.
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 verb 'get' and resource 'Fear & Greed Index', specifies what it returns (current and previous value, classification, recent history), and distinguishes it from sibling tools like get_market_quotes or get_market_history by focusing on sentiment rather than price or network data.
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 using it as a 'contrarian sentiment signal' and cautions 'not on its own', providing clear context for when to apply it. However, it does not explicitly mention when not to use it or name specific alternatives among the sibling tools.
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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds significant behavioral context: return format (annualized IV in PERCENT, plus min/median/max/percentile), interpretation guidance (IV alone is meaningless without percentile), derivation of expected moves with time scaling warning, and error behavior for unsupported coins. 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 well-structured: core purpose first, then differentiation from siblings, then detailed output explanation with interpretation, and finally an important mathematical warning about time scaling. Every sentence adds value without redundancy. It is informative yet concisely worded.
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 moderate complexity, presence of an output schema, and rich annotations, the description is remarkably complete. It covers purpose, usage context, output interpretation, edge cases (unavailable coins), and a subtle mathematical pitfall. The agent has enough context to correctly invoke and interpret the 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 coverage is 100% with both parameters already described in the input schema (coins: defaults, only BTC/ETH supported; windowDays: default 30, max 365). The description repeats these details but adds no new parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate because the schema does the heavy lifting.
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) for BTC/ETH, with a specific verb and resource. It distinguishes itself from sibling tools by noting that other derivatives tools describe positioning, while this one prices protection cost. Also explicitly distinguishes from get_macro_rates (US equity volatility).
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 gives explicit guidance on when to use this tool: to assess how expensive protection is (implied volatility), contrasting with positioning tools. It explicitly names the sibling get_macro_rates as an alternative for US equity volatility. It limits usage to BTC and ETH and explains behavior for other coins.
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 declare readOnly, idempotent, etc., which covers safety. The description adds that every series carries previous reading for direction, and explains the significance of the curve slope and VIX, but doesn't detail computational methods or potential side effects (none expected). 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 quite verbose and repetitive (e.g., the 'curve slope' and 'VIX' explanations are repeated). Could be condensed significantly. The structure is a single block, but the redundancy hurts conciseness.
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 (no params), the description covers the main outputs and their significance. It explains the derived signals and why they matter, which is sufficient for context. Slight redundancy, but 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?
No parameters exist, so the description's lack of param details is acceptable. But since there are no params, the baseline of 4 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 provides live US macro data and derived signals (e.g., Fed funds rate, Treasury yields, 2s10s spread, CPI, dollar index, VIX, M2), distinguishing it from other market tools. It is specific and action-oriented.
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 explains that the tool includes derived signals (spread, inverted flag, direction) and clarifies that it differs from the ICE dollar index, implying when to use it (for macro context). However, it does not explicitly state when not to use other tools, though the contrast with sibling tools is implicit.
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, and destructiveHint=false, so the description does not need to repeat those. The description adds value by explaining the interpretative context (regime filter, rotation signal) beyond the annotations, though it does not disclose additional behavioral traits like rate limits or data freshness.
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: first sentence states exactly what data is returned, second sentence gives usage guidance. Extremely concise, front-loaded with key information, and every sentence earns 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?
The tool has 0 parameters and an output schema exists, so the description need not explain return values. It fully captures the tool's purpose and usage context (dominance percentages for regime filter/rotation signal). 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?
There are 0 parameters, and schema coverage is 100% (trivially). The description does not need to explain parameters. The baseline for no parameters is 4, which is appropriate here.
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 'BTC.D, ETH.D and USDT.D as a percentage of total crypto market cap', using specific verbs (get) and resources (market dominance values). It clearly distinguishes from sibling tools like get_fear_greed or get_market_quotes by specifying the exact data elements and their purpose.
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 guidance: 'Use as a regime filter (risk-on/off) and a BTC vs altcoin rotation signal.' This tells the agent exactly when to invoke this tool versus alternatives like get_market_history for price data or get_fear_greed for sentiment.
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 already declare readOnlyHint and idempotentHint true, so the safe read behavior is clear. The description adds behavioral context: the sampling interval (~10 minutes), the metrics included, and the output fields (current, median, min, max, percentile). It also warns about insufficient samples, which is a key behavioral trait 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 and front-loaded with the core purpose. Every sentence adds value: it defines what the tool does, why it's useful, how to interpret output, and a caveat about sample size. 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?
Given there is an output schema (not shown but present), the description need not explain return values. The description fully covers the tool's purpose, input parameter, behavioral traits (sampling frequency, metrics), interpretation of output (percentile meaning), and a crucial warning about data reliability. This 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 input schema has 100% description coverage, explicitly documenting the single parameter 'hours' with defaults and maximum. The description reiterates this window behavior and adds the 168 maximum. Without param gaps, baseline 3 is appropriate; the description doesn't need to add much more for this simple parameter.
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 answers where a current reading (funding, open interest, Fear & Greed, BTC dominance) sits in its own recent distribution. It differentiates itself from siblings like get_fear_greed and get_market_dominance which likely provide raw or snapshot values, while this tool uniquely provides percentiles relative to a historical 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 explains when to use this tool: when you need to know if a reading is high or low relative to its history, stating 'the one question a snapshot cannot answer'. It also gives guidance on trusting the percentile by checking "samples" to avoid false conclusions from a small window, and specifies the window range (default 24 hours, max 168).
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. Dates show when Glama detected each change.
get_btc_network2 fields changedOutput schema / properties / minersRevenueUsd / descriptionAdded value: +"null when the source does not publish it. Never 0 - miner revenue cannot be zero while blocks are produced."Output schema / properties / minersRevenueUsd / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]get_eth_whale_flows6 fields changedOutput schema / properties / coverageAdded value: +{
+ "description": "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.",
+ "items": {
+ "properties": {
+ "exchange": {
+ "type": "string"
+ },
+ "minutesCovered": {
+ "type": "number"
+ },
+ "truncated": {
+ "description": "true means the wallet is too busy for a single page, so older transfers in the window were not seen.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "exchange",
+ "minutesCovered",
+ "truncated"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / flowsAdded value: +{
+ "description": "Large ETH transfers to and from known exchange wallets, largest first.",
+ "items": {
+ "properties": {
+ "counterparty": {
+ "description": "The non-exchange side of the transfer.",
+ "type": "string"
+ },
+ "direction": {
+ "description": "`in` is flow toward the exchange (distribution pressure), `out` is away.",
+ "enum": [
+ "in",
+ "out"
+ ],
+ "type": "string"
+ },
+ "exchange": {
+ "type": "string"
+ },
+ "hash": {
+ "type": "string"
+ },
+ "timestamp": {
+ "description": "Unix seconds.",
+ "type": "number"
+ },
+ "valueEth": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "exchange",
+ "valueEth",
+ "direction",
+ "timestamp",
+ "hash"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / resultRemoved value: -{
- "description": "Large ETH transfers to and from known exchange wallets, newest first.",
- "items": {
- "properties": {
- "counterparty": {
- "description": "The non-exchange side of the transfer.",
- "type": "string"
- },
- "direction": {
- "description": "`in` is flow toward the exchange (distribution pressure), `out` is away.",
- "enum": [
- "in",
- "out"
- ],
- "type": "string"
- },
- "exchange": {
- "type": "string"
- },
- "hash": {
- "type": "string"
- },
- "timestamp": {
- "description": "Unix seconds.",
- "type": "number"
- },
- "valueEth": {
- "type": "number"
- }
- },
- "required": [
- "exchange",
- "valueEth",
- "direction",
- "timestamp",
- "hash"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / unavailableAdded value: +{
+ "description": "Exchange wallets that could not be read. An empty flows list with entries here means nothing was read, not that nothing moved.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / windowMinutesAdded value: +{
+ "description": "The window asked for, in minutes.",
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "result"
-]New value: +[
+ "flows",
+ "windowMinutes",
+ "coverage",
+ "unavailable"
+]get_execution_cost1 field changedOutput schema / properties / unavailableDetailAdded value: +{
+ "description": "The same venues with the reason each one failed, so a missing venue is diagnosable.",
+ "items": {
+ "properties": {
+ "reason": {
+ "type": "string"
+ },
+ "venue": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "venue",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}get_market_briefget_execution_costget_implied_volatilityget_macro_rates8 fields changedOutput schema / properties / cpiYoY / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / dollarIndex / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / fedFunds / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / m2 / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / ust10y / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / ust2y / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / vix / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / yieldCurve2s10s / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]get_market_history24 fields changedOutput schema / properties / btcDominance / properties / current / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / btcDominance / properties / max / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / btcDominance / properties / median / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / btcDominance / properties / min / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / btcDominance / properties / percentile / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / btcDominance / properties / samplesAdded value: +{
+ "description": "How many measurements back these numbers. Lower than the window's total when the series has gaps — or, for open interest, when older readings came from a different set of venues and are therefore not comparable.",
+ "type": "number"
+}Output schema / properties / fearGreed / properties / current / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / fearGreed / properties / max / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / fearGreed / properties / median / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / fearGreed / properties / min / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / fearGreed / properties / percentile / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / fearGreed / properties / samplesAdded value: +{
+ "description": "How many measurements back these numbers. Lower than the window's total when the series has gaps — or, for open interest, when older readings came from a different set of venues and are therefore not comparable.",
+ "type": "number"
+}Output schema / properties / funding / properties / current / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / funding / properties / max / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / funding / properties / median / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / funding / properties / min / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / funding / properties / percentile / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / funding / properties / samplesAdded value: +{
+ "description": "How many measurements back these numbers. Lower than the window's total when the series has gaps — or, for open interest, when older readings came from a different set of venues and are therefore not comparable.",
+ "type": "number"
+}Output schema / properties / openInterestUsd / properties / current / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / openInterestUsd / properties / max / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / openInterestUsd / properties / median / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / openInterestUsd / properties / min / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / openInterestUsd / properties / percentile / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / openInterestUsd / properties / samplesAdded value: +{
+ "description": "How many measurements back these numbers. Lower than the window's total when the series has gaps — or, for open interest, when older readings came from a different set of venues and are therefore not comparable.",
+ "type": "number"
+}get_market_quotes5 fields changedOutput schema / properties / quotes / items / properties / change / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / quotes / items / properties / changePercent / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / quotes / items / properties / previousClose / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / quotes / items / properties / price / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / quotes / items / properties / time / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]get_derivatives2 fields changedOutput schema / properties / perExchange / items / properties / exchange / descriptionAdded value: +"Venue name. Hyperliquid is the only DEX in the set; its native hourly funding is already converted to the same percent-per-8h unit as the others."Output schema / properties / perExchange / items / properties / exchange / enumAdded value: +[
+ "Binance",
+ "Bybit",
+ "OKX",
+ "Hyperliquid"
+]get_btc_network1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "btcLargeMempool": {
+ "description": "Largest transactions currently waiting in the mempool.",
+ "items": {
+ "properties": {
+ "timestamp": {
+ "type": "number"
+ },
+ "totalBtc": {
+ "type": "number"
+ },
+ "txHash": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "txHash",
+ "totalBtc",
+ "timestamp"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "difficulty": {
+ "type": "number"
+ },
+ "estimatedTxVolumeUsd": {
+ "type": "number"
+ },
+ "hashRate": {
+ "type": "number"
+ },
+ "marketPrice": {
+ "type": "number"
+ },
+ "minersRevenueUsd": {
+ "type": "number"
+ },
+ "tradeVolumeUsd": {
+ "type": "number"
+ },
+ "txCount24h": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+}get_crypto_market1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "items": {
+ "properties": {
+ "change24h": {
+ "description": "Percent.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "change7d": {
+ "description": "Percent.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Coin id, e.g. `bitcoin`.",
+ "type": "string"
+ },
+ "marketCap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "price": {
+ "type": "number"
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "volume24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "symbol",
+ "name",
+ "price"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "type": "object"
+}get_crypto_news1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "description": "Recent headlines, newest first. Summaries are our own words, not article text.",
+ "items": {
+ "properties": {
+ "publishedAt": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "source",
+ "url",
+ "publishedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "type": "object"
+}get_defi_overview1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "stablecoinMarketCap": {
+ "description": "Dry powder waiting on the sidelines.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "topChains": {
+ "items": {
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "tvl": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "tvl"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalTvl": {
+ "description": "Total value locked across DeFi, in USD.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "totalTvl",
+ "topChains"
+ ],
+ "type": "object"
+}get_derivatives1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "avgFundingAnnualizedPct": {
+ "description": "The same funding as a yearly percentage, comparable to any other yield.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "avgFundingRate": {
+ "description": "Percent per 8 hours. 0.0067 means 0.0067%, not 0.67%.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "coin": {
+ "type": "string"
+ },
+ "exchangeCount": {
+ "description": "How many major venues backed the numbers.",
+ "type": "number"
+ },
+ "fundingSpread": {
+ "description": "Highest minus lowest venue funding. A wide spread marks localised positioning.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "perExchange": {
+ "description": "Per-venue breakdown, from each venue's largest-open-interest perpetual.",
+ "items": {
+ "properties": {
+ "exchange": {
+ "type": "string"
+ },
+ "fundingRate": {
+ "description": "Percent per 8 hours.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "openInterestUsd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "exchange"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalOpenInterestUsd": {
+ "description": "Summed across the major venues.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "coin",
+ "perExchange",
+ "exchangeCount"
+ ],
+ "type": "object"
+}get_derivatives_aggregate1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "coins": {
+ "items": {
+ "properties": {
+ "avgFundingAnnualizedPct": {
+ "description": "The same funding as a yearly percentage, comparable to any other yield.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "avgFundingRate": {
+ "description": "Percent per 8 hours. 0.0067 means 0.0067%, not 0.67%.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "coin": {
+ "type": "string"
+ },
+ "exchangeCount": {
+ "description": "How many major venues backed the numbers.",
+ "type": "number"
+ },
+ "fundingSpread": {
+ "description": "Highest minus lowest venue funding. A wide spread marks localised positioning.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "totalOpenInterestUsd": {
+ "description": "Summed across the major venues.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "coin",
+ "exchangeCount"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "unavailable": {
+ "description": "Requested coins with no major-venue perpetual. Never silently dropped.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "coins",
+ "unavailable"
+ ],
+ "type": "object"
+}get_economic_calendar1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "description": "Scheduled macro releases ahead, soonest first.",
+ "items": {
+ "properties": {
+ "actual": {
+ "description": "Null until the release lands.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "country": {
+ "type": "string"
+ },
+ "estimate": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "event": {
+ "type": "string"
+ },
+ "impact": {
+ "type": "string"
+ },
+ "previous": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "time": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "event",
+ "country",
+ "time",
+ "impact"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "type": "object"
+}get_eth_address1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "balanceEth": {
+ "type": "number"
+ },
+ "recentLargeTransfers": {
+ "description": "Transfers above 1 ETH, newest first.",
+ "items": {
+ "properties": {
+ "direction": {
+ "enum": [
+ "in",
+ "out"
+ ],
+ "type": "string"
+ },
+ "from": {
+ "type": "string"
+ },
+ "hash": {
+ "type": "string"
+ },
+ "timestamp": {
+ "description": "Unix seconds.",
+ "type": "number"
+ },
+ "to": {
+ "type": "string"
+ },
+ "valueEth": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "hash",
+ "from",
+ "to",
+ "valueEth",
+ "timestamp",
+ "direction"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "address",
+ "balanceEth",
+ "recentLargeTransfers"
+ ],
+ "type": "object"
+}get_eth_whale_flows1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "description": "Large ETH transfers to and from known exchange wallets, newest first.",
+ "items": {
+ "properties": {
+ "counterparty": {
+ "description": "The non-exchange side of the transfer.",
+ "type": "string"
+ },
+ "direction": {
+ "description": "`in` is flow toward the exchange (distribution pressure), `out` is away.",
+ "enum": [
+ "in",
+ "out"
+ ],
+ "type": "string"
+ },
+ "exchange": {
+ "type": "string"
+ },
+ "hash": {
+ "type": "string"
+ },
+ "timestamp": {
+ "description": "Unix seconds.",
+ "type": "number"
+ },
+ "valueEth": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "exchange",
+ "valueEth",
+ "direction",
+ "timestamp",
+ "hash"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "type": "object"
+}get_fear_greed1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "classification": {
+ "type": "string"
+ },
+ "history": {
+ "items": {
+ "properties": {
+ "time": {
+ "type": "number"
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "time",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "previousClassification": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "previousValue": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "description": "0-100. Low is fear, high is greed.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "value",
+ "classification",
+ "history"
+ ],
+ "type": "object"
+}get_macro_rates1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "cpiYoY": {
+ "properties": {
+ "date": {
+ "description": "ISO date of the observation.",
+ "type": "string"
+ },
+ "previous": {
+ "description": "Prior observation, for direction.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "value",
+ "date"
+ ],
+ "type": "object"
+ },
+ "dollarIndex": {
+ "properties": {
+ "date": {
+ "description": "ISO date of the observation.",
+ "type": "string"
+ },
+ "previous": {
+ "description": "Prior observation, for direction.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "value",
+ "date"
+ ],
+ "type": "object"
+ },
+ "fedFunds": {
+ "properties": {
+ "date": {
+ "description": "ISO date of the observation.",
+ "type": "string"
+ },
+ "previous": {
+ "description": "Prior observation, for direction.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "value",
+ "date"
+ ],
+ "type": "object"
+ },
+ "m2": {
+ "properties": {
+ "date": {
+ "description": "ISO date of the observation.",
+ "type": "string"
+ },
+ "previous": {
+ "description": "Prior observation, for direction.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "value",
+ "date"
+ ],
+ "type": "object"
+ },
+ "ust10y": {
+ "properties": {
+ "date": {
+ "description": "ISO date of the observation.",
+ "type": "string"
+ },
+ "previous": {
+ "description": "Prior observation, for direction.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "value",
+ "date"
+ ],
+ "type": "object"
+ },
+ "ust2y": {
+ "properties": {
+ "date": {
+ "description": "ISO date of the observation.",
+ "type": "string"
+ },
+ "previous": {
+ "description": "Prior observation, for direction.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "value",
+ "date"
+ ],
+ "type": "object"
+ },
+ "vix": {
+ "properties": {
+ "date": {
+ "description": "ISO date of the observation.",
+ "type": "string"
+ },
+ "previous": {
+ "description": "Prior observation, for direction.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "value",
+ "date"
+ ],
+ "type": "object"
+ },
+ "yieldCurve2s10s": {
+ "description": "10Y minus 2Y. Inversion has preceded every recent US recession.",
+ "properties": {
+ "direction": {
+ "enum": [
+ "steepening",
+ "flattening",
+ "flat",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "inverted": {
+ "type": "boolean"
+ },
+ "previous": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "value",
+ "inverted"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+}get_market_dominance1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "description": "Share of total crypto market cap, in percent.",
+ "properties": {
+ "btcDominance": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ethDominance": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "usdtDominance": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}get_market_history1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "btcDominance": {
+ "description": "Current reading placed in its own distribution over the window.",
+ "properties": {
+ "current": {
+ "type": "number"
+ },
+ "max": {
+ "type": "number"
+ },
+ "median": {
+ "type": "number"
+ },
+ "min": {
+ "type": "number"
+ },
+ "percentile": {
+ "description": "0-100. Where `current` sits among the samples.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "current",
+ "median",
+ "min",
+ "max",
+ "percentile"
+ ],
+ "type": "object"
+ },
+ "fearGreed": {
+ "description": "Current reading placed in its own distribution over the window.",
+ "properties": {
+ "current": {
+ "type": "number"
+ },
+ "max": {
+ "type": "number"
+ },
+ "median": {
+ "type": "number"
+ },
+ "min": {
+ "type": "number"
+ },
+ "percentile": {
+ "description": "0-100. Where `current` sits among the samples.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "current",
+ "median",
+ "min",
+ "max",
+ "percentile"
+ ],
+ "type": "object"
+ },
+ "from": {
+ "type": "string"
+ },
+ "funding": {
+ "description": "Current reading placed in its own distribution over the window.",
+ "properties": {
+ "current": {
+ "type": "number"
+ },
+ "max": {
+ "type": "number"
+ },
+ "median": {
+ "type": "number"
+ },
+ "min": {
+ "type": "number"
+ },
+ "percentile": {
+ "description": "0-100. Where `current` sits among the samples.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "current",
+ "median",
+ "min",
+ "max",
+ "percentile"
+ ],
+ "type": "object"
+ },
+ "openInterestUsd": {
+ "description": "Current reading placed in its own distribution over the window.",
+ "properties": {
+ "current": {
+ "type": "number"
+ },
+ "max": {
+ "type": "number"
+ },
+ "median": {
+ "type": "number"
+ },
+ "min": {
+ "type": "number"
+ },
+ "percentile": {
+ "description": "0-100. Where `current` sits among the samples.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "current",
+ "median",
+ "min",
+ "max",
+ "percentile"
+ ],
+ "type": "object"
+ },
+ "samples": {
+ "description": "Snapshots in the window, captured every ~10 minutes.",
+ "type": "number"
+ },
+ "to": {
+ "type": "string"
+ },
+ "windowHours": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "windowHours",
+ "samples",
+ "from",
+ "to"
+ ],
+ "type": "object"
+}get_market_quotes1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "quotes": {
+ "items": {
+ "properties": {
+ "change": {
+ "type": "number"
+ },
+ "changePercent": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "previousClose": {
+ "type": "number"
+ },
+ "price": {
+ "type": "number"
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "time": {
+ "description": "Unix seconds.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "symbol",
+ "name",
+ "price"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "quotes"
+ ],
+ "type": "object"
+}get_market_historyget_derivatives_aggregate2 fields changedInput schema / properties / coinRemoved value: -{
- "description": "Base coin, e.g. BTC, ETH (quote defaults to USDT)",
- "type": "string"
-}Input schema / properties / coinsAdded value: +{
+ "description": "Base coins, e.g. [\"BTC\",\"ETH\",\"SOL\"]. Maximum 10. Defaults to BTC and ETH.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}get_btc_networkget_crypto_marketget_crypto_newsget_defi_overviewget_derivativesget_derivatives_aggregateget_economic_calendarget_eth_addressget_eth_whale_flowsget_fear_greedget_macro_ratesget_market_dominanceget_market_quotesClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool targets a distinct data domain—network health, market prices, news, DeFi, derivatives per-venue vs aggregate, economic calendar, ETH address, whale flows, execution cost, sentiment, implied volatility, macro rates, market brief, dominance, history, and traditional market quotes. The only similar pair (get_derivatives vs get_derivatives_aggregate) is clearly differentiated by level of detail, so there is no real ambiguity.
All tools follow the get_<domain> pattern with descriptive noun phrases (e.g., get_btc_network, get_eth_whale_flows, get_market_brief). No mixed verb styles or casing conventions appear, making the naming fully predictable and consistent.
At 17 tools, the surface is slightly above the ideal 3-15 range, but the breadth of the domain—spot, derivatives, on-chain, macro, sentiment, and execution—justifies each tool. It's borderline but each tool earns its place in a comprehensive market analysis agent.
The toolset covers nearly every major facet of crypto market analysis: prices, history, dominance, derivatives, on-chain activity, DeFi, macro, economic calendar, sentiment, implied volatility, execution cost, and a composite brief. Minor gaps like historical OHLCV or multi-chain on-chain analytics are not critical given the agent's stated focus.