AlgoVault — Crypto Quant Trade Calls
Server Details
The Brain Layer for AI Trading Agents — quant calls + cross-venue arb across perp venues via MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- AlgoVaultLabs/crypto-quant-signal-mcp
- GitHub Stars
- 2
- Server Listing
- crypto-quant-signal-mcp
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/5 across 9 of 9 tools scored.
Each tool targets a distinct purpose: knowledge retrieval (chat vs search), equity calls/regime, crypto calls/regime, scans, and arbitrage. The alias get_trade_signal is explicitly noted as identical to get_trade_call, eliminating confusion. No overlapping functionality exists.
All tools follow a consistent verb_noun pattern in lowercase with underscores (e.g., get_equity_call, scan_trade_calls). The verbs 'chat', 'get', 'scan', and 'search' are uniformly used, and nouns clearly describe the resource. No mixed conventions or ambiguous names.
With 9 tools, the server covers its stated domain without being excessive or sparse. Each tool serves a clear role: knowledge access, single-asset signals for equities and crypto, regime detection, market-wide scans, and arbitrage scanning. The count feels well-scoped.
The server provides a comprehensive surface for crypto quant trade calls: knowledge base, per-asset and scan-level trade calls for both equities and crypto, regime detection for both, and funding arbitrage scanning. There are no obvious gaps for its declared purpose, and the alias tool ensures backward compatibility.
Available Tools
9 toolschat_knowledgeARead-onlyInspect
Returns a synthesized natural-language answer with citations, grounded in the AlgoVault knowledge bundle (every MCP tool description, response shape, integration tutorial, and code example). Use when you need an explanation, code pattern, or how-to; for raw ranked snippets without LLM synthesis use search_knowledge (faster, no quota cost). Read-only: calls an LLM, no other side effects. Quota: Free 10/month, Starter 50, Pro 200, Enterprise 2000.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional model override (default claude-haiku-4-5-20251001). | |
| question | Yes | Natural-language question (5-500 chars). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true. Description adds that it calls an LLM, has no other side effects, and details quota costs. This enriches beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose. Every sentence adds value: purpose, usage guidance, and behavioral context. 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 no output schema, the description explains the return is a synthesized answer with citations. It covers main aspects but could mention citation source format. Still, it's sufficient for a Q&A tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add extra meaning beyond the schema for question and model parameters. The schema already describes them adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a synthesized natural-language answer with citations grounded in AlgoVault knowledge. It distinguishes from sibling search_knowledge, which provides raw ranked snippets. The verb 'returns' and resource 'synthesized natural-language answer' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (need explanation, code pattern, how-to) and when not (use search_knowledge for raw snippets). It also mentions quota costs (Free 10/month, etc.), providing clear context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_equity_callARead-onlyInspect
Returns a daily-bar BUY/SELL/HOLD trade call for a US stock or ETF — verdict, confidence, market regime, and the technical factors behind it — from Databento EQUS.MINI daily bars. Universe = top US equities by dollar-volume plus index and crypto-proxy ETFs (SPY, QQQ, IBIT); an out-of-universe ticker returns a structured SYMBOL_NOT_IN_UNIVERSE error with nearest-symbol suggestions (accepts BRK-B or BRK.B). Defaults to the stock read; naming a crypto exchange or timeframe routes to the perpetual-futures call instead — for crypto or tokenized-stock perps, use get_trade_call. Read-only: reads a live market-data API, places no orders.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | US equity/ETF ticker, e.g. AAPL, SPY, BRK.B (BRK-B also accepted). | |
| exchange | No | Optional crypto venue — naming one routes to the perp call (prefer get_trade_call). | |
| timeframe | No | Optional candle timeframe — supplying one routes to the perp call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description reinforces this by stating it is read-only and places no orders. It also discloses behavioral traits such as routing to perpetual-futures call when exchange or timeframe is provided, and the structured error response SYMBOL_NOT_IN_UNIVERSE with nearest-symbol suggestions, adding significant value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured, with the main purpose front-loaded. It includes details on universe, error handling, and routing without redundancy. Every sentence adds value, though some information could be condensed slightly without loss of 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?
Given the absence of an output schema, the description adequately explains the return content (verdict, confidence, market regime, technical factors). It covers universe, error handling, symbol format acceptance, and routing behavior. For a tool with three parameters, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet the description adds value by clarifying that the symbol is a US equity/ETF ticker (e.g., AAPL, SPY, BRK.B) and that BRK-B is also accepted. It explains that exchange and timeframe parameters are optional and route to the perpetual-futures call. This provides context beyond the raw schema 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 clearly states it returns a daily-bar BUY/SELL/HOLD trade call for US stocks/ETFs, including verdict, confidence, market regime, and technical factors. It distinguishes from sibling tools like get_trade_call by explicitly noting that for crypto perpetual futures, the user should use get_trade_call instead.
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 specifies when to use this tool: for US equities and ETFs. It explicitly tells users to use get_trade_call for crypto or tokenized-stock perps. It also describes the universe scope and error behavior for out-of-universe tickers, providing clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_equity_regimeARead-onlyInspect
Returns the market regime for a US stock or ETF — trending_up, trending_down, compression, or ranging, with a confidence score — derived from daily-bar trend strength (ADX/DI), persistence (Hurst), and volatility compression. Defaults to SPY. For a crypto regime use get_market_regime instead. Read-only: reads a live market-data API.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | US equity/ETF ticker; defaults to SPY. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. Description confirms read-only and adds that it reads a live market-data API (implying potential latency/rate limits) and describes output format with regimes and confidence score. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, highly concise and front-loaded. First sentence defines output and methodology, second provides default and alternative tool, third confirms read-only. No redundant content.
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 one optional parameter and no output schema, description covers methodology, output possibilities, default, sibling alternative, and safety. Missing explicit error handling or rate limit info, but overall complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with single parameter 'symbol' described as 'US equity/ETF ticker; defaults to SPY.' Description repeats the default but adds no new parameter-level detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns market regime for US stocks/ETFs with specific regime names (trending_up, trending_down, compression, ranging) and confidence score, derived from daily-bar trend strength and volatility compression. It distinguishes from sibling get_market_regime (crypto). Verb 'Returns' and resource 'market regime' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit alternative for crypto (get_market_regime) and notes default symbol SPY. It implies use for US equities/ETFs but does not explicitly exclude other asset classes beyond crypto, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_regimeARead-onlyInspect
Returns the market regime — TRENDING_UP TRENDING_DOWN RANGING VOLATILE — with confidence and a strategy hint, for one crypto perpetual futures. Composite verdict blends trend ranging and cross-venue funding rate sentiment. For a US equity use get_equity_regime. Read-only, live exchange APIs. Verified track record, on-chain verified merkle anchor.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | Base asset crypto signal, e.g. BTC ETH SOL signal. Crypto quant regime. | |
| exchange | No | Crypto venue, e.g. Binance Bybit OKX Bitget Hyperliquid. Multi-exchange. | HL |
| timeframe | No | Candle timeframe, e.g. 1h 4h 1d. Buy sell hold AI trading signal context. | 4h |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that it is "Read-only, live exchange APIs" and describes the composite verdict methodology (blending trend, ranging, and cross-venue funding rate sentiment), plus mentions verified track record and on-chain merkle anchor, exceeding annotation information.
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?
Four sentences, each adding value: return values, usage context, read-only nature, and credibility. Front-loaded with the output type, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavior, and credibility. However, lacks explicit output schema or examples for the returned confidence and strategy hint, which would improve completeness. Still sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The tool description does not add additional semantic information beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it returns the market regime (TRENDING_UP, TRENDING_DOWN, RANGING, VOLATILE) with confidence and a strategy hint, for a crypto perpetual futures. It also distinguishes from a sibling tool (get_equity_regime) for US equities, satisfying specific verb+resource and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear usage context: "for one crypto perpetual futures." Explicitly directs users to get_equity_regime for US equity, providing when-to-use and when-not-to-use guidance with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trade_callARead-onlyInspect
Returns a composite verdict — BUY SELL HOLD trade call with confidence and market regime — for one crypto or tokenized-stock perpetual futures. One asset only; for a whole-market scan use scan_trade_calls, for US stocks use get_equity_call. Read-only: reads live exchange APIs, no orders. Verified track record, on-chain verified merkle anchor.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | Base asset, e.g. BTC ETH SOL signal, or a US stock/ETF ticker (no USDT). | |
| exchange | No | Crypto venue (default Binance), e.g. Binance Bybit OKX Bitget Hyperliquid. | |
| timeframe | No | Candle timeframe, 1m to 1d. Default 15m. Crypto quant intraday horizon. | |
| assetClass | No | Force engine: 'perp' or 'equity'. Cross-venue multi-exchange AI trading signal. | |
| includeReasoning | No | Include reasoning: trend ranging crypto signal and market regime drivers. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description reinforces this with 'Read-only: reads live exchange APIs, no orders' and adds context about a verified track record and on-chain merkle anchor, providing additional transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by usage guidance and transparency. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations and full parameter schema, the description adequately explains purpose, alternatives, and behavioral traits. It mentions output (composite verdict with confidence and market regime), though without an output schema, a bit more detail on return structure could help. Still, it is mostly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add new meaning beyond the schema; it mentions 'one asset only' which aligns with the coin parameter but does not elaborate further on parameter 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 clearly states the tool returns a composite verdict (BUY/SELL/HOLD) with confidence and market regime for one crypto or tokenized-stock perpetual futures. It distinguishes itself from siblings like scan_trade_calls and get_equity_call, specifying that it handles one asset only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidelines: 'One asset only; for a whole-market scan use scan_trade_calls, for US stocks use get_equity_call.' It also notes the tool is read-only, helping agents decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trade_signalARead-onlyInspect
Returns a composite verdict — BUY SELL HOLD trade call with confidence and market regime — for one crypto or tokenized-stock perpetual futures. One asset only; for a whole-market scan use scan_trade_calls, for US stocks use get_equity_call. Read-only: reads live exchange APIs, no orders. Verified track record, on-chain verified merkle anchor. [ALIAS] This tool is an alias of get_trade_call — same behavior, kept for backward compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | Base asset, e.g. BTC ETH SOL signal, or a US stock/ETF ticker (no USDT). | |
| exchange | No | Crypto venue (default Binance), e.g. Binance Bybit OKX Bitget Hyperliquid. | |
| timeframe | No | Candle timeframe, 1m to 1d. Default 15m. Crypto quant intraday horizon. | |
| assetClass | No | Force engine: 'perp' or 'equity'. Cross-venue multi-exchange AI trading signal. | |
| includeReasoning | No | Include reasoning: trend ranging crypto signal and market regime drivers. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds value by specifying that the tool reads live exchange APIs, places no orders, and mentions a verified track record and on-chain merkle anchor, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3-4 sentences) and front-loaded with the core purpose. Each sentence serves a purpose: purpose, sibling differentiation, read-only nature, alias clarification. No unnecessary 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?
The description covers purpose, usage, behavior, and alias. However, since there is no output schema, the description could have elaborated on the output format (e.g., details of the composite verdict). Despite this, it provides sufficient context for an AI to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add significant new meaning beyond the schema; it reinforces that only one asset is accepted, but the schema already describes the coin parameter similarly.
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: returning a composite verdict (BUY/SELL/HOLD) with confidence and market regime for one crypto or tokenized-stock perpetual futures. It distinguishes itself from sibling tools by specifying that for whole-market scans, use scan_trade_calls, and for US stocks, use get_equity_call.
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 states the tool is for one asset only and provides clear alternatives for whole-market scans and US stocks. Also mentions the alias relationship with get_trade_call, guiding the AI on when to use this over the alias.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_funding_arbARead-onlyInspect
Ranked cross-venue funding arbitrage across major crypto perpetual futures venues — funding rate spreads, long one venue short another, as a BUY SELL HOLD composite verdict per pair. AI trading signal for crypto quant and Claude trading agents. Trade call via get_trade_call, market regime via get_market_regime. On-chain verified merkle anchor.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max ranked results, e.g. 5 (free tier cap). Crypto quant AI trading signal. | |
| minSpreadBps | No | Minimum funding rate spread in bps. Cross-venue multi-exchange crypto signal. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. Description adds useful behavioral context like 'On-chain verified merkle anchor' and implies non-destructive scanning. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (3 sentences) and front-loaded with key function. Efficiently conveys purpose, output type, and related tools without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description explains output as 'BUY SELL HOLD composite verdict per pair' and mentions verification. For 2 optional parameters, this is sufficient but could be slightly more explicit about output 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?
Schema covers both parameters (limit, minSpreadBps) with descriptions including defaults and example values like '5 (free tier cap)'. Tool description does not add further detail beyond schema, so score is baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: 'Ranked cross-venue funding arbitrage across major crypto perpetual futures venues' with specific output 'as a BUY SELL HOLD composite verdict per pair'. This differentiates it from siblings like get_trade_call and scan_trade_calls by focusing on funding arbitrage.
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?
Description indicates appropriate use: 'AI trading signal for crypto quant and Claude trading agents' and directs to related tools for other needs ('Trade call via get_trade_call, market regime via get_market_regime'). Does not explicitly exclude scenarios, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_trade_callsARead-onlyInspect
Returns ranked BUY SELL HOLD trade calls across the top crypto perpetual futures by open interest — one scan for whole-market coverage, each with confidence and market regime. Use this for breadth; use get_trade_call for per-coin depth and reasoning. Read-only: reads live exchange APIs, places no orders.
| Name | Required | Description | Default |
|---|---|---|---|
| topN | No | How many top perps by open interest to scan, 1 to 100 (default 20). | |
| limit | No | Max ranked calls to return, 1 to 100 (default 10). Non-HOLD ranked first. | |
| rankBy | No | Universe lens: oi (default) volume gainers losers movers funding_positive funding_negative volatility oi_change (aliases vol gain lose move pfr nfr atr oid). funding_*/volatility/oi_change rank among the most-liquid perps; oi_change = real 24h open-interest %Δ. | oi |
| oiBasis | No | OI-delta basis for rankBy=oi_change: notional (default, USD) or contracts (base-coin, price-independent). Ignored by other lenses. | notional |
| exchange | No | Venue: BINANCE (default) HL BYBIT OKX BITGET. | BINANCE |
| timeframe | No | Candle timeframe, 1m to 1d for the scan. Default 15m intraday. | 15m |
| includeHolds | No | Include HOLD calls after non-HOLD (default false). HOLDs never cost quota. | |
| minConfidence | No | Optional confidence floor, 0 to 100, applied to non-HOLD trade calls. | |
| oiChangeWindow | No | OI-delta window for rankBy=oi_change: 1h, 4h, or 24h (default 24h). Ignored by other lenses. | 24h |
| includeReasoning | No | Enrich each non-HOLD call with price, the top 2-3 drivers, and one-line reasoning (default false → bare verdict cells). HOLDs stay bare. Same per-call detail as get_trade_call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds specific behavior: 'reads live exchange APIs, places no orders.' This reinforces and adds context beyond annotations. Does not disclose rate limits or pagination, but core safety profile is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and output characteristics, second provides usage guidance and safety. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no output schema, the description explains the tool's purpose, usage, and safety. It hints at output structure (ranked calls with confidence and market regime) but does not fully specify the return format. Given annotations and schema coverage, it is largely complete but could benefit from output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description provides high-level context about the tool's output (confidence, market regime) but does not add specific parameter semantics beyond what the schema already describes. No additional meaning for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'returns', the resource 'ranked BUY SELL HOLD trade calls across the top crypto perpetual futures by open interest', and the scope 'one scan for whole-market coverage'. It also distinguishes from sibling tool get_trade_call by specifying use for breadth vs per-coin depth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use this for breadth; use get_trade_call for per-coin depth and reasoning.' Also mentions read-only nature. Clearly indicates when to use this tool and when to use an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_knowledgeARead-onlyInspect
Returns ranked snippets from the AlgoVault knowledge bundle answering a question about its MCP tools, response shapes, integration patterns (LangChain, LlamaIndex, MAF, CrewAI), or code examples. Call this BEFORE other tool calls to confirm parameter usage and avoid hallucinating tool shapes. Fast: BM25 lexical search, no LLM call, no quota cost. For a synthesized natural-language answer use chat_knowledge. Read-only, no side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max ranked results (1-50, default 10). | |
| query | Yes | Natural-language search query (3-500 chars). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and destructiveHint annotations, it discloses that it uses BM25 lexical search, no LLM call, no quota cost, and has no side effects. This provides useful behavioral context.
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 concise sentences that are front-loaded with the core purpose, followed by usage guidance and performance characteristics. Every sentence is informative and necessary.
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 simple parameter set and lack of output schema, the description fully covers the tool's purpose, usage, performance, and alternatives, leaving no significant 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?
The input schema descriptions are already clear (100% coverage). The description adds value by specifying the knowledge domain (AlgoVault MCP tools, etc.), which helps the agent formulate appropriate queries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns ranked snippets from the AlgoVault knowledge bundle and lists specific domains (MCP tools, integration patterns, etc.). It also distinguishes itself from the sibling tool chat_knowledge by specifying its 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?
Explicitly advises to call this tool before other tool calls to confirm parameter usage and avoid hallucinations. It also contrasts with chat_knowledge for synthesized answers and mentions it's fast with no cost.
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!
Your Connectors
Sign in to create a connector for this server.