Liquidity-filtered funding & OI across Binance/Bybit/OKX, annualized, + macro regime signals
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 16 of 16 tools scored. Lowest: 3.6/5.
Most tools target distinct domains (network, market, derivatives, macro, on-chain flows), and overlapping tools like get_derivatives vs get_derivatives_aggregate are clearly differentiated by scope and detail level. However, get_crypto_market and get_market_dominance both cover market-wide data, and get_btc_network and get_eth_whale_flows both touch on-chain activity, which could cause some confusion.
All tool names follow a consistent get_ prefix with descriptive nouns (e.g., get_btc_network, get_defi_overview, get_execution_cost). The pattern is uniform across all 16 tools, with no camelCase or inconsistent verb styles, making it very predictable for an agent.
With 16 tools, the server covers a broad but coherent domain of crypto market analysis—prices, on-chain, derivatives, macro, sentiment, and execution. Each tool addresses a distinct analytical need, and the count is well-scoped for a comprehensive agent, not excessive given the breadth of features.
The surface is remarkably complete for a market analysis agent, covering spot, derivatives, on-chain, macro, sentiment, history, and execution costs. Minor gaps exist: no direct tool for decentralized exchange (DEX) trading volumes or specific coin list discovery, and no tool for order book depth beyond the execution cost tool. However, agents can work around these with existing tools.
get_btc_networkALive Bitcoin network health: hashrate, difficulty, transaction count, estimated volume, miner revenue and the largest recent mempool transactions (>10 BTC). Call for on-chain Bitcoin activity. Miner revenue is null when the source stops publishing it, never a misleading zero.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| hashRate | No | |
| difficulty | No | |
| txCount24h | No | |
| marketPrice | No | |
| tradeVolumeUsd | No | |
| btcLargeMempool | No | Largest transactions currently waiting in the mempool. |
| minersRevenueUsd | No | null when the source does not publish it. Never 0 - miner revenue cannot be zero while blocks are produced. |
| estimatedTxVolumeUsd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable nuance: 'Miner revenue is null when the source stops publishing it, never a misleading zero,' which explains a potential output edge case. This goes beyond the annotation baseline, but does not exhaustively describe all behaviors (e.g., throttling or data freshness). A 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The main purpose is front-loaded, and the additional note about null values is essential and efficient. Every word earns its place, fitting the conciseness ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with an output schema, the description fully covers what the tool does, what it returns, and a key behavioral nuance (null handling). There are no missing prerequisites, side effects, or return format ambiguities. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4 per the rubric. The description does not need to explain parameters since none exist, and the schema coverage is moot. The description's mention of what data is returned (e.g., 'largest recent mempool transactions >10 BTC') indirectly informs what the output contains, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Live Bitcoin network health' and lists specific metrics (hashrate, difficulty, transaction count, etc.), distinguishing it from sibling cryptocurrency tools like market quotes or news. The verb 'get' and resource 'BTC network' are explicit, and the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call for on-chain Bitcoin activity,' which gives a clear use case. It does not explicitly mention when not to use it or alternatives, but given the sibling list, the context is enough to infer this is for network health rather than market data. Lacking explicit exclusions, it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crypto_marketALive 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context by emphasizing 'live' data and listing specific market metrics, which helps the agent understand the return value scope beyond the base safety hints.
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, concise and front-loaded with the key purpose. Every sentence adds value, though the second sentence could be slightly more concise without losing meaning.
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 a clear market data focus, complete schema, and an output schema (not shown here), the description sufficiently covers when and how to use it. It doesn't detail every edge case but provides enough context for a straightforward 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?
Schema coverage is 100%, so the schema already documents both parameters. The description reinforces that 'ids' is for coin slugs and 'vs_currency' is for quote currency, but adds no new semantic meaning beyond the schema—keeping the score at baseline 3.
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, listing specific metrics like spot price, market cap, 24h volume, and change. It also mentions specific coins (Bitcoin, Ethereum, Solana, altcoins) and distinguishes it from sibling tools with different focuses like 'get_btc_network' or 'get_fear_greed'.
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 clearly indicates when to use this tool—for any price, market cap, or volume question. It doesn't explicitly state when not to use it or list alternatives among siblings, but given the broad scope and clear market data focus, usage context is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crypto_newsARecent 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, idempotentHint, openWorldHint, and destructiveHint=false. The description adds behavioral context: 'recent' implies time-sensitivity, and the attribution requirement governs output handling. 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?
Two sentences: first sentence states purpose, second provides usage guidance. No wasted words, front-loaded with key information. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, comprehensive annotations, and an output schema (not shown but present), the description is complete. It tells the agent what to expect (headlines) and how to handle the output (attribution, no reproduction). No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the baseline is 3. The description does not add parameter-level details (none needed), but it does imply the data is recent, which is not a 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 resource ('Recent crypto headlines') and the purpose ('for narrative context and catalysts'), using a specific verb and resource. It distinguishes from siblings like get_market_quotes or get_fear_greed by focusing on news content.
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 how to use the output ('Summarize in your own words with attribution... do not reproduce articles'), which is valuable. However, it does not explicitly state when to use this tool versus alternatives (e.g., market data tools), though the context of 'headlines' implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_defi_overviewALive 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds value by specifying the data returned ('TVL, top chains, stablecoin market cap') and the 'Live' nature. No behavioral traits are hidden or contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the key output details and use cases. Every word serves a purpose without redundancy. Highly efficient.
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 the output content and use cases. It could mention that the output is a snapshot (not historical) or include a note about data freshness, but it is sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description cannot add parameter semantics. With 100% schema coverage and no params, the baseline of 4 applies. The description does not need to discuss parameters.
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 a 'Live DeFi overview' with specific metrics: 'total value locked (TVL), top chains by TVL and stablecoin market cap.' This distinguishes it from sibling tools like get_btc_network (Bitcoin-specific) and get_crypto_market (broader market). The verb 'Call for' reinforces the 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 explicitly says 'Call for DeFi flows, liquidity and dry powder, or risk-on/risk-off reads,' which gives clear usage context. However, it does not explicitly exclude other use cases or name alternative tools, leaving some ambiguity for agents unfamiliar with the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_derivativesAVenue-by-venue breakdown for a single coin: what each major liquid venue — Binance, Bybit, OKX and Hyperliquid, the largest perpetual DEX — shows for funding and open interest, taken from that venue's largest-open-interest perpetual. Returns the per-venue rows plus the average funding, total open interest in USD and the funding spread. Reach for this when divergence between venues matters — one venue far more positive or negative than the rest signals localised positioning rather than market consensus. Takes one coin only; to sweep several at once, call get_derivatives_aggregate. Funding is returned in PERCENT per 8 hours (0.0061 means 0.0061%, not 0.61%) and also ANNUALIZED as a percent per year, so it can be compared directly against any other yield; open interest is in USD. Errors if the coin has no major-venue data. Current snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Coin or pair, e.g. BTC, BTCUSDT, ETH |
| Name | Required | Description |
|---|---|---|
| coin | Yes | |
| perExchange | Yes | Per-venue breakdown, from each venue's largest-open-interest perpetual. |
| exchangeCount | Yes | How many major venues backed the numbers. |
| fundingSpread | No | Highest minus lowest venue funding. A wide spread marks localised positioning. |
| avgFundingRate | No | Percent per 8 hours. 0.0067 means 0.0067%, not 0.67%. |
| totalOpenInterestUsd | No | Summed across the major venues. |
| avgFundingAnnualizedPct | No | The same funding as a yearly percentage, comparable to any other yield. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's safe. Description adds value beyond annotations: specifies return structure (per-venue rows plus averages), funding units (percent per 8 hours and annualized), OI in USD, and error behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Six sentences, no wasted words. Front-loaded with main result and venues. Each sentence adds essential information: venues, output fields, usage guidance, unit clarification, error condition. Well-structured for quick agent scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, output schema present), the description covers all necessary context: what data is returned, from which venues, units, error condition, and relation to sibling tool. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'symbol' parameter already described as 'Coin or pair, e.g. BTC, BTCUSDT, ETH'. Description reinforces 'Takes one coin only' but adds no new semantic detail beyond the schema. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it provides 'venue-by-venue breakdown for a single coin' showing funding and open interest from major venues. Explicitly distinguishes from sibling 'get_derivatives_aggregate' for sweeping multiple coins. Uses specific verb 'get' (implied) and resource 'derivatives' with precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use: 'Reach for this when divergence between venues matters'. Provides clear exclusion: 'Takes one coin only; to sweep several at once, call get_derivatives_aggregate'. Also notes error condition when no data exists, setting proper expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_derivatives_aggregateAWatchlist sweep over up to 10 coins in one call: the headline funding and open interest figures per coin — average funding, total open interest in USD, funding spread — with no per-venue rows, which keeps the response compact enough to compare positioning across a basket. Costs a single upstream call no matter how many coins you request, so prefer it over repeated single-coin calls. Figures come from the major liquid venues — Binance, Bybit, OKX and Hyperliquid; thin venues are excluded, since their outlier rates would otherwise distort the average by an order of magnitude. Coins with no major-venue data are listed in "unavailable" instead of failing the whole request. Reach for get_derivatives instead when you need the per-venue detail on one coin. Funding is returned in PERCENT per 8 hours (0.0061 means 0.0061%, not 0.61%) and also ANNUALIZED as a percent per year — 0.0067% per 8h is 7.3% a year, which says immediately whether a long is paying more than a bond yields. Open interest is in USD. Current snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| coins | No | Base coins, e.g. ["BTC","ETH","SOL"]. Maximum 10. Defaults to BTC and ETH. |
| Name | Required | Description |
|---|---|---|
| coins | Yes | |
| unavailable | Yes | Requested coins with no major-venue perpetual. Never silently dropped. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, establishing safety. The description adds substantial behavioral context: costs a single upstream call, excludes thin venues to avoid outlier distortion, handles unavailable coins gracefully, and details the units (percent per 8h, annualized, OI in USD). This goes well beyond what annotations provide, and there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with a clear action statement, then explaining benefits, data sources, handling of missing data, units, and the alternative tool. Every sentence adds value. However, it is slightly verbose (multiple sentences on units could be condensed), preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (aggregate derivatives across multiple venues), the description covers all critical aspects: what data is returned (funding, OI, spread), how it is aggregated (no per-venue rows), data sources (Binance, Bybit, OKX, Hyperliquid), handling of unavailable coins, and units. The presence of an output schema means return value details are not needed, making this description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the one parameter 'coins' is fully described). The description adds value beyond the schema by explaining the maximum of 10 coins, the default (BTC and ETH), and the purpose of the parameter in the context of a basket sweep. Baseline 3 is exceeded due to this added context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a 'watchlist sweep' of up to 10 coins, returning headline funding and open interest figures aggregated across major venues. It explicitly distinguishes itself from the sibling `get_derivatives` by noting that tool provides per-venue detail, while this tool gives compact totals for comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises preferring this tool over repeated single-coin calls because it costs a single upstream call regardless of coin count. It also provides a clear alternative: 'Reach for get_derivatives instead when you need the per-venue detail on one coin.' Additionally, it explains that coins with missing data are listed as 'unavailable' rather than failing, guiding the agent on expected behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_economic_calendarAScheduled macro events (CPI, PCE, NFP / Employment Situation, GDP, Retail Sales, FOMC) from the official US release calendar. Call for upcoming economic catalysts. Returns the scheduled date and indicator, not analyst consensus.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days ahead to cover, defaults to 14 |
| Name | Required | Description |
|---|---|---|
| result | Yes | Scheduled macro releases ahead, soonest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value beyond these by specifying the data source (official US release calendar) and clarifying that it returns 'scheduled date and indicator, not analyst consensus.' No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with examples, and no redundant information. Every word serves a purpose, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, existing output schema, rich annotations), the description fully covers what the agent needs to know: what events are returned, what is not returned (consensus), and the source. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'days' parameter, which already has a clear description. The tool description does not add additional meaning or constraints beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns scheduled macro events from the official US release calendar, listing specific indicators (CPI, PCE, NFP, GDP, etc.). It distinguishes itself from sibling tools which are mostly crypto-focused, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call for upcoming economic catalysts,' providing clear usage context. It lacks explicit when-not-to-use or alternative guidance, but given the sibling set, this is the only macro calendar tool, so the usage is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eth_addressAEthereum address activity: ETH balance plus recent large transfers in and out. Call when a specific wallet or exchange address is named and needs to be tracked.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Ethereum address (0x...) |
| Name | Required | Description |
|---|---|---|
| address | Yes | |
| balanceEth | Yes | |
| recentLargeTransfers | Yes | Transfers above 1 ETH, newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds value by specifying the output includes balance and large transfers, which is beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: one clearly defines the tool's output, the other gives usage guidance. No wasted words, front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to explain return values. It covers the tool's purpose, usage context, and key output fields. Minor gap: no mention of any limitations, but adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter. The description does not add additional meaning beyond what the schema already provides ('Ethereum address (0x...)'), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves Ethereum address activity with ETH balance and recent large transfers. It distinguishes from siblings like get_eth_whale_flows by specifying a single wallet or exchange address, and the usage guidance reinforces this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call when a specific wallet or exchange address is named and needs to be tracked,' providing clear context. It does not mention when not to use or alternatives, but the specificity is sufficient for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eth_whale_flowsALarge 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?
The description discloses that 'wallets that could not be read are listed under "unavailable" rather than dropped' and that the response states 'how far back each wallet could actually be read.' These are critical behavioral details beyond the readOnlyHint annotation, preventing misinterpretation of empty results.
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 longer than the minimal two-sentence version, but every sentence adds value: interpretation of inflows/outflows and data-completeness caveats. It is front-loaded with the core purpose, and the extra sentences are justified given the risk of misreading empty results.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a zero-parameter schema and an output schema present, the description covers all necessary context: what data is returned, how to interpret it for smart-money signals, and how completeness is ensured. The description leaves no critical gap for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter ambiguity. The description effectively defines the implicit query criteria (threshold >100 ETH, exchanges, 2-hour window), which fully compensates for the empty 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 opens with 'Large ETH transfers (>100 ETH) to and from live exchange hot wallets (Binance, Coinbase, Bitfinex) in the last 2 hours,' which precisely names the resource and scope. It also clarifies the intent with 'Call for smart-money signals and exchange flows,' distinguishing it from general market data siblings.
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 smart-money signals and exchange flows' is explicit when-to-use guidance. However, it does not name alternative tools for different types of flows, so the 'when not to use' aspect is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_execution_costAWhat a given trade size actually costs to execute right now, walked through the live order books of Bybit and OKX. Every other tool here reports where price is; this one reports the price YOU would get at YOUR size. Returns, per requested notional and separately for buying and selling: the average fill price, slippage against mid in basis points AND in dollars, the spread, the depth sitting within 1% of mid, and which venue is cheapest for that size. The floor is half the spread; anything above it is the size eating through levels. A size the book cannot absorb comes back as "filled": false with the amount that could actually be filled, never an extrapolated price. This is the number that decides whether a correct thesis still makes money after costs.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | Coin symbol, e.g. "BTC", "ETH", "SOL". The USDT perpetual is read. | |
| sizesUsd | No | Trade sizes to price, in US dollars. Defaults to 10000, 50000 and 250000. At most five. |
| Name | Required | Description |
|---|---|---|
| coin | Yes | |
| venues | Yes | |
| bandPct | No | Half-width of the depth band around mid, in percent. |
| cheapest | Yes | Per requested size, the venue with the lowest slippage among those that can fill it. |
| sizesUsd | Yes | |
| unavailable | Yes | Venues with no usable book for this coin. Never dropped silently. |
| unavailableDetail | No | The same venues with the reason each one failed, so a missing venue is diagnosable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotations, the description reveals how the tool handles insufficient liquidity: 'A size the book cannot absorb comes back as "filled": false with the amount that could actually be filled, never an extrapolated price.' It also explains the interpretation of slippage: 'The floor is half the spread; anything above it is the size eating through levels.' These are behavioral details not present in structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a bit longer than typical but each sentence serves a purpose: first sentence states the core function, second differentiates from siblings, subsequent sentences explain output and edge-case behavior. It is front-loaded with the most important information and the additional detail is justified for a tool with non-obvious behavior, though some editorializing ('This is the number that decides...') could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool and the presence of a full output schema and annotations, the description provides crucial context not captured elsewhere: the venue comparison, behavior when the book cannot absorb size, and the interpretation of slippage as spread plus crossing levels. This makes the tool's behavior clear and complete for an agent to know when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both coin and sizesUsd (100% coverage), so the tool description doesn't add parameter-level semantics beyond what the schema contains. It does reinforce that sizesUsd is 'per requested notional' but this matches the schema's 'Trade sizes to price, in US dollars.' Baseline of 3 is appropriate since the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes actual execution cost for a given trade size by walking live order books of Bybit and OKX. It explicitly distinguishes from siblings: 'Every other tool here reports where price is; this one reports the price YOU would get at YOUR size.' This is a specific verb+resource with clear sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with sibling tools: 'Every other tool here reports where price is; this one reports the price YOU would get at YOUR size.' It also explains when the metric matters: 'This is the number that decides whether a correct thesis still makes money after costs.' This provides clear context for when to use the tool, even without naming specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fear_greedACrypto Fear & Greed Index: current and previous value plus classification (Extreme Fear to Extreme Greed), with recent history. Best used as a contrarian sentiment signal, not on its own.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| value | Yes | 0-100. Low is fear, high is greed. |
| history | Yes | |
| previousValue | No | |
| classification | Yes | |
| previousClassification | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states the tool retrieves historical data ('recent history'), complements the readOnlyHint and idempotentHint annotations by confirming read behavior. While not strictly necessary to call out, it accurately describes the output without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with no wasted words. All critical information (what, what format, when to use) is front-loaded and efficiently communicated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for this tool: it describes the output (current/previous value, classification, recent history), provides usage context (contrarian sentiment signal), and clarifies limitations (not standalone). The output schema presumably documents return fields, so no additional return-value explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description correctly adds no additional parameter semantics. The baseline of 3 is appropriate since there is no parameter information to supplement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the Crypto Fear & Greed Index, including current/previous values, classification, and recent history. It effectively distinguishes itself from sibling tools by specifying the specific index it retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool ('best used as a contrarian sentiment signal') and explicitly advises against relying on it in isolation ('not on its own'). This directly helps an AI agent decide when to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_implied_volatilityAHow far the market EXPECTS price to move, priced off options (the DVOL index). Every other derivatives tool here describes how the market is POSITIONED; this one prices how expensive protection is. Returns the current 30-day implied volatility, annualized, in PERCENT (34.95 means 34.95%), together with its min, median, max and PERCENTILE over the window — an IV of 35% says nothing alone, but at the 5th percentile of the last month it says optionality is cheap and the market is complacent. Also returns the derived expected move (plus or minus percent over 1, 7 and 30 days), which scales with the square root of time, not linearly: dividing annualized IV by 365 instead of by the root understates a one-day move roughly nineteenfold. Distinct from the VIX reported by get_macro_rates, which is US equity volatility, not crypto. Published for BTC and ETH only; any other coin comes back under "unavailable" rather than failing the request.
| Name | Required | Description | Default |
|---|---|---|---|
| coins | No | Coins, e.g. ["BTC","ETH"]. Defaults to both. Only BTC and ETH have a published index. | |
| windowDays | No | How many days the percentile distribution covers. Defaults to 30, maximum 365. |
| Name | Required | Description |
|---|---|---|
| coins | Yes | |
| windowDays | Yes | |
| unavailable | Yes | Requested coins with no published volatility index. Never silently dropped. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, establishing a safe read-only profile. The description adds valuable behavioral context: the index source (DVOL), the interpretation of percentile context, the square-root-of-time scaling for expected moves, and the fallback behavior for unsupported coins. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and has a logical flow: purpose → outputs → interpretation caveats → sibling differentiation → constraints. However, it is somewhat verbose, especially the detailed square-root-of-time explanation and the example about percentiles. While this adds educational value, it makes the description longer than strictly necessary for tool selection. Still, it remains well-structured and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (indicated true), the description does not need to detail the return format. It adequately covers the tool's outputs (30-day IV, percentile stats, expected moves), explains critical interpretation points (annualized percent, percentile context, time scaling), and handles edge cases (unsupported coins). The agent can fully understand the tool's role and behavior without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema by clarifying that the 'coins' parameter only works for BTC/ETH and that other values result in an 'unavailable' response rather than an error. While it doesn't elaborate on windowDays beyond what the schema says, this additional behavioral detail for the coins parameter is valuable and justifies a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns options-implied volatility (DVOL index) and expected moves, using specific verbs ('prices how expensive protection is'). It explicitly distinguishes itself from sibling derivatives tools that describe market positioning and from get_macro_rates (VIX for US equities). The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (to get crypto implied volatility) and when not: 'Every other derivatives tool here describes how the market is POSITIONED; this one prices how expensive protection is.' It contrasts with get_macro_rates for VIX and notes that only BTC and ETH are supported, with non-supported coins returning 'unavailable' rather than failing. No alternative usage guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_macro_ratesALive US macro data with the derived signals, not just the raw levels: Fed funds rate, 2Y and 10Y Treasury yields plus the 2s10s YIELD CURVE SPREAD (with its direction — steepening or flattening — and an inverted flag), CPI inflation year-over-year, the broad trade-weighted dollar index (a different index from the ICE dollar index, so read its direction rather than comparing its level), VIX and M2 money supply. Every series carries its previous reading, so direction is available without a second call. The curve slope, not the level of any single yield, is the liquidity and cycle signal: inversion has preceded every US recession, and re-steepening out of an inversion usually marks the start of easing — the moment that matters for risk assets. VIX explains crypto drawdowns that have no crypto-native cause.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| m2 | No | |
| vix | No | |
| ust2y | No | |
| cpiYoY | No | |
| ust10y | No | |
| fedFunds | No | |
| dollarIndex | No | |
| yieldCurve2s10s | No | 10Y minus 2Y. Inversion has preceded every recent US recession. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive. The description adds context about derived signals (yield curve spread, VIX explanation) which aids understanding of the data's meaning and behavior, going beyond the raw annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and somewhat redundant, repeating the 'derived signals' concept and elaborating on the yield curve and VIX details. It could be more concise while retaining key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description effectively lists the data points returned and explains their relevance. It is sufficiently complete for a read-only data fetch tool, though it omits potential error or edge-case details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The description provides no parameter info, but that is appropriate since none exist; the baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides live US macro data with derived signals (Fed funds rate, yields, CPI, dollar index, VIX, M2). It distinguishes from sibling get_* tools by focusing on macro rates, which is a unique topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over alternatives, though the distinct subject matter makes it implicitly obvious. It lacks a direct 'use this for macro data' or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_briefAThe 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?
Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description adds rich behavioral details: deterministic rules (same numbers always give same verdict), handling of failed sources (named under 'missing' rather than neutral zero), definition of 'fragile', and BTC-only percentile context. This is far beyond what annotations provide.
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 dense but every sentence earns its place. The opening sentence immediately sets the purpose and differentiates from siblings. Subsequent sentences efficiently explain composition, determinism, the 'fragile' definition, and important edge cases. No wasted words; the length is justified by the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers all essential aspects: what it does, how the verdict is derived, its deterministic nature, failure handling, and coin-specific behavior. There are no significant gaps that would prevent correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters (coin and sizeUsd). The description adds one meaningful semantic constraint not in the schema: percentile context exists only for BTC, and other coins get the level without the crowded label. This enhances understanding of the coin parameter. The sizeUsd parameter is not additionally clarified, but the schema covers 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's purpose: composing multiple market signals into a single stance (risk-on, risk-off, fragile, neutral) with confidence level and invalidating conditions. It distinguishes itself from sibling tools by saying 'The verdict in one call, not the ingredients,' which differentiates it from raw-data tools like get_derivatives or get_implied_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 implies when to use the tool ('verdict in one call' vs. 'ingredients'), giving context for synthesis rather than raw data. However, it does not explicitly name alternative tools or state when-not-to-use scenarios, 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.
get_market_dominanceACrypto market dominance: BTC.D, ETH.D and USDT.D as a percentage of total crypto market cap. Use as a regime filter (risk-on/off) and a BTC vs altcoin rotation signal.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| btcDominance | No | |
| ethDominance | No | |
| usdtDominance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, fully covering the safety profile. The description adds context about the return format (percentages) and intended use, but does not disclose additional behavioral traits like data freshness or update frequency. With annotations carrying the main burden, the description provides adequate but not extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary output definition and followed by usage guidance. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, the presence of an output schema, and annotations covering safety, the description is complete. It explains what the tool returns, how to interpret it, and when to use it. No additional information is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema description coverage is 100%. The description does not need to explain parameter semantics. Baseline for 0 parameters is 4, and the description meets this without adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns crypto market dominance metrics (BTC.D, ETH.D, USDT.D) as percentages of total market cap. This clearly distinguishes it from sibling tools like get_crypto_market (overall market data) and get_fear_greed (sentiment), which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use as a regime filter (risk-on/off) and a BTC vs altcoin rotation signal.' This tells the agent when to invoke this tool, though it does not explicitly exclude alternatives or list sibling tools for comparison. The context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_historyAWhere the current reading sits in its own recent distribution, from a series captured every ~10 minutes: funding, open interest, Fear & Greed and BTC dominance, each as current, median, min, max and percentile over the window. This is the one question a snapshot cannot answer — "is funding high right now?" has no absolute answer, only one relative to where it has been. A percentile near 0 means the reading is at the low end of the window, near 100 the high end. Check "samples" before trusting the percentile: a window with few measurements is not a distribution. Window defaults to 24 hours, maximum 168. Funding is in percent per 8 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | How many hours back the window covers. Defaults to 24, maximum 168. |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| from | Yes | |
| funding | No | Current reading placed in its own distribution over the window. |
| samples | Yes | Snapshots in the window, captured every ~10 minutes. |
| fearGreed | No | Current reading placed in its own distribution over the window. |
| windowHours | Yes | |
| btcDominance | No | Current reading placed in its own distribution over the window. |
| openInterestUsd | No | Current reading placed in its own distribution over the window. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations clearly mark the tool as readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds volatility context (data captured every ~10 minutes, window defaults to 24 hours, max 168) and cautions about sample size. However, it does not explain if the percentile is historical real-time or adjusted, nor how funding percent per 8 hours is computed. Still, annotations suffice for safety, and description adds useful nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet fully informative, front-loading the core purpose and then detailing metrics, utility, and caveats. Every sentence serves a clear function, and nothing is extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter, complete schema/annotations, and no nested objects, the description covers all key aspects: what it does, how to interpret results, and limitations (samples check). However, the output schema exists but isn't referenced; the description could benefit from a brief note on returned fields beyond percentiles. Still, it's nearly complete for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description effectively repeats the only parameter ('hours') with defaults and maximums, matching the schema's description exactly. No additional meaning or formatting details are added beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool computes where current readings sit in their recent distribution for funding, open interest, Fear & Greed, and BTC dominance. The verb 'sits' and resource 'recent distribution' are specific and differentiated from siblings; no other tool seems to provide historical percentiles over a sliding window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states this is for relative context (e.g., 'is funding high right now?'), directly contrasting with a snapshot. It tells the agent to check 'samples' before trusting the percentile and specifies volatility-like behavior. No exclusion or alternative tools are named, but the uniqueness of the question justifies the tool's use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_quotesALive 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 provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to re-state safety. It adds value by clarifying the return behavior (ETFs priced in USD per share, use direction/percent change not absolute index level), but does not disclose anything beyond annotations plus this formatting hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the essential information (which ETFs). The explanation about how to interpret the data is helpful but could be slightly more concise. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, a complete output schema, and comprehensive annotations, the description adequately covers what an agent needs to know: which assets are included and how to interpret their values. It could mention the return format or data frequency, but for a quote tool with missing title, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the description has no parameters to document. However, the description provides meaningful usage semantics about interpreting the output (direction and percent change vs absolute level), which adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the specific ETFs (SPY, GLD, QQQ) and provides the context that these are USD-priced ETFs, making the tool's purpose clear. It could better distinguish from the sibling tool get_crypto_market, but it does state these are traditional markets for macro context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'macro context for risk-on/risk-off and the correlation of traditional markets with crypto,' which implies it should be used when analyzing cross-market relationships. However, it does not explicitly say when to use this versus alternatives like get_crypto_market or get_fear_greed, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!