Skip to main content
Glama
AlgoVaultLabs

crypto-quant-signal-mcp

by AlgoVaultLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_trade_call

Read-only

Get a BUY, SELL, or HOLD trade call with confidence and market regime for a single crypto or tokenized-stock perpetual, using live exchange data.

Instructions

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; whole-market scan: scan_trade_calls. Read-only: live exchange APIs, no orders. Verified track record: get_track_record or performance://signal-performance; on-chain verified merkle anchor.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
coinYesBase asset, e.g. BTC ETH SOL signal, or a US stock/ETF ticker (no USDT).
exchangeNoCrypto venue (default Binance), e.g. Binance Bybit OKX Bitget Hyperliquid.
timeframeNoCandle timeframe, 1m to 1d. Default 15m. Crypto quant intraday horizon.
assetClassNoForce engine: 'perp' or 'equity'. Cross-venue multi-exchange AI trading signal.
includeReasoningNoInclude reasoning: trend ranging crypto signal and market regime drivers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.30.0
    • changedInput schema / properties / exchange / enum
      Previous value: -[
-  "HL",
-  "BINANCE",
-  "BYBIT",
-  "OKX",
-  "BITGET",
-  "ASTER",
-  "BINGX",
-  "GATE",
-  "HTX",
-  "KUCOIN",
-  "MEXC",
-  "PHEMEX",
-  "WHITEBIT",
-  "BITMART",
-  "XT"
-]New value: +[
+  "HL",
+  "BINANCE",
+  "BYBIT",
+  "OKX",
+  "BITGET",
+  "ASTER",
+  "BINGX",
+  "GATE",
+  "HTX",
+  "KUCOIN",
+  "MEXC",
+  "PHEMEX",
+  "WHITEBIT",
+  "XT",
+  "WEEX"
+]
  2. Changed1 schema field changedv1.28.0
    • changedInput schema / properties / exchange / enum
      Previous value: -[
-  "HL",
-  "BINANCE",
-  "BYBIT",
-  "OKX",
-  "BITGET",
-  "ASTER",
-  "EDGEX",
-  "GATE",
-  "MEXC",
-  "KUCOIN",
-  "PHEMEX",
-  "BINGX",
-  "HTX",
-  "WEEX",
-  "BITMART",
-  "XT",
-  "WHITEBIT"
-]New value: +[
+  "HL",
+  "BINANCE",
+  "BYBIT",
+  "OKX",
+  "BITGET",
+  "ASTER",
+  "BINGX",
+  "GATE",
+  "HTX",
+  "KUCOIN",
+  "MEXC",
+  "PHEMEX",
+  "WHITEBIT",
+  "BITMART",
+  "XT"
+]
  3. First observedv1.25.0

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool read-only and non-destructive; the description reinforces this with 'live exchange APIs, no orders,' which adds operational context beyond the hints. It also discloses the verified-provenance angle with get_track_record and the on-chain merkle anchor. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences front-load the core behavior and scope before routing to alternatives. The track-record sentence is marginally tangential but still informative, and there is no real padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only lookup with rich schema coverage, the description covers purpose, scope, alternative, and safety in a compact way. Without an output schema, it gives the main elements of the return (verdict, confidence, market regime) but not a complete response shape; still sufficient to call correctly with just the coin parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter already has descriptive text with defaults and examples. The description adds only the one-asset constraint and the composite-verdict framing, not new parameter-level semantics, so the schema carries the weight.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb and resource: returns a composite BUY/SELL/HOLD verdict with confidence and market regime for a single perpetual-futures asset. It also explicitly contrasts with the whole-market scan sibling scan_trade_calls, so an agent can distinguish the tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'One asset only; whole-market scan: scan_trade_calls' sentence gives an explicit alternative and the condition that selects it. However, it does not explain how to choose between get_trade_call and the similarly named get_trade_signal, leaving that distinction implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools