Skip to main content
Glama
AlgoVaultLabs

crypto-quant-signal-mcp

by AlgoVaultLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_trade_signal

Read-only

Get a composite BUY/SELL/HOLD verdict with confidence and market regime for one crypto or tokenized-stock perpetual. Provide coin, exchange, timeframe for a read-only AI signal.

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. [ALIAS] This tool is an alias of get_trade_call — same behavior, kept for backward compatibility. Prefer get_trade_call for new integrations.

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.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds that it queries 'live exchange APIs, no orders', discloses alias equivalence with get_trade_call, and mentions a verified track record. This adds useful behavioral context beyond annotations, though it could detail latency or failure modes.

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?

The main output is front-loaded in the first sentence. Subsequent sentences each serve a purpose: scope, whole-market alternative, read-only safety, verification, and alias. It is dense but not bloated; the 'performance://signal-performance' reference is slightly cryptic but still earns its place.

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 tool with five parameters, no output schema, and informative annotations, the description covers the return shape (BUY/SELL/HOLD, confidence, market regime), single-asset input, read-only behavior, and alias relationship. It could add default exchange/timeframe behavior or response structure details, but the current context is sufficient for correct invocation.

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

Parameters4/5

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

Input schema coverage is 100%, so the baseline is already satisfied. The description adds meaning by clarifying 'One asset only' and 'crypto or tokenized-stock perpetual futures', which usefully constrains the coin and assetClass parameters beyond the schema examples.

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?

Description opens with a specific verb and resource: 'Returns a composite verdict — BUY SELL HOLD trade call with confidence and market regime — for one crypto or tokenized-stock perpetual futures.' It explicitly distinguishes itself from scan_trade_calls ('One asset only; whole-market scan') and identifies the alias get_trade_call, so sibling confusion is minimized.

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

Usage Guidelines5/5

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

The description states single-asset scope and routes whole-market scans to scan_trade_calls. It also points to get_track_record/performance://signal-performance for verification and advises preferring get_trade_call for new integrations, giving clear when-to-use and alternative guidance.

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