自律型取引の世界において、リアルタイムのオーダーフローを持たないAIエージェントは、目隠しをして飛行するパイロットのようなものです。テクニカル指標（RSI、MACD）は過去の遅れた残響に過ぎません。Horusは、以下を提供する神経系です：
自己受容感覚: 市場の「筋肉」（オーダーブックの深さ）に対するリアルタイムの認識。
反射神経: 機関投資家の「痛み」（流動性の崩壊）のサブ秒単位での検知。
インテリジェンス: 生の物理データを実用的なシグナルに変換する、コンテキストを認識した意思決定マトリックス。
「AIエージェントにクジラのように取引させたいなら、クジラの目を与えなければなりません。Horusこそがその視覚です。」
Related MCP server: crypto-quant-signal-mcp
Horus Flow MCPは、Manus AI（自律型実行エージェント）によって厳格に監査されました。その結果、Horusが単なるコードではなく、高性能な現実であることが確認されました。
シグナルの精度: 0.85の信頼スコアでSTRONG_SELL_PRESSURE（強い売り圧力）を正常に検知。
物理エンジンの検証: bid_ask_ratio（買値/売値比率）が0.156であることを確認し、薄いリミットブックとアグレッシブな売りを読み取るエンジンの能力を証明。
ハルシネーションのないロジック: MCPサーバーは「データ収集」モード（例：SOLUSDT）のシンボルを正しく識別し、AIが誤った前提で判断を下すことを防止。
メトリック | 監査結果 | ステータス |
応答時間 | サブミリ秒（ローカル） | ✅ 検証済み |
データ整合性 | L2 Binanceオーダーブック同期 | ✅ 検証済み |
AI信頼度 | 高ボラティリティイベントで0.85以上 | ✅ 検証済み |
わずかなコストで同じマイクロストラクチャー・インテリジェンスが得られるのに、なぜ機関投資家向け端末に何千ドルも支払うのでしょうか？
機能 | Horus Flow MCP | 従来の端末 |
月額費用 | 29ドル（Proプラン） | 150ドル - 2,000ドル以上 |
AI統合 | ネイティブMCP（プラグ＆プレイ） | 複雑なAPI / 手動 |
データソース | 機関投資家向けL2フィード | 独自 / クローズド |
意思決定ロジック | 物理ベース（重力） | 遅行指標 |
個人トレーダーは、過去に基づいて市場がどう動くかを推測するために遅行指標を使用します。Horusは、レベル2オーダーブックの物理特性、ティックの不均衡、5秒間のフローデルタを使用して、機関投資家のクジラが今まさに何をしているかを正確に測定します。
Horusは「買われすぎか？」とは問いません。重力を測定し、こう伝えます：「クジラが買い板を偽装しており、アグレッシブなテイカーが売り板を突き破っている。流動性が崩壊している。今すぐ逃げろ。」
AIエージェントを基本的なテクニカル指標フィードに接続すると、ノイズに混乱してしまいます。AIエージェントにHorusを供給すれば、機関投資家グレードの意思決定マトリックスが得られます。
流動性の引き揚げ / フラッシュクラッシュの試行中に、Horusがリアルタイムで何を捉えるかを見てください：
{
"symbol": "BTCUSDT",
"signal": "LIQUIDITY_EVENT",
"confidence": 0.99,
"market_state": "DISTRIBUTION",
"risk": "EXTREME",
"description": "Liquidity withdrawn under price. Aggressive taking.",
"metrics": {
"bid_ask_ratio": 7.934,
"buy_sell_ratio": 0.393,
"delta_5s": -83040.05,
"whale_activity": true,
"large_sell_count": 4,
"delta_accel": 3.8,
"wall_side": "BID",
"wiseman_climate": {
"market_mode": "CHOP",
"health": "FRAGILE",
"confidence": 0.85
},
"flags": [
"GLOBAL_LIQUIDITY_EVENT",
"SPOOFING_DETECTED(wall=BID)"
]
},
"timestamp": 1776107738.975
}bid_ask_ratio: 7.934 & wall_side: BID: 偽のサポートを作るために、クジラによって市場の下に大規模な偽の買い板が置かれています。
buy_sell_ratio: 0.393: Horusは偽装を見抜きます（SPOOFING_DETECTEDフラグ）。実際のテイカーフローを測定し、アグレッシブな売りがオーダーブックを破壊していることを発見します。
delta_accel: 3.8 & whale_activity: true: 売りモメンタムが3.8倍に加速し、ミリ秒単位で4つの主要なクジラの投げ売りをネイティブに追跡します。
wiseman_climate: FRAGILE: Horus SaaSの全体的なマクロ脳と完全に統合し、攻撃を仕掛ける前にビットコインの全体的な環境が脆弱であることを検証します。
判定: 0.99の信頼係数で、AIエンジンはLIQUIDITY_EVENTをトリガーします。その後の1分間の暴落を先回りします。これが機関投資家グレードです。
graph TD
%% Styling
classDef crypto_stream fill:#F3BA2F,stroke:#000,color:#000,stroke-width:2px;
classDef equity_stream fill:#000,stroke:#09b533,color:#09b533,stroke-width:2px;
classDef compute fill:#1A1F36,stroke:#00D6FF,color:#fff,stroke-width:2px;
classDef mcp fill:#632CA6,stroke:#fff,color:#fff,stroke-width:2px;
classDef client fill:#FF3366,stroke:#fff,color:#fff,stroke-width:2px;
%% Ingestion
subgraph Data_Pipelines [Sub-Millisecond Websocket Ingestion]
B[Binance WSS <br/> L1/L2 Book]:::crypto_stream
A[Alpaca WSS <br/> SIP Equities]:::equity_stream
end
%% Engine
subgraph Core_Engine [The Physics Engine]
IC[Imbalance Calculator <br/> Bid/Ask Spread]:::compute
FC[Flow Calculator <br/> Tape Deltas]:::compute
Tkr[Prediction Tracker <br/> In-Memory Evaluator]:::compute
BC[Behavioral Court <br/> Spoofing & Liquidity Rules]:::compute
end
%% Output
subgraph Output_Layer [Data Shield & Delivery]
MCP[AI Agent MCP Context <br/> Context-Aware Prompts]:::mcp
API[FastAPI Client <br/> Safe Shielded Outputs]:::client
Dash[Real-time Dashboard <br/> Live Edge Proof]:::client
end
B --> IC
A --> IC
B --> FC
A --> FC
IC --> BC
FC --> BC
BC --> Tkr
Tkr -- "Validates 1M accuracy" --> BC
BC --> MCP
BC --> API
BC --> DashHorusの利用開始は60秒もかかりません。 ⚡ 即時テスト: Postmanコレクションをダウンロードして、ブラウザから直接APIをpingしてください。
# Install Dependencies
pip install mcp httpx
# Set your RapidAPI Key (Required for the server to fetch live data)
export RAPIDAPI_KEY="your_actual_rapidapi_key"
# Run the SSE Server
python horus_mcp_public.py --transport sse --port 8011ローカルのボット/エージェントで、RapidAPIキーまたは直接APIキーを使用して、暗号資産または米国株のライブフローを取得するだけです：
import requests
response = requests.get(
"https://flow.horustek.pro/v1/flow/crypto/BTCUSDT",
headers={"X-API-Key": "your_secure_api_key"}
)
flow_data = response.json()
# The Zero-Human Decision Loop:
if flow_data.get('signal') in ['EMERGENCY_DUMP', 'BAILOUT', 'LIQUIDITY_EVENT']:
print(f"⚠️ {flow_data['symbol']} Market gravity collapsing. Executing Bailout.")
# execute_market_sell()Horusには、箱から出してすぐに使える、見事なグラスモーフィズムのWebSocketダッシュボードとインタラクティブなAPIドキュメントコンソールが付属しています。
👁️ 開発者ポータルを見る: https://flow.horustek.pro
物理エンジンによって生成された1分間のローソク足の方向予測を、透明性の高い勝率で厳密に測定する「ローカルエッジ証明トラッカー」を備えています。開発者がエージェントに組み込む前に、そのロジックを確認できるようにしています。
マトリックスを見る必要がある人々のために、絶対的な精度で構築されました。 — HORUS INTELLIGENCE 👁️
mcp-name: io.github.horustechltd/horus-flow-mcp
Get composite intelligence score (0-100) with tactical verdict.
Returns a score from 0-100 and a verdict: BUY, SHORT, or STAY_OUT.
Combines orderflow, sentiment, leverage ratios, and smart money positioning
into a single actionable number. Score < 45 = dangerous, > 65 = opportunity.
Args:
symbol: Trading pair (default: BTCUSDT)
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | BTCUSDT |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output structure and basic interpretation but lacks details on authentication requirements, data freshness, or any side effects. The description is somewhat transparent 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?
The description is concise with about 4 sentences. It leads with the main purpose, then explains output, composition, and interpretation. It is well-structured and efficient, though slightly more bullet-point structuring could improve readability.
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 (indicated but not shown), and the description adequately explains the return values (score and verdict). Given the single parameter and absence of annotations, the description covers the essential context 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?
There is one parameter (symbol) with 0% schema description coverage, meaning the schema only provides a title and default. The description adds semantic meaning by stating 'Trading pair (default: BTCUSDT)', which is clear and helpful beyond 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 the tool gets a composite intelligence score with a tactical verdict (BUY, SHORT, STAY_OUT). It specifies the score range (0-100) and combines multiple factors like orderflow, sentiment, leverage ratios, and smart money positioning, distinguishing it from sibling tools that focus on specific flows or heatmaps.
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 interpretation guidance (score <45 dangerous, >65 opportunity) but does not explicitly state when to use this tool versus alternatives like get_market_intelligence or get_crypto_flow. No explicit when-to-use or when-not-to-use conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Futures/Spot ratio, speculation index, and smart money divergence.
Reveals whether the market is driven by speculation (Futures) or real demand (Spot).
Futures/Spot > 8x = HYPER_SPECULATION (vulnerable to flush).
Also shows smart money divergence: are top traders positioned opposite to the crowd?
Args:
symbol: Trading pair (default: BTCUSDT)
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | BTCUSDT |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully convey behavior. It describes the returned indicators and gives a threshold, but does not mention rate limits, authentication, or potential side effects. As a read operation, it is adequately transparent.
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, well-structured, and front-loaded with key information. It uses a clear header, explanation, and args section without any unnecessary 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 a single optional parameter and an output schema, the description is complete. It explains the indicators, a threshold, and the parameter, making it fully self-contained for an agent.
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, so the description must compensate. It explicitly states the symbol argument is a trading pair with a default of BTCUSDT, adding meaning beyond the schema's default value.
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 gets Futures/Spot ratio, speculation index, and smart money divergence. It explains what these indicators reveal, making the purpose unmistakable. The name matches the description, and it is distinct from sibling tools like get_crypto_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 explains what the tool reveals (speculation vs real demand) and provides a hyper-speculation threshold. It does not explicitly state when to use versus siblings or alternatives, but the context is clear for cross-exchange flow analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time institutional orderflow for a cryptocurrency.
Returns signal (BUY_PRESSURE/SELL_PRESSURE/WHALE_EXIT/EMERGENCY_DUMP),
confidence score, bid/ask depth metrics, whale intent, toxicity level,
and flags like SPOOFING_DETECTED, BID_WALL_TRAP, DEPTH_COLLAPSE.
Args:
symbol: Trading pair (e.g., "BTCUSDT", "ETHUSDT", "SOLUSDT")
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 output types (signal, confidence, depth metrics, flags) and notes it is real-time. It does not mention rate limits or permissions, but for a read-only data tool, this is adequate.
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 four sentences, starting with the core purpose and then listing return fields and the argument. It is front-loaded and every sentence adds value. 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's simplicity (1 required parameter) and the existence of an output schema, the description provides a thorough overview of return values and the argument. It covers all necessary context for an agent to select and invoke 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 input schema has only 'symbol' with type string and 0% description coverage. The description adds concrete examples ('BTCUSDT', 'ETHUSDT', 'SOLUSDT') and clarifies the trading pair format, which is essential for correct invocation. This fully compensates for the schema's lack of detail.
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 'Get real-time institutional orderflow for a cryptocurrency,' which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'scan_crypto_flow' by focusing on a single symbol and providing detailed output metrics.
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 implicitly tells when to use: when needing real-time orderflow for a specific cryptocurrency. However, it does not explicitly state when not to use it or compare with alternative siblings like 'scan_crypto_flow' for scanning multiple symbols.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time institutional orderflow for a US equity stock.
Returns signal (BUY_PRESSURE/SELL_PRESSURE/WHALE_EXIT/EMERGENCY_DUMP),
confidence score, large sell orders count, block trades, toxicity,
and flags like WATERFALL_DUMP, PULLED_BID_WALL_SPOOF.
Args:
symbol: Stock ticker (e.g., "SPY", "AAPL", "TSLA", "NVDA", "MSFT")
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the returned data fields but does not mention latency, data freshness, rate limits, or whether the operation is read-only. The non-destructive nature is implied.
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 with no wasted words. It uses a clear structure: a one-line purpose, a list of return fields, and an Args section for the parameter. Information 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 tool has a single parameter and an output schema (not shown to us). The description covers all returned fields and the parameter's usage. For a simple data retrieval tool, it is fully 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 0%, but the only parameter 'symbol' is well-described with examples (e.g., 'SPY', 'AAPL'), adding meaning beyond the schema's title and type. This compensates for the lack of 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 retrieves real-time institutional orderflow for US equities, listing specific return fields like signals and flags. This distinguishes it from siblings such as get_crypto_flow (crypto) and get_cross_exchange_flow (cross-exchange).
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 for US equities but does not explicitly state when to use this tool versus alternatives like get_crypto_flow or get_cross_exchange_flow. No exclusions or alternative conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect volatility ignition events — potential explosive price moves.
Returns ignition state (DORMANT, RISING, IGNITED) and directional bias.
IGNITED = imminent large move, reduce or exit positions.
RISING = pressure building, prepare for breakout.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses outputs (state and bias) and interprets them. It does not mention side effects, which is acceptable for a read-like tool. Lacks explicit read-only hint but is sufficiently transparent.
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, each adding value: purpose, outputs, interpretation. No unnecessary 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 parameters and presence of output schema, description explains key return fields meaning. Could add more detail on directional bias format, but complete enough for usage.
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?
No parameters exist and schema coverage is 100%, so description need not add param details. Baseline of 4 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 clearly states the tool detects volatility ignition events and returns ignition state and directional bias. It distinguishes itself from sibling tools (flow and intelligence tools) by focusing on explosive price moves.
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 usage context by explaining what IGNITED and RISING states imply (reduce positions, prepare for breakout), but does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get liquidation zones with dollar amounts — where leveraged positions will be force-closed.
Returns clusters of long and short liquidations at specific price levels
with total dollar amounts. Critical for avoiding entries near massive
liquidation zones that could trigger cascading price moves.
Args:
symbol: Trading pair (default: ETHUSDT)
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | ETHUSDT |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear all behavioral disclosure. It explains the tool returns clusters with dollar amounts but doesn't mention read-only behavior or any potential side effects. While it adds value, it could be more transparent about its idempotency.
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 paragraphs with an args list; the first sentence is clear and direct. However, the second paragraph partly restates the first, and the overall length could be trimmed without losing meaning.
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 adequately explains the tool's purpose and return structure. It adds context about critical use cases, making it largely complete for an agent.
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 the 'symbol' parameter, but the description explicitly states 'symbol: Trading pair (default: ETHUSDT)', which adds meaning beyond the schema's type and default. This compensates for the schema 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 description clearly states the tool retrieves liquidation zones with dollar amounts, specifying that it returns clusters of long and short liquidations at specific price levels. This differentiates it from sibling tools that focus on flows or intelligence, though not explicitly naming alternatives.
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 use for avoiding entries near large liquidation zones to prevent cascading moves, but lacks explicit when-not-to-use or alternative suggestions. It provides a clear use case without situational exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get US equity market macro trend and recent institutional block trades.
Returns SPY macro climate (market mode, buy ratio) and list of recent
block trades over $200K with symbol, direction, and size.
Use this to understand where institutional money is flowing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It states the tool returns macro climate and block trades, implying a read operation. However, it lacks details on data recency, update frequency, or any limitations, which would be helpful 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 three sentences with no wasted words. It front-loads the purpose, details the output, and provides a use case, making it highly efficient for an agent to parse.
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 no parameters and an output schema exists, the description adequately covers the output structure and threshold. It could mention whether data is historical or real-time, but overall it is complete for agent 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?
The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it does not add any parameter info, which 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 clearly states the tool retrieves US equity market macro trend and institutional block trades. It specifies the output includes SPY macro climate (market mode, buy ratio) and block trades with details. This sets it apart from sibling tools like get_equity_flow and get_market_climate.
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 suggests using the tool 'to understand where institutional money is flowing', providing a use case. However, it does not explicitly mention when not to use it or compare it with alternative tools among the siblings, leaving some ambiguity for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current market mode and health status.
Returns market mode (CHOP, TREND, RANGE) and health (HEALTHY, FRAGILE).
CHOP = only scalps work, TREND = directional trades, RANGE = mean-reversion.
If health is FRAGILE, reduce all position sizes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses return values and implications. Explains what each market mode means for trading strategy and advises position sizing adjustment for FRAGILE health.
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 concise sentences front-loaded with purpose. Every sentence adds value. 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?
Fully explains the tool's output and its interpretation. With no parameters and an output schema, the description is 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?
No parameters exist, so baseline 4. Description adds value by explaining the meaning of the returned data beyond 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?
Clearly states it returns market mode (CHOP, TREND, RANGE) and health (HEALTHY, FRAGILE). Distinguishes from siblings like get_market_intelligence by focusing on climate status.
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 describes when to use (get current mode/health) and gives actionable advice for FRAGILE health. Doesn't explicitly mention when not to use or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete market intelligence in a single call — combines all endpoints.
Returns orderflow signal, composite score, liquidation zones, cross-exchange
analysis, climate, and ignition state in one unified response. Use this
for a comprehensive pre-trade check.
Args:
symbol: Trading pair (default: BTCUSDT)
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | BTCUSDT |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It explains what data is returned but does not mention any limitations, auth needs, rate limits, or data freshness. This is insufficient for a tool combining multiple endpoints.
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 mostly concise with two clear introductory sentences and a parameter doc. The Args section could be integrated more smoothly, but overall it's well-structured.
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 (combining multiple analyses) and the presence of an output schema, the description adequately explains the return contents and parameter. It lacks mention of any usage restrictions or error handling, but otherwise is fairly 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 description adds meaning to the symbol parameter beyond the schema: 'Trading pair (default: BTCUSDT)'. Since schema coverage is 0%, this extra context is valuable, though it could specify format or constraints.
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 combination of multiple endpoints (orderflow signal, composite score, etc.), distinguishing it from sibling tools that likely return individual metrics. The verb 'Get' with 'complete market intelligence' is 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 advises using this for a comprehensive pre-trade check, giving a clear context. However, it does not explicitly state when not to use it (e.g., if only one component is needed) or mention alternative sibling tools for specific data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan multiple cryptocurrencies for orderflow signals at once.
Returns a summary with strongest buy/sell signals and individual results
sorted by confidence. Use this for portfolio-wide risk assessment.
Args:
symbols: Comma-separated trading pairs (default: BTC, ETH, SOL, BNB, XRP)
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | No | BTCUSDT,ETHUSDT,SOLUSDT,BNBUSDT,XRPUSDT |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions that the tool returns a summary and individual results sorted by confidence, indicating a read-like operation. However, it does not disclose potential behavioral traits such as authentication requirements, rate limits, error handling, or what happens if symbols are invalid. Basic transparency is present but incomplete.
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 well-structured: it starts with the main purpose, then describes the return, gives a usage context, and explains the argument. Every sentence serves a purpose with no unnecessary 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 that an output schema exists, the description does not need to explain return values. It adequately covers purpose, parameter, and usage context. The only gap is the minor inconsistency in the parameter default example, which slightly undermines completeness. Overall, it is mostly sufficient 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?
The input schema has no descriptions (0% coverage). The description adds value by explaining the 'symbols' parameter as 'Comma-separated trading pairs' and provides a default list. This goes beyond the schema's mere type and default. However, there is a slight inconsistency: the schema default includes full trading pairs like 'BTCUSDT', while the description lists simple names like 'BTC'. This could cause confusion.
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 scans multiple cryptocurrencies for orderflow signals, returns a summary with strongest buy/sell signals, and individual results sorted by confidence. It distinguishes from siblings like get_crypto_flow (likely for single asset) by explicitly mentioning 'multiple' and 'portfolio-wide risk assessment.'
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 a clear use case: 'Use this for portfolio-wide risk assessment.' It implies the tool is for scanning multiple assets but does not explicitly state when not to use it or compare to alternatives. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_composite_intelligenceget_cross_exchange_flowget_ignitionsget_liquidation_heatmapget_macro_blocksget_market_climateget_market_intelligencev1.0.0get_crypto_flowget_equity_flowscan_crypto_flowScored across 10 tools
Most tools have distinct purposes: crypto vs equity flow, batch scanning, macro blocks, composite score, liquidations, cross-exchange, climate, and ignition detection. The main ambiguity is between get_composite_intelligence and get_market_intelligence, though the latter is clearly described as an aggregate of all endpoints.
The dominant pattern is get_<domain>_<concept>, which is predictable and readable. One deviation is scan_crypto_flow, which uses a verb other than get, but it still follows the same broad noun/flow convention.
Ten tools is well-suited to the server's purpose of providing comprehensive market intelligence. Each tool addresses a distinct data need without redundancy, and the count feels appropriately scoped for a trading analysis domain.
The toolset covers crypto and equity orderflow, macro context, liquidation zones, cross-exchange data, market climate, ignition events, and a composite aggregate. Minor gaps include no direct tool for historical data or sentiment text, but the core pre-trade intelligence workflow is well covered.
Crypto futures order-flow signals, pumps, liquidation levels, order book walls and verdicts
Live crypto order book heatmap PNG, CVD, imbalance and liquidations from 4 public exchange feeds.
Tracks real-time 1h/24h DEX buy/sell orderflow ratios, whale accumulation signals, and liquidity v
Crypto market data, 200 indicators, order flow and a chart link. No account, no API key.
