Live crypto data: why a coin or the market is moving (funding, OI, positioning, flow).
Toxic Carry Score (cost-of-leverage from funding, positive = bullish) + Open Interest
Quality Index (is the price trend agreeing with new positioning, i.e. healthy, or against
it, i.e. forced flow / reversal risk). Requires an EnsoTrade Pro API key. coin = ticker
e.g. 'btc'. See the market_glossary resource for how to read these numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does state the authentication requirement (EnsoTrade Pro API key) and points to the market_glossary for interpretation, which is useful context. However, it does not disclose whether the operation is read-only, potential rate limits, or error behavior. The existing output schema reduces the need to describe return values, but more behavioral context would be expected.
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 three sentences with no filler. The core definition of the two indicators is front-loaded, followed by the auth requirement and parameter clarification. It is appropriately sized for the complexity and each sentence contributes 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?
For a single-parameter tool with an output schema, the description covers the key aspects: what the metrics mean, the required auth, the parameter format, and where to learn more. However, it lacks any usage context (e.g., when to choose this over siblings) and does not mention constraints like time periods or market scope. This is adequate but not 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 input schema provides only the parameter name 'coin' with no description, so schema description coverage is 0%. The description compensates by explaining that `coin` is a ticker (e.g., 'btc'), giving the agent the format and an example. This adds meaningful semantic value beyond the bare 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 defines the tool as providing a 'Toxic Carry Score' and an 'Open Interest Quality Index', explaining what each measures. While it lacks an explicit verb like 'retrieves' or 'calculates', the composite indicator is clearly specified. It does not explicitly distinguish itself from sibling tools like get_funding or get_order_flow, but the name and content make its purpose reasonably clear.
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 guidance is given for when to use this tool versus alternatives such as get_funding or get_order_flow. The description mentions the need for an API key and how to read the numbers, but does not state conditions or scenarios where it should be preferred. Implied usage is possible but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The cost of the currency you were never quoted in. Use for "what does it really cost me to trade $5M of SOL", "which venue is cheapest for a USD fund", "how much am I paying to hold USDT", "should I use a USDC venue instead".
THE POINT: every execution cost in this API, and in every competing tool, is denominated in the VENUE'S OWN quote currency. Most perp venues quote USDT. A fund's money is USD. So the quoted cost is for a trade the fund cannot place until it has bought USDT, and the price of that conversion appears in nobody's TCA. This walks the live USD/USDT and USD/USDC books at the caller's size, reports the cheapest round trip and the capacity ceiling, and re-ranks venues on cost INCLUDING the leg.
IT DOES NOT TELL YOU WHICH VENUE TO TRADE ON, and you must not present it as if it does.
That output existed, was measured across 20 coins x 5 sizes, flipped 0 of 95 times, and was
deleted — leg_does_not_change_venue in the response carries the numbers. What it tells you
is what the trade ACTUALLY costs: quote leg_as_pct_of_execution_cost, which is the leg
measured against the trade's own execution cost on the venue the desk would really use.
THE LEG IS A COST ON CAPITAL MOVED, NOT ON TURNOVER. turns is how many times the desk
turns the balance over before repatriating to USD. At turns=1 the full round trip is
charged; at turns=50 the leg is rounding error and the response will show that. Do not
quote the turns=1 figure as a per-trade cost for a desk that trades continuously.
coin = ticker e.g. 'sol'. notional_usd = order size in USD. side = 'buy' or 'sell'.
Requires an EnsoTrade Pro API key.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | ||
| side | No | buy | |
| turns | No | ||
| notional_usd | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to fall back on, the description does the full disclosure. It reveals that the tool forces: that leg cost depends on a 'turns' multiplier, that at turns=1 the full round trip is charged while at turns=50 it approaches zero, and that the old 'venue recommendation' output was measured and deliberately removed. It does not explicitly mention that the tool makes live API calls or its latency, but the explanatory depth and warnings about not overloading turn=1 as a per-trade cost show it goes beyond the bare definition.
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?
While longer than average, it adapts to the tool's conceptual complexity. It introduces the 'point' with a vivid phrase (the cost of the currency you were never quoted in), but the structure is logical: purpose, examples, caveats, parameter definitions, and a closing API-key note. It is a single cohesive block; the front-loading of the one-sentence 'POINT' is strong. A few supporting sentences could be trimmed, but not enough to break the value.
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 with an output schema and several behavioral caveats, the description covers all key context: the motivation (why the leg is invisible in other TCA), the inputs, the output's intended meaning (leg_as_pct_of_execution_cost), and explicit counterfactual warnings (it does that, not that). It also notes the Pro API key requirement, which is not in the schema. The only missing piece is the exact response data model, but the output schema covers that.
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?
Input schema is minimal – only names, no descriptions (coverage 0%). The description fully compensates: 'coin' is a ticker ('sol'), 'notional_usd' is order size in USD, 'side' is 'buy' or 'sell', and 'turns' is explained as how many times the desk repatriates to USD (with concrete thresholds). It even clarifies the default of 1 turn and warns against quoting the turns=1 figure as a per-trade cost for a continuously trading desk.
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 states a clear, specific purpose: to compute the hidden currency-conversion leg cost for a trade, using a finite live order book, and to re-rank venues including that leg. It also explicitly disclaims venue-recommendation, which distinguishes it from sibling tools like route_order and leg_rates. Terms like 'walks the live USD/USDT and USD/USDC books' and 're-ranks venues on cost INCLUDING the leg' make the action and resource 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?
It provides concrete example queries (e.g., 'what does it really cost me to trade $5M of SOL') and an explicit exclusion: 'IT DOES NOT TELL YOU WHICH VENUE TO TRADE ON, and you must not present it as if it does.' This is stronger than typical guidance because it states both when to use and when to avoid misusing the tool, and references the output field leg_does_not_change_venue that encodes the non-decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When during the day crypto is cheapest to execute into, as a session-level profile pooled across the coin universe. Use for "what time of day should I trade", "when is crypto most liquid", "best time to execute a large crypto order". Returns four UTC session blocks with a relative execution-cost number each (lower = cheaper), measured as Amihud illiquidity (|hourly return| / hourly quote volume) over ~62 days of hourly candles.
IMPORTANT when quoting this: the effect is WEAK BUT STABLE — roughly 1.3-1.45x between the cheapest and dearest session, and the response ships a split-half check so you can see that both halves of the sample agree on the ordering. There is deliberately NO per-coin "best hour" because that version FAILED split-sample validation; do not invent one from this data. Free on any EnsoTrade API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does so thoroughly. It discloses the effect is weak but stable (1.3-1.45x), that the response includes a split-half check, and what metric underlies it (Amihud illiquidity over ~62 days). It also warns about a known limitation (per-coin version failed validation).
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, followed by an 'IMPORTANT' caveat. Every sentence adds value: the use-case questions, the effect size, the split-half detail, and the warning. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what the tool returns, how the metric is calculated, and what caveats apply. With an output schema also present, an agent can invoke and interpret this tool correctly without further information.
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, so the baseline is 4. The description adds useful semantic context about the output and measurement method beyond the schema, which is more than necessary for a parameterless tool.
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 states exactly what the tool does: it provides a session-level profile of when crypto is cheapest to execute across the coin universe. It includes concrete use-case questions and specifies the output (four UTC session blocks with relative execution-cost numbers). This clearly distinguishes it from siblings like market_snapshot or top_movers.
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 'Use for' examples and an important caveat advising the agent not to invent per-coin 'best hour' data because that version failed validation. It does not mention alternative tools explicitly, but for a zero-parameter analytics tool the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How fast a crypto position can be exited and what it costs. Use for "how long to get out of $5M of SOL", "can I exit this position", "what's my liquidity risk". Returns: immediate exit cost by walking the live book; direction skew (up-cost vs down-cost, since a lopsided book matters); time to exit at 5%/10%/20% participation; max exitable in 24h; and how concentrated the depth is on one venue.
IMPORTANT when quoting the capacity numbers: they are computed on REPORTED venue volume, which is an UPPER BOUND on genuinely tradable capacity — say so, and treat the time-to-exit figures as optimistic. An "effective volume" adjustment was built and deliberately NOT shipped: comparing how much volume each venue needs to move price one bp collapses into a pure size proxy, because arbitrage equalises price travel across venues. The response carries a live degeneracy_check showing this for the requested asset. Do not present the capacity figures as adjusted or verified volume.
coin = ticker e.g. 'sol'. position_usd = position size in USD. Requires an EnsoTrade
Pro API key.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | ||
| position_usd | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it excels. It explains that capacity numbers are computed on REPORTED venue volume, an upper bound, and is warned to treat time-to-exit as optimistic. It details the unshipped 'effective volume' adjustment and the degeneracy_check in the response, and instructs not to present figures as verified. This is exemplary behavioral disclosure.
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 lengthy, but it is well-structured: a concise summary initially, followed by a list of returns, then a clearly marked 'IMPORTANT' caveat paragraph. Every sentence adds value, and the first sentence captures the core idea quickly. It is slightly longer than ideal, but not rambling.
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, the description is remarkably complete. It explains the core operation, the specific metrics computed, the key caveat about data quality, the API key requirement, and the parameter meanings. The optional output schema exists separately to detail the return structure, so nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It does so fully: `coin` = ticker e.g. 'sol' and `position_usd` = position size in USD. Both parameters are covered with clear meaning and examples, compensating entirely for the schema's lack of descriptions.
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 states a specific resource (crypto position exit capacity) and a clear purpose: 'How fast a crypto position can be exited and what it costs.' It lists concrete use cases like 'how long to get out of $5M of SOL' and enumerates specific outputs. It clearly distinguishes itself from sibling tools that focus on other aspects such as funding or order flow.
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 example queries that signal when to use the tool, and it clearly mentions prerequisites ('Requires an EnsoTrade Pro API key'). It also warns about the interpretation of results (upper bound on tradable capacity). However, it does not explicitly state when not to use this tool or kind adjust behavior for alternatives that could compete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain WHY a crypto coin is up or down right now, from live order-flow and positioning.
Use this for "why is bitcoin down", "why is BTC/ETH/SOL pumping or dumping", or any question
about the CAUSE of a crypto move. Returns a ready-to-quote sentence plus structured signals
(price, regime, funding, open interest, basis). coin = ticker like 'btc', 'eth', 'sol'.
Pass an EnsoTrade Pro API key as a Bearer token for real-time data (public calls are
15-minute delayed) — generate one at ensotrade.tech under Account -> Developer Access.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are supplied, the description fully carries behavioral disclosure. It states the data source (live order flow and positioning), the output format (a ready-to-quote sentence plus structured signals including price, regime, funding, open interest, basis), AND the access condition for real-time vs delayed data. It also mentions where to generate the API key. No behavioral contradictions exist.
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 organized well with the core purpose stated first, followed by usage examples, then output details and the coin parameter. It is somewhat long (including the API key note) but every sentence carries meaningful guidance without redundant filler. It is not as tight as a three-line ideal but remains 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 presence of an output schema but with no detailed description, the tool description still explains the inputs (coin format), the output (sentence and signals), the authentication requirements, and the data freshness tradeoff. It clearly positions the tool within the sibling set by emphasizing causal analysis, making it complete for an agent to call 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 only parameter 'coin' is explicitly described as a ticker like 'btc', 'eth', 'sol', which adds essential semantic detail that the schema (with zero description coverage) lacks. This fully clarifies what value to pass and leaves no ambiguity about format or examples.
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 uses a specific verb ('Explain') and a specific resource (crypto coin moves), and immediately clarifies the intended query types ('why is bitcoin down', etc.). It distinguishes the tool from siblings by emphasizing its focus on the cause of a move via order flow and positioning, which is not present in the sibling names.
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 clear examples of usage ('why is bitcoin down', 'why is btc/ethereum pumping or dumping'), explicitly states the kind of question it is for, and provides concrete input format guidance (coin='btc', 'eth', etc.). It also gives authentication instructions and notes the difference between real-time (with API key) and delayed public calls, which is practical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Raw time series for one field on one symbol, oldest-first, capped at 1000/1500 points.
Use this to explore what a field actually looks like before wiring it into test_formula.
Requires an EnsoTrade Pro API key. symbol e.g. 'SOL' or 'SOLUSDT'.
timeframe="scalp" (default): WDE order-flow microstructure, second-scale. field is one
of mid, spread_bp, signal, toxicity, cost_bp, ret_1s_bp, ret_5s_bp, ret_30s_bp, ret_60s_bp
(top-level), or ofi1, ofi5, dofi, qi, mp, obi, tf1, tf5, tf30, run, inten, vpin, wall,
bid_pr, ask_pr, sigma1m (order-flow features). hours max 168. Coverage is uneven and only
covers whatever windows the WDE panel was actively open for a symbol — SOL and BNB have the
most logged history, other symbols may return no rows for a recent window; widen hours or
try a different symbol if so.
timeframe = "15m", "1h", "4h", or "1d" for day/swing work: real OKX perp candles instead
of order-flow logs (always available, not dependent on the WDE panel being open). field
is one of open, high, low, close, volume, ret_pct (bar-over-bar % return), range_pct
(bar high-low as % of close), body_pct (close-open as % of open), rsi14, vol_ratio (volume
vs its 20-bar average). hours max ~1500 bars worth (e.g. up to ~62 days for "1h").
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| hours | No | ||
| symbol | Yes | ||
| timeframe | No | scalp |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden and does so thoroughly. It discloses rate limits (capped points), data availability quirks (uneven coverage, dependency on WDE panel), authentication requirements (Pro key), and behavior for different timeframes, giving the agent a realistic model of what to expect.
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?
Although long, every sentence adds critical detail. The structure is logical: overall purpose, usage context, then per-timeframe parameter specifics. There is no filler or repetition, making the length justified and well-organized.
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 an output schema (though not shown), so return format is covered. Given the complexity of multiple timeframes and field lists, the description is impressively complete — it even addresses edge cases like missing data. No agent-relevant detail is omitted.
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 0%, so the description must fully explain parameters, and it does. It provides examples for symbol, enumerates valid field values for each timeframe, explains hours max, and clarifies the default and allowed timeframe options. Nothing about the parameters is left ambiguous.
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 fetches raw time series data for a single field and symbol, with specific details like oldest-first ordering and point caps. It distinguishes itself from sibling tools by specifying its role as a data exploration tool for test_formula, making its 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 to use it to explore a field before wiring it into test_formula, and provides guidance on when to use each timeframe mode (scalp vs. daily/swing). It also explains what to do if data is missing (widen hours or try another symbol), effectively teaching the agent when and how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current perpetual funding rate and crowding read for a crypto coin (are longs or shorts
paying / crowded). Use for "what's the funding rate on ", "is funding positive".
coin = ticker e.g. 'btc'. Bearer-auth with a Pro API key for real-time data.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the data is 'current', includes a crowding read, and requires 'Bearer-auth with a Pro API key for real-time data'. It does not cover error conditions or rate limits, but the core behavior is clear.
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 and front-loaded: behavior first, then example queries, parameter format, and auth requirement. Every sentence adds information and none is redundant.
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 single-parameter read tool with an output schema present, the description covers the essential invocation details: what it returns, how to specify the coin, and the auth requirement. The only minor gap is explaining when not to use this tool versus the sibling rate/crowding tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name and type with zero coverage, and the description compensates by defining `coin` as a ticker with the example 'btc'. This is sufficient for a single required 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 states the tool provides 'current perpetual funding rate and crowding read for a crypto coin', with concrete example queries. It is clearer than simply restating the title, but it does not explicitly distinguish this from overlapping siblings like leg_rates or perp_dashboard.
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?
It gives direct trigger examples ('what's the funding rate on <coin>', 'is funding positive') and identifies the intended read use. However, it does not mention when to prefer an alternative tool or state any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Positioning regime + open interest + recent taker imbalance for a crypto coin — whether a
move is new longs, short covering, fresh shorts, or deleveraging. Use for "crypto order flow",
"open interest change", "is this a short squeeze". coin = ticker e.g. 'btc'. Bearer-auth
with a Pro API key for real-time data.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that Bearer-auth with a Pro API key is required for real-time data, which is useful context. However, it doesn't mention whether this is a read-only operation, potential rate limits, or how the output is structured beyond the described concepts.
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 packs necessary information into a few sentences. The main purpose and example queries are front-loaded, followed by the parameter format and auth note. It is tight, though the line break after 'short squeeze' adds slight awkwardness.
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 single-parameter tool with an output schema present, the description is fairly complete. It explains the domain concept, gives usage examples, parameter format, and auth requirements. It could have briefly mentioned the output nature (e.g., is it a report object?) but the output schema likely covers that.
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 a single parameter 'coin' with no description, and schema coverage is 0%. The description compensates by specifying 'coin' = ticker e.g. 'btc', adding meaning beyond the bare string type. However, since there is only one parameter and the example is clear, this is adequate but not extensive.
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: it provides positioning regime, open interest, and taker imbalance to characterize crypto moves. Specific examples of queries are given ('crypto order flow', 'open interest change', 'is this a short squeeze'), distinguishing it from potential siblings about funding, pressure, or execution.
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 mentions sample queries that an agent might use to select this tool, giving clear context for use. It does not explicitly mention when not to use alternatives, but the example queries effectively signal the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What it costs, right now, to move USD into and back out of the stablecoins the crypto venues quote in — and how much can be moved before the book runs out. Use for "what does USDT conversion cost", "is USDC or USDT cheaper to hold", "how much can I convert at once", "what is the USDT basis".
No coin involved: this is the currency leg on its own. Returns per-market cost in and out, the cheapest venue for each direction, aggregate capacity, and how far each stablecoin is trading from 1.0000.
where_to_convert IS THE ACTIONABLE PART: the cheapest and dearest conversion venue and
the bp/USD penalty between them. Measured at 13.5x-17x on USDT and 27.7x on USDC, and the
winner ROTATES with size because these books are shallow enough that the usual winner runs
out — Kraken wins to $2.5M and loses to Bitfinex at $5M.
CAPACITY IS THE PART THAT SURPRISES PEOPLE. The USD/stablecoin books are thin relative to
the coin books they feed, so a size that walks a coin book comfortably can exhaust the
currency book outright. size_exceeds_capacity is a hard wall, not a cost.
par_offset_bp is NOT charged as a cost — a desk that buys and later sells the same stablecoin is flat to it. Do not add it to the round-trip figure.
notional_usd = the size to price. Requires an EnsoTrade Pro API key.
| Name | Required | Description | Default |
|---|---|---|---|
| notional_usd | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: capacity is a hard wall, par_offset_bp is not a cost, the winner rotates with size, books are shallow, and a Pro API key is required. These are non-obvious and essential facts not inferable from the schema.
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 average but every section adds distinct value: use cases, capacity caveat, par_offset clarification, and parameter definition. It is front-loaded with the key question it answers. Slight verbosity in all-caps headings does not detract significantly.
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 a single parameter, no annotations, and an output schema (which covers return structure), the description covers all necessary operational context: what is returned, how to interpret warnings, what not to add, and access requirements. An agent can call this tool correctly with high confidence.
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?
Only one optional parameter exists with 0% schema description coverage. The description explicitly defines notional_usd as 'the size to price' and mentions default sizing context (measured at certain multiples). This directly compensates for the schema's lack of description, though units and range are not detailed.
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 states a specific purpose: reporting costs to move USD into and back out of stablecoins, with per-market costs, cheapest venue, capacity, and deviation from $1.0000. It explicitly says 'No coin involved: this is the currency leg on its own,' which distinguishes it from sibling tools like carry_pressure or market_snapshot.
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 usage scenarios ('Use for...') and explicitly scopes the tool to the currency leg, implying it is not for coin-related queries. It does not explicitly list exclusions or alternatives, but the context signals are strong enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-sectional momentum ranking across the whole crypto perp universe right now — which coins are leading (top percentile) vs lagging (bottom percentile). Use this FIRST when asked to "find a coin" or "what should I look at" before drilling into one with the other tools. Requires an EnsoTrade Pro API key.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds the important behavioral constraint of requiring an EnsoTrade Pro API key, and implies a real-time snapshot. However, it does not disclose other behavioral aspects like whether results are sorted, paginated, or cached, though these are partly covered by the output schema.
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 filler. The core purpose is front-loaded, followed by usage guidance and a key requirement. 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?
Given there is an output schema, return values need no explanation. The description covers purpose, usage context, and an important prerequisite (API key). The only minor gap is the undocumented 'limit' parameter, but it is a simple optional field with a default, so overall completeness is high.
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 has 0% description coverage and the description does not mention the 'limit' parameter at all. While the name and default (20) are somewhat self-explanatory, the description adds no semantic value beyond the schema, failing to compensate for the low 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?
The description states a specific verb ('ranking') and resource ('whole crypto perp universe'), with clear differentiation between leading and lagging coins. It also signals its primary role as the first-step tool, distinguishing it from the sibling tools that drill deeper.
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 directs the agent to use this tool FIRST when asked to 'find a coin' or 'what should I look at', and contrasts it with 'the other tools' for deeper investigation. This gives clear when-to-use guidance and implicitly names alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One combined live snapshot for a crypto coin: price, 24h change, funding, open interest,
perp basis, positioning regime. coin = ticker e.g. 'btc'. Bearer-auth with a Pro API key
for real-time data plus the validated funding-momentum directional signal (public calls get
a 15-minute-delayed price and no directional call).
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates the authentication requirement (Bearer-auth with Pro API key), the data access tiers, and the special condition of delayed public data. It does not elaborate on rate limits or side effects, but 'snapshot' implies a read operation, and the auth note is a valuable disclosure.
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, containing exactly two sentences that cover the core purpose, parameter semantics, authentication, and public-call limitations. Every clause conveys meaningful information, and the key details are front-loaded in the first sentence with the parameter explanation leading into the auth note.
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 sufficient for an agent to invoke the tool correctly: it names the single required parameter, shows an example value, and explains the authentication-dependent behavior. Since an output schema exists, the return structure need not be spelled out, and the trade-offs between Pro and public calls are clearly noted, making the context complete for this moderately 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?
The schema has one required string parameter with no additional description, yet the description explicitly explains that 'coin' is a ticker such as 'btc'. This provides the necessary semantic meaning beyond the raw schema and gives a concrete example, fully compensating for the 0% schema description 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?
The description clearly identifies the tool's function as providing a combined live snapshot for a crypto coin and lists specific metrics (price, 24h change, funding, open interest, perp basis, positioning regime). However, it uses a noun phrase rather than an explicit verb like 'get' or 'fetch', and it does not directly contrast with sibling tools, though the listed fields give a distinct profile.
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 context by explaining the difference between Pro API key usage and public calls, including the 15-minute delay and absence of the directional signal. However, it does not explicitly state when to choose this tool over its siblings such as get_funding or perp_dashboard, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bounded MASS scan. Select exchanges with comma-separated venues. Rows stay separate. Pro key required.
| Name | Required | Description | Default |
|---|---|---|---|
| coins | No | ||
| limit | No | ||
| venues | No | ||
| impact_pct | No | ||
| venue_class | No | perp |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses a few traits: the scan is bounded, venues are selected with comma-separated values, rows remain separate, and a Pro key is required. However, it does not clarify what 'bounded' refers to, whether the operation is read-only, rate limits, error behavior, or the nature of results, leaving notable ambiguity for an agent.
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 no filler words. Each sentence conveys a fact, and the formatting is scannable. It loses one point because the terse wording contributes to ambiguity, so it is not perfectly structured for clarity.
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 no annotations, five undocumented parameters, and no parameter descriptions in the schema, the description is insufficient. It omits details about what each parameter controls, what the output looks like, and how this tool relates to the sibling mass_scan. The presence of an output schema does not compensate because its structure is not provided. Overall, the agent lacks essential information for confident use.
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 0%, leaving the description to compensate. It only explains the venues parameter (comma-separated format). The meanings of coins, limit, impact_pct, and venue_class are entirely absent, and even the relationship between 'bounded' and the limit parameter is not explicitly stated. Five unexplained parameters at zero coverage are not adequately addressed.
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 identifies a 'Bounded MASS scan' and mentions venue selection and row separation, but it never states what output the tool actually produces or what 'MASS' signifies. It is clear enough to separate it from generic tools, yet it fails to distinguish it from sibling mass_scan or to define the core resource being acted on.
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 guidance is provided on when to use this tool versus alternatives like mass_scan, market_snapshot, or market_rotation. The only contextual note is 'Pro key required', which is an access restriction rather than a usage guideline. There is no statement of conditions that would favor mass_map over a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MASS on one selected exchange or comma-separated exchanges. One result per exchange; no blend. Pro key required.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | ||
| venues | No | ||
| impact_pct | No | ||
| venue_class | No | perp |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses key behavioral traits: operates on one or comma-separated exchanges, returns one result per exchange, does not blend, and requires Pro key. However, it omits other behavioral details such as error handling, rate limits, or output format, so partial 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?
Three sentences with no fluff—every clause contributes information. The description is appropriately short and front-loaded with the core action. It loses one point for not structuring parameter hints, but overall it is compact and readable.
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 4-parameter tool with zero schema coverage and no annotations, this description is too sparse. It fails to explain the meaning of three parameters, lacks usage guidance, and does not mention output structure despite the existence of an output schema. An agent would struggle to invoke this tool correctly with only this text.
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 0%, so the description must compensate. It vaguely hints at venues via 'one selected exchange or comma-separated exchanges' but leaves coin, impact_pct, and venue_class unexplained. The description adds minimal value beyond the schema's bare parameter names.
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 states a specific operation ('MASS on exchanges') and distinguishes it from siblings by noting 'one result per exchange; no blend.' It clearly identifies the resource (exchanges) and the action (MASS scan), though it does not define what MASS stands for.
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 (when you need MASS data per exchange) but provides no explicit guidance on when to choose this tool over alternatives like mass_map. It mentions a prerequisite ('Pro key required') but does not explain when this is the right tool versus other scan/map tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full crypto options chain for a coin: strikes, mark IV, greeks, and the Black-Scholes
fair-value gap per contract. Requires an EnsoTrade Pro API key. coin = underlying
ticker e.g. 'btc'.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the need for an EnsoTrade Pro API key, which is a meaningful prerequisite. However, it does not mention whether the operation is read-only, whether data is real-time, or any rate-limit/pagination behavior, leaving gaps in behavioral 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?
Two sentences: the first front-loads the core function and contents, the second covers the API key requirement and parameter semantics. There is zero redundant phrasing, and every clause adds value.
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 single parameter is fully explained, the API key prerequisite is stated, and an output schema exists to document return structure, nothing essential is missing. The description is complete for an agent to invoke the tool 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 sole parameter 'coin' is fully explained in the description with an inline definition ('underlying ticker') and a concrete example ('e.g. 'btc''). Since the schema provides only a string type with 0% description coverage, this enrichment is essential and completely sufficient for correct invocation.
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 uses a specific verb phrase 'Full crypto options chain' and enumerates the exact contents (strikes, mark IV, greeks, Black-Scholes gap), making it unmistakable what the tool returns. This clearly distinguishes it from siblings like market_snapshot or get_funding.
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 the tool is used when an options chain for a coin is needed, and it states the API key requirement as a precondition. However, it does not explicitly contrast with alternative tools or state when not to use it, leaving the when-to-use guidance mostly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full perp dashboard for a crypto coin: mark price, index price, funding rate + next
funding time, open interest, 24h high/low/volume. Requires an EnsoTrade Pro API key
(Bearer auth) — generate one at ensotrade.tech, Account -> Developer Access.
coin = ticker e.g. 'btc'.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the authentication requirement (Pro API key via Bearer auth) and where to generate it, which is critical for invoking the tool. It also lists the return data fields, giving clear behavioral expectations. It does not mention rate limits or error behavior, but for a read-only data fetch this is sufficient.
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: one sentence listing output data, one sentence covering authentication and parameter semantics. Every clause adds value, and there is no redundancy or 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?
Given the tool's moderate complexity (single parameter, authentication needed, rich output), the description covers all necessary invocation details: what the tool returns, how to authenticate, and what the parameter means. Since an output schema exists, the lack of explicit return format documentation is not a 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?
The schema provides only the parameter name and type (coin: string) with 0% description coverage. The description fully compensates by explaining that 'coin' is a ticker and gives a concrete example ('btc'). This adds essential meaning beyond the schema and leaves no ambiguity.
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 'Full perp dashboard for a crypto coin' and immediately enumerates the exact data points included (mark price, index price, funding rate, open interest, etc.). It is a specific verb+resource statement that clearly differentiates this tool from siblings that focus on single data streams like get_funding.
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 does not explicitly state when to use this tool over alternatives or mention exclusions. However, the term 'Full perp dashboard' implies a comprehensive view, which guides an agent to prefer it when a broad market overview is needed. Lacking direct comparison to sibling tools, it is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Position-limit table for a universe of crypto perps: the largest position in each coin that could be exited inside 24 hours at a chosen participation rate, sorted TIGHTEST-FIRST. Use for "what position limit should I set on X", "which of my positions is too big to get out of", "how much SOL can I safely hold", "rank my coins by exit risk".
coins = optional comma-separated list (default: the liquid crypto perp universe by
volume). participation = the fraction of daily volume you are willing to be, default
0.10 (10%). limit = how many coins to return, max 40.
IMPORTANT when quoting these: they are computed on REPORTED venue volume, which is an UPPER BOUND on genuinely tradable capacity — say so, and treat the limits as optimistic. No effective-volume adjustment is applied; that was built, measured and cut because arbitrage equalises price travel across venues, collapsing volume-per-bp into a size proxy. Requires an EnsoTrade Pro API key.
| Name | Required | Description | Default |
|---|---|---|---|
| coins | No | ||
| limit | No | ||
| participation | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly discloses the key behavioral trait: the limits are computed on reported venue volume, which is an upper bound, and no effective-volume adjustment is applied. It also reveals the requirement for an EnsoTrade Pro API key and notes that the adjustment was built, measured, and cut for a specific reason. This is significant behavioral context that an agent needs to avoid misusing the tool.
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 not bloated. It front-loads the core purpose and use cases, then details parameters, then adds the critical caveat. While it is somewhat long, every sentence carries useful information for an agent. A slight reorganization could tighten it, but overall it earns a high 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, the lack of annotations, and the 0% schema coverage, the description is remarkably complete. It covers what the tool does, when to use it, how to interpret results, parameter details, and a key caveat. The presence of an output schema means return values need not be described. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains each parameter: `coins` (optional comma-separated list, default liquid crypto perp universe), `participation` (fraction of daily volume, default 0.10), and `limit` (number of coins, max 40). This goes beyond the minimal schema info and provides meaningful usage semantics.
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 uses a specific verb phrase ('position-limit table... sorted TIGHTEST-FIRST') and clearly identifies the resource (crypto perp positions) and the intended use cases ('what position limit should I set on X', 'rank my coins by exit risk'). It distinguishes itself from sibling tools by focusing on exit capacity within 24 hours at a participation rate, which is a unique angle compared to tools like exit_capacity or carry_pressure.
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 lists example queries ('what position limit should I set on X', 'which of my positions is too big to get out of') and provides a clear caveat about the optimistic nature of the limits. It also states that the results are computed on reported venue volume, which is an upper bound, and advises how to handle that in practice. This gives agents clear guidance on when to use this tool and how to interpret its output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Universe-wide maker/taker table: for each liquid crypto perp, the best venue to post on and the round-trip prize, sorted widest-first. Use for "where is being passive worth the most", "which coins should I be quoting rather than taking", "rank my book by spread capture".
Same honesty requirement as post_value and it is not optional: these are prizes CONDITIONAL ON BEING FILLED. No fill probability is estimated anywhere in the response. Say so.
coins = optional comma-separated list (default: the liquid crypto perp universe by volume).
notional_usd = optional; supplying it prices crossing as the real book walk and adds the
best-venue-to-cross comparison per coin. limit = how many coins, max 40. Requires an
EnsoTrade Pro API key.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | buy | |
| coins | No | ||
| limit | No | ||
| notional_usd | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does this well: it explicitly warns that prizes are 'CONDITIONAL ON BEING FILLED' and that 'No fill probability is estimated anywhere in the response,' it states the output ordering ('sorted widest-first'), explains the effect of providing notional_usd ('prices crossing as the real book walk and adds the best-venue-to-cross comparison per coin'), and notes the API key requirement. This is strong behavioral disclosure, though a few details (e.g., error handling or exact response format) are left to the output schema.
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 efficiently structured: a one-sentence summary of purpose, a clear list of use cases, a direct and emphatic honesty warning, then a compact parameter glossary. Every sentence serves a function, and the most critical constraints (fill condition, no probability) are front-loaded immediately after the purpose. No filler or redundant phrasing.
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 (4 optional parameters, no annotations, output schema available), the description covers essential context: what the tool returns conceptually, how it sorts, the conditional nature of prizes, the impact of notional_usd, the limit cap, and authentication needs. The output schema covers return shape, so that is appropriately delegated. The only notable omission is the side parameter semantics, which slightly reduces completeness.
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% description coverage for its 4 parameters, so the description must compensate. It does: 'coins = optional comma-separated list (default: the liquid crypto perp universe by volume)', 'notional_usd = optional; supplying it prices crossing as the real book walk...', and 'limit = how many coins, max 40.' However, the side parameter is not explained at all, leaving a small gap. Despite that, the description adds rich semantics beyond the raw schema, earning a 4 but not a 5.
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 begins with a specific, action-oriented summary: 'Universe-wide maker/taker table: for each liquid crypto perp, the best venue to post on and the round-trip prize, sorted widest-first.' It clearly states the resource (liquid crypto perps), the action (finding the best venue to post), and the sorting logic. It also lists concrete use cases ('where is being passive worth the most', 'which coins should I be quoting rather than taking', 'rank my book by spread capture'), which unambiguously differentiates this tool from the sibling post_value by emphasizing a whole-universe 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 description provides explicit use cases and conditions: 'Use for "where is being passive worth the most"...' and it notes a prerequisite: 'Requires an EnsoTrade Pro API key.' It references the sibling post_value ('Same honesty requirement as post_value') indicating a related alternative, but does not explicitly state when NOT to use this tool versus its siblings. The context is clear enough to guide selection, though exclusions or alternative routing are not spelled out, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What POSTING a resting order is worth versus CROSSING the spread, per venue, for a crypto perp. Use for "should I use a limit order or market order", "what does paying the spread cost me", "which venue should I quote on", "is it worth being passive here", "maker vs taker".
Returns per venue: the current spread in bp, taker and maker fee, the value of posting per
side, and the round trip (2x, because a position is opened and closed). Ranked by posting
value. Pass notional_usd to price the crossing side as the real walk down the book instead
of half the spread — a larger and more honest number at size.
MEASURED across 54 coin-venue pairs: median 4.09bp per side / 8.17bp round trip, mean 4.63bp, p90 6.72bp. Wide-spread names go much further (ARB 20.31bp round trip, OP 19.33bp, DOT 19.70bp). Note SOL at a 0.13bp spread is still worth 4.07bp per side — on a tight book the whole of the value is the maker/taker FEE DIFFERENTIAL, which does not shrink as spreads tighten. That is a floor, and it is why this holds up on liquid majors where cheapest_venue has almost nothing to choose between.
YOU MUST STATE THIS WHEN QUOTING ANY NUMBER FROM THIS TOOL: it is the SIZE OF THE PRIZE, NOT THE PROBABILITY OF WINNING IT. A resting order that never fills does not save the spread, it costs the trade, and that is routinely worth more than the basis points here. EnsoTrade does NOT estimate fill probability — that needs order-book time series this service does not log — and does not approximate it. Never present posting as free money.
Also read cross_vs_post: the best venue to POST on is frequently NOT the best venue to
CROSS on, because maker fees and spreads rank venues differently from depth. Where they
differ, the answer is to rest on one and take on the other.
coin = ticker e.g. 'sol'. Requires an EnsoTrade Pro API key.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | ||
| side | No | buy | |
| notional_usd | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers: it discloses the return contents (spread in bp, taker/maker fee, posting value per side, round trip, ranking), the API-key requirement, and critically the interpretive warning that the value is the size of the prize, NOT the probability of winning it, explicitly stating fill probability is not estimated. This is exactly the kind of behavioral context that prevents misuse.
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 purpose and use cases, and nearly every sentence earns its place — especially the fill-probability warning and cross_vs_post routing. The statistics block with named coins and round-trip bp values is useful calibration for agents quoting numbers, but it is somewhat long and could be tightened without losing the fee-differential floor insight.
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?
Against a minimal 3-param schema with 0% description coverage and no annotations, this description is remarkably complete: it covers return values (even though an output schema exists), two of three parameters, authentication requirements, typical magnitude via statistics, a critical interpretation caveat, and sibling routing. Nothing an agent needs to select and invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It documents coin ('ticker e.g. 'sol'') and notional_usd richly ('price the crossing side as the real walk down the book instead of half the spread'). However, the side parameter is left to inference — it is referenced only as 'per side' in the returns, not explained as an input. Strong compensation for most params with one gap.
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 opening sentence states a specific comparison — POSTING a resting order vs CROSSING the spread, per venue, for a crypto perp — with an unambiguous verb and resource. It distinguishes itself from siblings by naming cross_vs_post as the complementary comparison and by framing its output (maker/taker fee economics) differently from siblings like route_order or post_map.
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 verbatim use cases ('should I use a limit order or market order', 'which venue should I quote on', 'maker vs taker') and explicitly routes the agent to cross_vs_post with the condition: the best venue to post on is frequently NOT the best venue to cross on. This is explicit when-to-use plus alternative selection, not left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cheapest way to fill a crypto perp order across multiple venues, and what that saves versus using the single best venue. Merges every order-book level from Binance, Bybit, Bitget, Hyperliquid, OKX and Gate into one list ordered by FEE-ADJUSTED price and walks it until filled. Use for "how should I split this order", "what's the cheapest venue to buy $2M of SOL", "how much would routing save me". Returns the per-venue allocation, the blended price, the best single venue, and the saving in bp and USD.
coin = ticker e.g. 'sol'. notional_usd = order size in USD. side = 'buy' or 'sell'.
venues = optional comma-separated subset (e.g. "binance,bybit") for a desk that only has
accounts on some — the saving is only real on venues you can actually trade.
This is a MEASUREMENT of a live book, not a prediction: it is optimal for the static snapshot, prices move while an order works, and it assumes capital is already on each venue and ignores transfer costs. Requires an EnsoTrade Pro API key.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | ||
| side | No | buy | |
| venues | No | ||
| notional_usd | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses algorithm (merges fee-adjusted levels, walks the book), that it is a measurement not a prediction, assumptions (capital on each venue, no transfer costs), limitations (prices move), and the need for an API key. This provides deep behavioral insight beyond the basic function.
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 average, but every sentence carries essential information: problem statement, algorithm, use cases, return values, parameter definitions, and caveats. It is logically front-loaded with the primary purpose and caveats placed at the end with the API key requirement. No filler or repetition.
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, multiple parameters, and the presence of an output schema, the description covers all needed contextual elements: parameter meanings, use-case instructions, behavioral limitations, authentication requirements, and return values. Even though an output schema exists, the description still summarizes what is returned, which improves completeness.
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 descriptions are absent (0% coverage). The description compensates by explaining each parameter: 'coin', 'notional_usd', 'side', and 'venues', including examples ('sol', 'binance,bybit') and the purpose of the venues param. Since schema provided no help, this is exemplary compensation.
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 a specific, result-oriented statement: 'Cheapest way to fill a crypto perp order across multiple venues, and what that saves versus using the single best venue.' It clearly distinguishes the tool by its multi-venue routing and savings analysis, and names example queries. This separates it from generic order tools and the many sibling analysis tools.
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?
It gives explicit use cases ('Use for "how should I split this order"...'), and explains when the optional venues parameter matters. It warns that it is a static measurement, implying limitations for live execution, but it does not point to alternative sibling tools or explicitly state non-use conditions. Overall, the guidance is clear and context-aware.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a formula as a strategy IF it currently validates. Re-runs test_formula itself
server-side first — never trusts a stale claim from an earlier call, since data moves —
and only saves when that fresh verdict is 'validated'. Saved strategies appear in the
user's own EnsoTrade dashboard under Strategies; they're private to that account, not
published or shared with anyone else. Same parameters as test_formula: symbol/formula
as usual, timeframe="scalp" (use horizon) or "15m"/"1h"/"4h"/"1d" (use horizon_bars),
hours = history window tested. label is an optional short name for the strategy (e.g.
"BTC 1h RSI reversion"). Requires an EnsoTrade Pro API key.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| label | No | ||
| symbol | Yes | ||
| formula | Yes | ||
| horizon | No | ret_30s_bp | |
| timeframe | No | scalp | |
| horizon_bars | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does the disclosure work: it states the server re-runs validation (`Re-runs test_formula itself server-side first`), trusts no stale result, only saves on validated, persists privately to the user's dashboard, and requires a Pro key. It does not describe overwrite/duplicate behavior or failure response, but the main side effects are disclosed.
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?
Five purposeful sentences introduce the action, then validation behavior, then param mapping; no padding. The structure packs much detail into a continuous paragraph and would be slightly clearer with bullet/list separation of parameter groups, but it remains 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 annotations, an output schema, and 7 params, the description covers operation, conditions, side effects, auth, privacy, and parameter relationships. The only notable omissions are precise error/invalid-verdict behavior and detailed semantics of `horizon`, but the output schema and sibling `test_formula` fill some gaps.
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 0%, but the description enumerates the main params: `symbol`/`formula`, conditional use of `horizon` vs `horizon_bars` based on `timeframe`, meaning of `hours`, and optional `label`. It leaves precise semantics of `horizon` (e.g. `ret_30s_bp`) to defaults/sibling knowledge but sufficiently compensates for an 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?
Description states the action (`Save a formula as a strategy`) and the condition (`IF it currently validates`), clearly distinguishing it from testing-only siblings by describing persistence to dashboard. It names sibling `test_formula` and clarifies save happens only after fresh validation, so the function's purpose 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?
It clearly implies usage as the persistence counterpart to `test_formula` by saying it re-runs the test server-side and only saves on a fresh 'validated' verdict. It also supplies prerequisites (`EnsoTrade Pro API key`) and privacy scope. It does not explicitly spell out cases to prefer `test_formula` over `save_strategy` (e.g., testing without persisting), so not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invent a formula over EnsoTrade's data, and get back whether it actually predicts
forward returns — validated on a holdout split, not just fit to the whole window.
formula is a math expression combining any of the fields listed in fetch_series'
docstring (for the same timeframe) with +, -, *, /, **, %, unary +/-, and abs/min/max/
sqrt/log/log1p/exp/sign/clip/mean/std, e.g. "ofi1 * vpin - dofi / 2" or
"sign(qi) * sqrt(abs(obi))". No other Python is executed — this runs through a restricted,
default-deny expression evaluator, not eval().
timeframe="scalp" (default, WDE order-flow, second-scale): horizon is which forward
return to correlate against — ret_1s_bp, ret_5s_bp, ret_30s_bp, or ret_60s_bp. hours max
720 (30 days).
timeframe = "15m"/"1h"/"4h"/"1d" for day/swing strategies (real OKX candles, always
available): use horizon_bars instead of horizon — the forward % return N candles
ahead (e.g. horizon_bars=4 on timeframe="1h" = predicting the move 4 hours out). hours
max ~1500 bars worth; a small hours still fetches at least 150 bars (the minimum needed
for a meaningful 70/30 split) rather than failing outright, so the actual window tested
can be wider than requested for a small hours value.
Either mode needs enough rows that a 70/30 split leaves >=150 total. Returns train (first 70% chronologically) and holdout (untouched final 30%) Spearman/Pearson correlations plus a verdict: 'validated' only if holdout |spearman| >= 0.15 AND same-signed as train — this guards against keeping a formula that only looked good by chance on one slice of data.
ALSO returns, computed on the holdout portion only:
net: risk-adjusted performance AFTER trading costs — sharpe, sortino,
max_drawdown_pct, calmar, ann_return_pct, ann_volatility_pct, win_rate_pct,
profit_factor. Sharpe is annualized and corrected for overlapping horizons
(a horizon spanning N bars sampled every bar is subsampled to non-overlapping
periods first, which removes the ~sqrt(N) inflation naive Sharpe would show).
gross: the same metrics before costs, so the cost drag is visible.
costs: fee/slippage assumptions, position_changes (turnover), total_cost_pct.
Costs are charged on position CHANGES only, not per bar — holding one side is
cheap, flipping every bar is not.
cost_verdict: survives_costs / marginal_after_costs / killed_by_costs / unknown.
IMPORTANT: verdict is a correlation test and says nothing about profitability;
a formula can be 'validated' and still be killed_by_costs. Check both.
walk_forward: the same formula re-scored on 5 consecutive time blocks, with
consistency_pct (share of blocks agreeing on direction) and a stable flag.
An edge that passes one holdout but flips sign between blocks is usually noise.
fee_bp/slippage_bp are per side, defaulting to 5bp taker + 2bp slippage; raise
them for illiquid coins or a worse fee tier. Iterate: call this repeatedly with
different formulas, keep what validates AND survives costs, discard what doesn't.
Requires an EnsoTrade Pro API key.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| fee_bp | No | ||
| symbol | Yes | ||
| formula | Yes | ||
| horizon | No | ret_30s_bp | |
| timeframe | No | scalp | |
| slippage_bp | No | ||
| horizon_bars | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility, and it does an excellent job. It discloses the restricted evaluator (no eval, default-deny), the validation methodology (70/30 chronological split, same-sign requirement), how costs are charged (only on position changes), the meaning of verdict vs. cost_verdict, and walk-forward stability checks. No behavioral surprises are left unmentioned.
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 long but well-structured with clear sections. Each paragraph adds necessary context; there is no fluff. It earns a 4 rather than 5 only because the length, while justified, could be slightly tightened for faster parsing by an agent.
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 complex tool with 8 parameters and a rich output schema, this description is remarkably complete. It covers formula syntax, data availability, timeframes, cost modeling, return metrics, verdict logic, and practical iteration advice. An agent has everything needed to invoke the tool correctly and interpret its results.
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% description coverage, yet the tool description explains every parameter: symbol, formula (with syntax and allowed operators), timeframe (modes), horizon vs. horizon_bars, hours limits, fee_bp and slippage_bp defaults and guidance. It even warns about minimum data requirements. This fully compensates for the sparse 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 states a specific verb and resource: 'Invent a formula over EnsoTrade's data, and get back whether it actually predicts forward returns' — a testing/validation tool for formulas. It distinguishes itself from sibling tools by describing a unique workflow of hypothesis testing against a holdout split, which is not present in other tool names.
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 instructs when to use this tool: 'Iterate: call this repeatedly with different formulas, keep what validates AND survives costs, discard what doesn't.' It also explains mode-specific usage (scalp vs. day/swing) and parameter choices. This is more than sufficient for an agent to select it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top gaining and losing crypto perpetuals right now, ranked across the whole market. Use for "top crypto movers", "biggest crypto gainers and losers today".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly states the output will be rankings of gainers and losers, and ranks are ordered (implied by 'ranked'), which helps set expectations. However, it does not disclose any caching behavior, time window, or whether results are live or delayed. Most critically, the description invents a quoting structure ("Use for ...") that reads like a usage hint but provides no behavioral facts, such as pagination or output format. An agent cannot reliably predict what fields each row contains without an output schema reference.
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—a single sentence plus quoted example phrases. It front-loads the core value proposition. The quotes take up space without adding much semantic value beyond natural-language examples, but they are not padding. A 4 feels right: it's efficient, though the quoted block adds a little noise.
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 (so return fields are defined there) and only one parameter, the description is close to adequate. But with schema coverage at 0%, the single parameter 'limit' is entirely undefined, and the description adds no detail. The tool is a market-wide mover list; an agent could call it correctly for top movers, but might misuse 'limit' or misunderstand the return shape. A score of 3 reflects that it passes for a simple call but leaves a minor gap on the parameter.
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 has a single integer parameter 'limit' with a default of 10, and schema_description_coverage is 0%. The description does not explain what 'limit' controls (number of items returned, presumably) or any bounds. Since the schema provides no descriptions for the parameter, the description should have compensated—it does not. An agent must guess at the semantics of 'limit'.
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's purpose: listing top-gaining and top-losing crypto perpetuals, ranked across the whole market. It distinguishes the market-wide scope from sibling tools like market_snapshot or perp_dashboard, which likely have narrower or different scopes. It stops short of a 5 because it doesn't explicitly contrast against any sibling, leaving some differentiation to inference.
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 example natural-language invocations ('top crypto movers', 'biggest crypto gainers and losers today'), which implicitly tells an agent when to call it. However, it provides no explicit guidance on when NOT to use it or which sibling tool to prefer instead. The context is implied but not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming 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 or an account that owns the GitHub organization, then choose Claim with GitHub.
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!
Live crypto data: funding rates, funding arbitrage, OI pressure, Fear & Greed. Free, no API key.
Live crypto market signals for AI agents: perp liquidations, funding, OI positioning, yield, FX.
Crypto market intelligence: regime detection, funding rates, liquidations, prices, signals.
AI crypto signals, smart money whale positions, live futures prices and indicators
Add one secure layer between your agents and this server.
Most tools target distinct analytics functions (order flow, execution cost, strategy testing, market scans). A few pairs overlap—mass_map/mass_scan, market_rotation/top_movers, and market_snapshot/perp_dashboard—but descriptions clarify differences. No tools are truly indistinguishable.
Naming style is mixed: some tools use verb+noun (explain_move, fetch_series, get_funding) while others use descriptive noun phrases (carry_pressure, currency_leg, exit_capacity). The names are readable and meaningful, but the pattern is not uniform. It is not chaotic, but lacks a single consistent convention.
22 tools is on the heavier side but reasonable for a comprehensive crypto analytics suite covering market data, execution analysis, risk, and strategy testing. Each tool serves a distinct purpose and contributes to the overall scope. It is not excessive enough to feel bloated.
The tool set covers the full analytics lifecycle: market overview, order-flow explanation, execution routing and cost, position limits, options, and strategy backtesting. There are no obvious dead ends; users can research, test, and validate strategies. The coverage is thorough for the stated trading-analytics domain.
