ensotrade
Server Details
Live crypto data: why a coin or the market is moving (funding, OI, positioning, flow).
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 5 of 5 tools scored. Lowest: 3/5.
Most tools have distinct purposes, but 'market_snapshot' aggregates data from 'get_funding' and 'get_order_flow', causing potential confusion. Descriptions help differentiate, but an agent might struggle to choose between the combined and individual tools.
Tool names mix 'verb_noun' patterns (e.g., 'explain_move', 'get_funding') with noun phrases ('market_snapshot', 'top_movers'), lacking a consistent naming convention. While readable, the inconsistency could confuse an agent expecting a uniform pattern.
With 5 tools, the server is well-scoped for providing crypto perpetuals data. Each tool earns its place, covering explanations, funding, order flow, snapshots, and top movers without unnecessary bloat.
The tool set covers key aspects of crypto market analysis (funding, order flow, price movements, top movers). Minor gaps exist, such as the lack of historical data or direct individual access to open interest, but core workflows are supported.
Available Tools
12 toolscarry_pressureAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry full transparency burden. It discloses the API key requirement and explains output components, but does not mention rate limits, data freshness, or whether the tool modifies state.
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 three sentences are concise and front-loaded: first sentence defines the tool's output, second adds a prerequisite, third gives a parameter example and reference. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and an output schema exists, the description covers the key points: metric definitions, auth requirement, parameter guidance, and a reference to help interpret results. It is sufficiently 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 schema has no parameter descriptions (0% coverage). The description adds '`coin` = ticker e.g. 'btc'', which provides an example but lacks details on format, case sensitivity, or valid values.
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 explains the tool computes a 'Toxic Carry Score' and 'Open Interest Quality Index', both well-defined. However, it lacks an explicit verb (e.g., 'retrieve' or 'calculate') and does not contrast with sibling tools, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions an EnsoTrade Pro API key requirement and directs to a glossary resource, but provides no guidance on when to use this tool versus siblings like 'get_funding' or 'market_snapshot', leaving selection ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_moveAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
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 discloses that the tool uses live order-flow and positioning, and returns a sentence plus structured signals. This is sufficient transparency for a read-only query 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 three sentences with no fluff. It is front-loaded with the purpose and provides all necessary context efficiently.
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 one parameter, an output schema (implied), and clear usage examples, the description is complete. No gaps remain for the agent to select and 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?
Schema description coverage is 0%, but the description explicitly defines the parameter: 'coin = ticker like btc, eth, sol.' This adds full meaning beyond the schema's type-only specification.
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 explains WHY a crypto coin is moving using live data. It provides example questions and distinguishes itself from siblings like get_funding or market_snapshot by focusing on causal explanation.
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 'Use this for...' and gives examples of when to invoke it. It does not explicitly mention alternatives or when not to use, but the context with sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_seriesInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
get_fundingAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It explains that the tool returns current funding rate and crowding information, and indicates whether longs or shorts are paying/crowded. However, it does not disclose potential side effects (likely read-only), error handling, or rate limits, leaving some behavioral aspects unclear.
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 short and to the point, with two sentences plus a parameter note. It is front-loaded with purpose and examples. Could be slightly more structured, but overall concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and an output schema present, the description adequately covers the tool's purpose and usage. It explains the kind of data returned (funding rate and crowding). It lacks details on prerequisites or error scenarios, but for a simple read tool this is sufficient.
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% as the parameter 'coin' has only a type string with no description. The tool description adds 'coin = ticker e.g. 'btc'', which provides meaningful context and an example, compensating for the lack of schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the current perpetual funding rate and crowding read for a crypto coin, with examples like 'funding rate on <coin>' and 'is funding positive'. It distinguishes itself from siblings which likely focus on other aspects like order flow or market snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage contexts: 'Use for "what's the funding rate on <coin>", "is funding positive".' This helps the agent know when to invoke it. However, it does not explicitly mention when not to use or mention alternatives, but the sibling tools list provides implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_order_flowAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It mentions the output conceptually (interpretation of moves) but lacks details on data freshness, error handling, or any side effects. This is adequate but not exhaustive.
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 plus a concise parameter note. Every part adds value, no redundancy. The key functionality is front-loaded.
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 covers input, output concept, and use cases. With an existing output schema, return values are separate. A single parameter makes this complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds needed meaning: it defines 'coin' as a ticker with example 'btc'. This compensates well for the missing schema documentation, though format specifics are omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it provides 'positioning regime + open interest + recent taker imbalance' for a crypto coin, and distinguishes from siblings by focusing on order flow analysis rather than general market snapshot or funding rates.
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 suggests use cases like 'crypto order flow', 'open interest change', 'is this a short squeeze', which is clear guidance. However, it does not explicitly contrast with sibling tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_rotationInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
market_snapshotAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries burden. It indicates live, real-time data and lists metrics, but does not disclose potential side effects, rate limits, data freshness, or authorization needs. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Front-loaded with purpose and key metrics. Parameter explanation integrated efficiently.
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 output schema existence (relieves need to explain returns), description lists metrics. Missing details like error handling or authentication, but sufficient for a simple snapshot tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description compensates by explaining the 'coin' parameter with example format ('e.g. 'btc''). Clearly defines what user must provide, though no additional constraints like allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it provides a combined live snapshot for a crypto coin, listing specific metrics (price, 24h change, funding, open interest, perp basis, positioning regime). It distinguishes from siblings which are more specialized tools (explain_move, get_funding, etc.).
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?
Implies use when an overall market view is needed ('One combined live snapshot'), but does not explicitly state when to use versus alternatives, nor provide when-not scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
options_chainAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the API key requirement and outlines output contents. No annotations are provided, so the description carries the burden well, though lacks details on rate limits or side effects.
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, no filler: first sentence defines purpose and output, second adds prerequisite and parameter guidance. Efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description covers core functionality and parameter meaning. Minor gap: no mention of expiration dates or filtering options, but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no schema parameter descriptions (0% coverage), the description fully clarifies the single parameter 'coin' by defining it as the underlying ticker with an example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'full crypto options chain' and lists specific elements (strikes, mark IV, greeks, Black-Scholes gap), making it distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions the prerequisite (EnsoTrade Pro API key) and gives an example for the coin parameter, but does not contrast with sibling tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
perp_dashboardInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
save_strategyInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
test_formulaAInspect
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. Iterate: call this repeatedly with different formulas, keep what validates, discard what doesn't. Requires an EnsoTrade Pro API key.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| symbol | Yes | ||
| formula | Yes | ||
| horizon | No | ret_30s_bp | |
| timeframe | No | scalp | |
| horizon_bars | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: restricted expression evaluator, validation methodology (70/30 split, holdout condition), minimum data requirements, and API key requirement. All critical behaviors are clearly stated.
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-organized into logical sections (formula, timeframe modes, validation logic) and contains no filler. It is slightly lengthy but every sentence provides necessary context for correct usage.
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 (6 parameters, multiple timeframes, validation logic), the description covers all essential aspects: parameter details, constraints, return values (train/holdout stats, verdict), and iterative workflow. The presence of an output schema further contextualizes the return structure.
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 description adds extensive meaning beyond the schema: explains formula syntax with examples, details timeframe behavior and horizon options, describes hours constraints and minimum data guarantees. Despite 0% schema coverage, the description compensates completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: to invent and test a formula for predictive power on forward returns. It uses specific verbs ('invent', 'validated on holdout') and clearly distinguishes from sibling tools like fetch_series by focusing on formula testing rather than data retrieval.
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 detailed usage context, including formula syntax, timeframe options, and parameter behavior. It explains when to use different timeframes and horizons. While it lacks explicit 'when not to use' statements, the guidance is thorough and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
top_moversBInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states the tool returns data 'right now' but does not disclose the time horizon (e.g., 24h), metric type (percentage vs absolute), or how the 'limit' parameter affects results. Missing details on ordering and error states reduce transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two efficient sentences. The first sentence delivers the core purpose immediately, and the second provides example queries. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (which may clarify return values), the description omits critical context: the time period for moves, whether gains/losses are percentage or absolute, and how results are sorted. For a tool with one optional parameter and no annotations, this leaves significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the only parameter 'limit', and the description does not explain it. The agent must infer that 'limit' controls the number of results, but no unit or default behavior beyond the schema's default of 10 is clarified. The description adds no value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides top gaining and losing crypto perpetuals, ranked across the whole market. It distinguishes from sibling tools like 'explain_move' or 'market_snapshot' by focusing specifically on movers. However, it does not specify whether the ranking is by percentage or absolute change, which slightly reduces clarity.
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 queries like 'top crypto movers' and 'biggest crypto gainers and losers today', which imply appropriate usage contexts. However, it does not explicitly state when to use this tool versus alternatives like 'market_snapshot', nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!